Posts by jwenting

that said, whizlabs are a reliable company with a quality product.
The other one may be, but they're unknown to me after almost 15 years working with Java.

you should synch the data between your client and server to ensure both are talking the same language.
There should be no problem if both client and server are using the same JVM version, which in your case apparently is not happening.

That's the main problem using any serialisation system when you rely on external parties to provide the classes you're (de)serialising, when the classes change on one side but not the other things are out of whack.

One solution is to switch to another data transfer system completely. For example you're transferring serialised ImageIcons, you could instead transfer only the images contained in those icons with maybe a message header containing information like sizes, and have the client recreate an ImageIcon of its own. That way you avoid sending core library classes completely (I don't think simply wrapping them would solve anything as there'd still be a serialised ImageIcon in the datastream that needs to be deserialised).

I've never had this problem myself, but then the only stuff I usually send serialised are Strings and maybe some Integers, those are pretty stable.
For more complex data structures it's either webservices or some other mechanism that separates the data from the language specific data structures.

If you're using generated serialversionids you can expect that to happen. Those are generated on the fly and the generation can and often will yield different values when using different jvms.
This is well published and there's no excuse for you to not have known this.

It's quite possible a change in a class used by one of your serialised classes caused your serialversionids to change even if the generation algorithm stays the same, and that's something a minor (bugfix) update can quite possibly introduce.

Which is why no serious project/product will ever rely on generated serialversionids except maybe in very early stages of development.

even if the device is his, the connection isn't. He'd be stealing bandwidth if he ever succeeded.

The router does the routing of incoming messages to anything residing behind it.
Unless each client is accessing your server through a different TCP or UDP port there's no way for the server to distinguish them unless you send specific information in each request/response to the client and the client then returns that information (which is how session management in http works, roughly).

yes, they can get new values during new method calls, but will be preserved for the instance of the method local inner class instance created by the previous call.

well, that's the facebook generation for you...

See page 182 of the Java Language Specification, 3rd edition (may be a different page in other editions).

Basically, an inner class contains an implicit reference to the outer class instance that creates it, thus preventing that instance from going out of scope (and thus getting garbage collected).
However, method local variables do go out of scope unless they're declared final, in which case they're preserved between method calls.
For an instance of a method local inner class to be able to refer to those method local variables after the method goes out of scope (say, if you return the instance from the method), those method local variables thus have to be declared final else they will no longer exist when needed by the inner class instance that refers to them.

not urgent.

"because if raising (around) 500Mb used memory then IDE freeze"

An IDE that needs such a button pressed regularly else it freezes or crashes is bugged.
Q.E.D.

It's a really really fun place with flowers and balloons and lots of sunshine. I really suggest you donate to find out. :)

And black helicopters :)

aplologize me for hiJacking this thread but,

@ jwenting wrote

If you're programming raw sockets, you can only ever send bytes. Java also lets you send Strings and integers, because it handles the conversion to bytes for you.

are you sure that that is valid for Non-ACSII chars, maybe then I something ***, or I'm wrong isn't there something as InputStream...

yes, I am sure. Everything gets translated to bytes as only bytes can get sent over the line :)

The Stream reads the bytes but doesn't know what to do with them. If you expect Strings, wrap the Stream in an InputStreamReader.

Sure, you could use a library that uses another networking stack, but you'd be limiting your audience to people using networks using that stack.

If you're programming raw sockets, you can only ever send bytes. Java also lets you send Strings and integers, because it handles the conversion to bytes for you.
You can of course send anything by serialising it, that's one of the things serialisation was created for.

Pretty much every other networking library you could bolt onto any programming language will work on top of sockets, so you'd be using them anyway :)

if you did that you couldn't sit on it at all... Best get a new chair first, THEN break the old one, much more practical ;)

For that, contact human resources or facilities management, depending on the reasons the chair is bad (if it's merely broken, facilities should provide a replacement, if you need a special chair for health reasons like a bad back, human resources is the place to be).

super secret stuff mere mortals can't handle. Their brains'd explode out of their ears, which leaves a terrible mess (we experimented, why do you think the total number of users is so much lower than the active number of users?).

Setting the classpath doesn't mean that it is wrong..

Setting the classpath at system level is wrong. It invites trouble with relying on libraries you don't realise you have in your classpath, including version conflicts.
Adding rt.jar to the classpath is wrong as well. It's not only completely unnecessary, it's harmful especially if you have several JDKs installed.

IOW, you're telling him to do something that's just plain wrong for 2 reasons.

"copy the path of rt.jar file and set the class path in environmental variables"

WRONG. Not needed, not recommended, don't do this.

That's not a Java problem, it's a problem with your understanding (or lack thereof) of your operating system.
You need to add the location of the java.exe and javac.exe to your system path environment variable (they're in the same directory).

There's for example cases where for performance reasons (and yes, those are rare) the overhead of a method call is simply too much.
Of course you can still make them safe from change by making all data members final, so they can not be changed after setting them in the constructor :)

never say never :)
There are special cases in which it's required, but they're special cases.

It's certainly acceptable and even desirable if not required in some specific cases.
If and when you run into such cases, you'll know them as there will be no way to get the application compiling and/or running when doing things in other ways.

any logic used when creating a graph using only JSP is utterly flawed by definition and therefore not worth discussing.

read up on them, and experiment.

gosh, and you're surprised that you can't access a document if you don't know where to find it?

What'd a taxi driver say when you go to him and tell him "I'd like to visit a friend of mine, but I don't know where he lives or what his name is, I think it was a village with an "e" in the name somewhere"?

your DBAs will just love you if you keep firing off queries just to check for new data constantly... NOT!

Far better to only check when you need to generate a new screen of data for display purposes or need data for a batch job.

Is the + necessary? If so that was my mistake when I tried doing it that way. The error I got was an incompatible types error. I'll try it again tomorrow with +14 and hopefully that solves it. Why must it have a + though?

No, the + is absolutely NOT necessary anywhere in Java.

it's your project. And the first step is for you to research what you want to do.
Just asking others to make that decision for you is NOT the way to go forward.
What'll you do next, ask us to write the design document, implement it, document it, and write your thesis for you as well?

cut up the main method into several methods. One to handle input, one for processing it, one for output (maybe, not strictly needed for something this trivial but good practice).
In your main, just have an infinite loop that reads input, processes it, and produces output, with a terminating condition (for example, have it terminate when receiving a specific input).

you mean the client of your web application? There is no Java running there, only Javascript which knows nothing about all that.
The only thing you can do is set a cookie, which is automatically handled for you (if possible and needed) by the server based on the content of the serverside session object.

If you mean you have a Java program running outside an application server environment, you won't have access to the session management features of the application server, obviously, and will have to implement something similar yourself (or search the net for something created by others).

http://java.sun.com and check out the Java tutorial.

read and understand the Java tutorial and all will become clear (or at least clearer than it is now) to you.

fix the bug in your application that causes it to require inordinate amounts of memory.
I can guarantee you that whatever amount you feed it with you'll run out eventually unless you fix that bug.

and to always use the system properties to retrieve operating system specific things like that if you have to.

you have an instance of a class, you can call methods on that instance if you have a reference to it.
If you don't maintain a reference, you should start figuring out how to do that (or how to get the JDesktop to give you one, no doubt it has functionality to do just that).

According to your opinion, It means that as the file size increase the compression ratio will also increase(A common understanding).

No, you read me wrong.
And that "common understanding" (if it exists) is also wrong.
While most algorithms may become more efficient with more data to handle, that's only up to a point.
For the first few kilobytes of data for example they might become slightly more efficient, then reach their limit.
But that doesn't mean all larger files compress better than all smaller files given the same algorithm (or even in general).
A 1kb file containing plain text and all the same ASCII code for example will compress very well using most algorithms. A 1kb JPEG image otoh will likely not compress at all (and may even expand in size) when compression is attempted (this of course due to the fact that it's already compressed as part of the JFIF algorithm that created the file content).

no doubt it's too late now.

yup, if you code it correctly that should be possible.

That's all that can be said without knowing what convoluted code you produced to generate the behaviour you describe.

not really, no.
Of course you need enough data in the original file to be able to compress it at all.
A 1 byte file for example can't be compressed.

Apart from that, the compression algorithm might add more overhead in markers and stuff to the compressed file than it removes by compressing the orignal data.
That however is independent of file size, can happen with any size input (but might be more readily apparent with small input files than with large ones on average).

It's just another file, of course you can load it.
And if you have the right libraries you should be able to visualise the models as well.
I guess such libraries would exist (try some search engines :) ), if not you'll have to write them (which would I guess not be a trivial undertaking, certainly not if you want to be complete and have it perform).

not urgent

learn a bit about Java and you'd know the answer to that.
I suggest you reread your entire courseware and the Java tutorial from Sun's website, and actually study what's there.

tell your "friend" to do his own homework.
Though of course we all know your "friend" is really you.

NoCodeTagsError at line 1, program terminated.
OutOfCheeseError at line 0, redo from start

and no stupid things like hardcoding operating system specific file locations :)

You can access a Hashtable using an Iterator, retrieving Entry objects containing key/value pairs.
For each of those, retrieve the key and value and insert it into the database using standard jdbc functionality.

You'll need to learn some Java to be able to do that, can't be helped. So you will need to "do Java".

Applets can only make network connections back to the server on which they are hosted unless they are signed, so yes you need to make it a signed applet.

Wrong, it's "super easy" for anyone who knows a tiny bit about Java.
No Hibernate or other persistence framework needed, just common sense.

In fact it's so trivial the only way to be more specific than I already was would be to give him all the code to actually do it, and I'm not going to do that.

use the keys from the hashtable as keys in your database, the values as datafields.
Effectively a hashtable can be mapped directly to a database table like that.
You will have to somehow ensure you get unique primary keys if you want a primary key on the database table, but that is usually handled with some sort of autoincrement field.

see my reply from 27 november 2007...

NoCodeTagsError at line 0, redo from start