Posts by jwenting

You can't have it both ways. Either you use RMI and the ports it gives you, or you code your own sockets implementation and use whatever port you want.

you can also buy CDs in any music store.

RMI as standard runs on port 1099, not port 21.

he probably didn't install the JDK, or didn't set his environment properly, as described in the installation instructions.

look at JOptionPane. Dozens of options.

So, the server can't bind the remote.
Hardly surprising if you have no RMI registry running.

And you never even try to find the registry you're trying to register your remote object with, so it's no surprise you can't register it.

what do you mean, it "cannot see the server"?

Log the remote object as it is returned, what are you getting for the endpoint?

If your hostsfile is configured wrong your server might pass your clients an incorrect IP address to use when making calls on the remote object, leading to those calls getting lost and the client reporting a "connection refused" or similar error.

We're not here to do your work for you, so we don't have to understand it.

I'm not going to read all that, that's your job. It's also your job to understand it.
If you're too lazy to read it, so be it but you're going to fail your assignment and hopefully your entire course so you won't bother us as a potential colleague in the future.

Be happy you're getting detailed specs now, in the future you will hardly ever get anything more detailed than a short description of what it's about to do.

read the release notes.
they're in the obvious location.

try things like JGraph or JXGraph. I've not used them myself but seen some output and it looks good.

http://today.java.net/pub/a/today/2006/04/20/bringing-swing-to-the-web.html might give some pointers.

start writing your speeches with more time to spare next time.

there are no trial versions of any Windows version.
Nor are there any versions (officially) called "XP 2004". Might be a pirate's name for XP SP2.

and if you don't know English you're never going to be able to explain it, nor to understand whatever we're trying to tell you ;)

You should always close resources after you're through with them, and scarce resources like database connections should be treated more carefully than most.

While an application should release them when closing, it's always good practice to do so deliberately, and make certain you don't keep them open longer than needed.

Case in point from the real world:
A major customer (this was a multinational) had a weird problem. One of their application servers (and the database server it was hooked up with) would crash every morning at around 9AM.
It would require a hard reboot of the database to get back online.
When investigating we found that the application was opening hundreds of database connections, and kept trying to open more and more until the database license ran out, after which it would keep polling and queueing requests for more connections until the database server crashed because of the overload.
All clients would then of course hang or crash as well.
The application was opening connections for every request to the database, and never closing them again.
Adding a few lines of code to handle connections properly cured the problem (which had been costing them tens of thousands of Euros per day for weeks) in minutes.
A more complete solution was complete and tested a few weeks later using connection pooling for better performance.

learn English and don't be lazy...

1) use syntactically and gramatically correct English everywhere
2) ditto Java
3) O'Reilly

and more on political correctness than on anything else... My sister was told to march in anti-nuke rallies or she'd be failed her classes.
Only a complaint to the school administrator got that situation changed.

get the ascii code and subtract the value of 'a'.

they hook into the JVM from the outside, which should give them more information.
It's probably available, but think of it: when you try to find out how many objects there are you're creating objects yourself, thereby changing the result.

The Sun forums are excellent, but even less friendly towards freeloading kids who want to gain a diploma over the heads of others and then claim to be software engineers without doing any real work, instead loading it onto the shoulders of the same people who were stupid enough to help them get that diploma.

As I said, do your own homework.
You're too lazy to even try to disguise it as a real problem, too lazy to even copy and paste your assignment...
Teachers should go back to handing out assignments on paper, that way you lazy kids would at least have to type them in.

StringBuffer s1=new String Buffer("hello");

StringBuffer s2=s1;

creates a compiler error.

StringBuffer s1=new StringBuffer("hello");

StringBuffer s2=s1;

creates at most 2 objects, a StringBuffer on the heap which lasts for the scope of the method, and a String on the String constant pool (unless one already exist for the string "hello" in which case that one is referenced instead).
It also creates 2 references to the single StringBuffer.

There is no way to count objects or references that exist in Java, there is no such mechanism provided in any public API (there may be something in an internal API used by the garbage collector).

I have to agree with wizard. Though she's doing a good job and I think most everyone would hate to see her go it's her decision and hers alone.

you forgot to "clean up" the dialogue to use hax0r sp33k and tm shorthand in overabundance.

There's nothing wrong with Javadoc itself, it works just fine here...
But I've over the years learned to avoid paths with spaces in them, which is likely your problem.

do your own homework, don't just go whining that you're late starting and would someone please do it for you as it won't get you any sympathy.

yes, they're different applications.
In the real world they'd be different projects or subprojects and should be treated as such.
And the interaction layer is a different project or subproject again.

They'll also have different usecases with quite different actors.

Better yet: just learn to use the toold you get without using an IDE to hide it all from you.

In the clientside diagram(s), you wouldn't.
You'd only include a highlevel package containing shared classes.

In the serverside(s), you don't include the client and only a highlevel package with those same shared classes.

You'd have a third set containing detailed diagrams of those shared classes.

That immediately forces you to think about the design of your application, cutting it up into distinct (reusable) components.

Short answer: you don't.
Way too complex to achieve what you can do far more easily with just 2 commands.
Which those are I leave to you, the API documentation is your friend.

that is correct. A class is loaded when first needed by the JVM (or more precisely the classloader, of which there may be several inside a single JVM) and not unloaded until the classloader terminates (which in many environments happens only on JVM termination, given that the classloader is itself usually a class, the only exception being the root classloader which loads the classloader that loads the rest of the classes and classloaders).

Read the relevant sections of the JLS and JVMS to get more details, it gets rather gory :)

I don't use diagrams (especially implementation diagrams like class diagrams) that ridigly.

They're great for visualising concepts and planning things, but don't see them as the final product.
For me they're more quick sketches of what I'm intending to do, rather than a dictate of what's really there.

They'll therefore also be rather sketchy, often containing only the bare minimum in fields and methods needed to convey the core functionality of a class rather than every smallest detail.

Overly complet diagrams are a pain, precisely because of the effort needed to keep them in synch with the code.
And remember that documentation that's out of synch with the thing it documents is often worse than no documentation at all as people will not know the documentation is incorrect and therefore assume that your code does what the documentation says it does (which obviously it won't if the two are out of synch).

Class diagrams should be thrown away IMO after the code is complete.
When needed they can always be recreated from the code, every halfway decent UML system has an import feature for that.

A major problem in many large organisations though is too great a separation between the people thinking up the system architecture and the people implementing it.
A mass of documents and diagrams (often way too detailed for a document that should be an architectural overview rather than documentation for an existing system) is shoved down the …

quick hacks lead to big problems later on...

Class.forName("MySql ODBC 3.51 Driver");

and you wonder why it won't load?
Go read the documentation...

You did some modification to the code JBuilder generates for you I see ;)

You will need to design your screen and hook up the controls to enable the interaction.
You should also go for a proper object oriented approach, which would have the RMI functionality separate from the user interface.

That way you can do something like:

if (!GraphicsEnvironment.isHeadless()) {
            // graphical environment available, launch GUI for interactive mode

            MainFrame frame = new MainFrame(serverProps);
            frame.validate();
            Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
            Dimension frameSize = frame.getSize();
            if (frameSize.height > screenSize.height) {
                frameSize.height = screenSize.height;
            }
            if (frameSize.width > screenSize.width) {
                frameSize.width = screenSize.width;
            }
            frame.setLocation((screenSize.width - frameSize.width) / 2,
                              (screenSize.height - frameSize.height) / 2);
            frame.setVisible(true);

        } else {
            // no graphical subsystem, launch server without interactive mode
            // using the values from the properties file
            Server server = new Server(
                Integer.parseInt(serverProps.getProperty("rmi.port")),
                serverProps.getProperty("server.file"),
                serverProps.getProperty("rmi.service"),
                Integer.parseInt(serverProps.getProperty("server.timeout")));
            try {
                server.startServer();
            } catch (RemoteException ex) {
                System.err.println(server.getMessages());
                return;
            } catch (IOException ex) {
                System.err.println(server.getMessages());
                return;
            }

        }

to allow your server to also function on a machine that has no graphical shell using a configuration file to initialise it.
Mind I've not yet been able to actually test that code to see if the headless mode works, but I see no reason why it shouldn't.

A class diagram has no direct relationship to the usecase diagrams.

A single usecase may use classes from several class diagrams (typically you'd have one class diagram per package for example, plus several linking packages together maybe).
similarly a single class diagram may provide classes that are used on several use cases (or even all use cases in case of highlevel classes and interfaces).

blueJ doesn't teach Java (it hides pretty much everything from the user), and is way too limited for serious use.

Eclipse is nice, but nothing I've used beats JBuilder. IDEA is supposed to be very very good as well, but I've not used it yet (am somewhat planning to purchase it, maybe next year or 2008).

there is no best, just personal preference.

I would recommend Netbeans. The last versions are very good. Netbeans also gives J2EE, SOA, Mobility and other things for free which may be interesting for you.

Why do you recommend Netbeans to someone who tried it and wants something else?

mkDirs will create the entire path you pass it, including non-existent directories.
So if you pass it "/usr/myapp/data/20060407/xml" and only /usr/myapp" exists, it will first create data, then 20060407 under that, and finally xml under that to complete the structure.
mkDir would just give you an error.

That's correct. And if you want to create a complete directory path even if parts don't exist, use mkDirs.

Some advise though: don't hardcode path separators. Use the system property "path.separator" instead to make your code platform independent (and of course always use relative paths to some system property).

yup, they can just decide to block any package that doesn't come from an allowed host for example.
That's exactly how corporate firewalls often work.
Or block specific protocols.
Or both.

destroying the form will not end the application.
Use application.terminate to do that.
That will also destroy any remaining objects at the same time, releasing (or it should) all application memory.

But what do you mean by "Delphi will not write the exe"? Sounds like you are having some serious misunderstanding about how Delphi works.

That's indeed the method you want, but most likely you're not calling it correctly.

Without knowing what you're doing and what's happening as a result it's impossible to say more than that.

XBox uses a feature limited version of Windows :)

That would all depend on your hardware platform and operating system.
OpenGL is pretty much platform independent, DirectX is much used but only for Windows.

For other operating system custom libraries often exist as well, or can be created.

A JPanel has to exist inside something else.
To show it on screen that will usually be a JFrame or a JDialog.

When you have one of those you can easily display them, both have methods to achieve that.

You're moving into an area where you will have to write a proper design document, storyline, and things like that before you even think of coding.

As to why C++ is more common in game programming, that's pretty much historical.
In the beginning Java just lacked the capabilities in both APIs and performance to be of much use for graphics and game development. In fact, C++ has only in the last few years taken over from C and Assembler as the main language used...
Java is used in game development, but mainly as an internal scripting language for the game engine to control things like character behaviour.

and yes, I know that sounds elitist ;)

But the platforms that don't have a 1.5 JVM are mainly mainframe and big Unix servers running things like AIX and OpenUnix.
Those run mainly custom software.

no, since there is no reason for most of your potential users not to have a 1.5 JVM installed.

There are a few operating systems that don't have one available, but not a lot of people use those, certainly not a lot of people using public domain software.

yes, but you're going to have differences in path separators, file separators, etc. etc. to take into account.

And what if javac is not on the path on the machine? You're in trouble then...