String manipulation
Hi all, I have a dummy question regaring a double-quoted string written in multiple line. Here is what I have been doing: stmt.executeQuery( "SELECT COF_NAME, " + "SALES FROM COFFEES " ); Is there a way to to eliminate the '+' sign by doing something like below? stmt.executeQuery( "SELECT COF_NAME, \ SALES FROM COFFEES " ); I know the code cannot be compiled, but is there any substitution to the escape character above? Many thanks in advance. __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM 1.3 full release
Some of u managed to download the packages?? I managed to register me, give them all my infos :-( and after loosing time I came across this ugly page filled up with broken links. Would realy like to know if they had there links ever working thanks patrick -- - Save software competition, use Linux and Java! mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM 1.3 full release
Thanks to IBM for getting a 1.3 out. But that registration procedure really sucks. >Would realy like to know if they had there links ever working Yep, I managed to download it. Haven't even opened it up yet. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ Make your computer useful 24 hours a day: http://www.popularpower.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM 1.3 full release
> Some of u managed to download the packages?? I did download the RPM package (27+Mb) without a problem. I installed it but had time for nothing else. -- Julio Cesar Aguilar Cabrera [EMAIL PROTECTED] Laboratorio Nacional de Informatica Avanzada Xalapa, Veracruz, Mexico. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IBM 1.3 full release
Julio Cesar Aguilar Cabrera wrote: > > > Some of u managed to download the packages?? > > I did download the RPM package (27+Mb) without a problem. > I installed it but had time for nothing else. > Downloaded the tarball version, put it where I wanted it, and tried the Java2D demo. After the intro ran for awhile a nullPointer exception was spit out and the rest of the demo was incredibly slow. -- wYRd.:|:[EMAIL PROTECTED]:|:.prohibitions void where offered de recta non tolerandum sunt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Serious bug in System.identityHashCode() found.
Hi all. There seems to be a really serious bug in the System.identityHashCode() method in all > JDK 1.2 releases derived from Sun code. The problem only shows up in "high load" situations. Basically, two different Java objects of the same class can return the exact same unique id from the System.identityHashCode() method. I have a test that reproduces this bug every time in > JDK 1.2 JVMs. Steps to reproduce: 1: Download Jacl (Tcl shell implemented in Java): ftp://ftp.scriptics.com/pub/tcl/java/jacl126-noarch.zip 2: unzip jacl126-noarch.zip, the following files are created: lib/tcljava.jar lib/jacl.jar Readme.jacl 3: Set your CLASSPATH to include the two jar files and ".". setenv CLASSPATH `pwd`/lib/tcljava.jar:`pwd`/lib/jacl.jar:. 4: Download the crash test from: http://www.mail-archive.com/[email protected]/msg00847/ReflectCrash.zip 5: unzip ReflectCrash.zip, the following files are created: ReflectCrash ReflectCrash/MyCmd.java ReflectCrash/MyObjects.java ReflectCrash/mytest.tcl ReflectCrash/SomeObject.java ReflectCrash/MyCmd.class ReflectCrash/SomeObject.class ReflectCrash/MyObjects.class ReflectCrash/mytest.results 6: cd to the ReflectCrash and run the crash test. java tcl.lang.Shell mytest.tcl This test case will create a bunch of Java objects and hash the objects into a Hashtable based on the class name and the uid returned by System.identityHashCode(). For example, "SomeObject.1512497281" would map to an instance of the class SomeObject with the uid 1512497281 as returned by System.identityHashCode(). If two different objects return the same hash code, they will overlap. This causes an assert to fail and a message like this will be printed: Exception in thread "main" tcl.lang.TclRuntimeError: (find) table entry "SomeObject.1512497281" mapped to an invalid entry, I have been able to reproduce this error in > JDK 1.2 releases from Sun (including blackdown and IBM ports). This also happens on all platforms, NT, 95, Linux, and so on. This error does not show up with JDK 1.1.8 from blackdown (or any other JDK 1.1 JVMs for that matter). So far, I have identified a couple of workarounds. I could just require that everyone use a JDK 1.1 release. I could also require that people use Kaffe (it does not have the bug). The final option would be to write my own UID() method that would try to do something to detect a duplicate id and generate a unique one. Each of the above options is sub-optimal. Comments anyone? Mo DeJong Red Hat Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Serious bug in System.identityHashCode() found.
Mo DeJong wrote, > There seems to be a really serious bug in the > System.identityHashCode() method in all > JDK 1.2 releases > derived from Sun code. The problem only shows up in "high > load" situations. Basically, two different Java objects of > the same class can return the exact same unique id from the > System.identityHashCode() method. Why is this a bug? The only requirement on a hashCode (system or otherwise) is that two == or .equal() objects should have the same hashCode. There's no requirement that != or !.equal() objects should have different hashCodes. Apart from anything else, hashCodes are ints, so there are at most 2^32 distinct ones. A 64 bit implementation could support more that 2^32 objects, in which case there'd have to be some collisions. > So far, I have identified a couple of workarounds. I could > just require that everyone use a JDK 1.1 release. I could > also require that people use Kaffe (it does not have the > bug). The final option would be to write my own UID() method > that would try to do something to detect a duplicate id and > generate a unique one. > > Comments anyone? You shouldn't expect System.identityHashCode() to be usable as a UID. Assuming otherwise is non-portable ... as you've just discovered. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England [EMAIL PROTECTED] http://www.cromwellmedia.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
--On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
wrote:
> Exception in thread "main" tcl.lang.TclRuntimeError:
>
> (find) table entry "SomeObject.1512497281" mapped to an invalid
> entry,
I'm not familiar with the Jacl code base, but this error does not jibe with
my own experiences with this method under heavy load situations. Is it
possible that this is a bug in the Jacl engine? A real easy test would be
take the two object which are supposedly using the same identity hash and
test if the two objects are indeed identical.
Other items worth noting:
1) By the strictest of interpretations of the specifications of the
specifications, it is in fact legal for two different objects to return the
same value for System.identityHashCode() so long as you don't test the
values at the same time.
2) If the previous object has been garbage collected, this in theory frees
up the hash code for another object to use. Make sure that you really have
two objects and this is not just a left over value from an already GC'd
object.
My suspicion is that you are discovering that the JDK 1.2+ VM's move
objects around in memory when they GC. This potentially results in
different return values for System.indentityHashCode() for the same object
before and after a GC.
So the assertion that:
static MyClass {
private static MyClass firstInstance = new MyClass();
private static int fiHashCode = System.identityHashCode(firstInstance);
public bool assert() {
if (this == firstInstance)
return true;
else
return fiHashCode != (System.identityHashCode(this));
}
}
MyClass.assert() will never return false is not true.
--Chris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
> "Mo" == Mo DeJong <[EMAIL PROTECTED]> writes: Mo> There seems to be a really serious bug in the Mo> System.identityHashCode() method in all > JDK 1.2 releases Mo> derived from Sun code. The problem only shows up in "high Mo> load" situations. Basically, two different Java objects of the Mo> same class can return the exact same unique id from the Mo> System.identityHashCode() method. I have a test that Mo> reproduces this bug every time in > JDK 1.2 JVMs. It's no bug, the behavior is absolutely legal. >From the API documentation for java.lang.System: doc> public static int identityHashCode(Object x) doc>Returns the same hashcode for the given object as doc>would be returned by the default method hashCode(), doc>whether or not the given object's class overrides doc>hashCode(). The hashcode for the null reference is doc>zero. and for java.lang.Object: doc> public int hashCode() [...] doc>The general contract of hashCode is: [...] doc> * If two objects are equal according to the doc> equals(Object) method, then calling the doc> hashCode method on each of the two objects must doc> produce the same integer result. doc> * It is /not/ required that if two objects are doc> unequal according to the doc> equals(java.lang.Object) method, then calling doc> the hashCode method on each of the two objects doc> must produce distinct integer results. doc> However, the programmer should be aware that doc> producing distinct integer results for unequal doc> objects may improve the performance of doc> hashtables. (The latter point is redundant but makes the situation more obvious). Mo> I have been able to reproduce this error in > JDK 1.2 releases Mo> from Sun (including blackdown and IBM ports). This also Mo> happens on all platforms, NT, 95, Linux, and so on. This error Mo> does not show up with JDK 1.1.8 from blackdown (or any other Mo> JDK 1.1 JVMs for that matter). The implementation of Object.hashCode() was changed in 1.2 for security reasons. Mo> So far, I have identified a couple of workarounds. I could Mo> just require that everyone use a JDK 1.1 release. I could Mo> also require that people use Kaffe (it does not have the Mo> bug). It's no bug. Mo> The final option would be to write my own UID() method that Mo> would try to do something to detect a duplicate id and Mo> generate a unique one. That's the better solution, System.identityHashCode() simply doesn't guarantee unique values. Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://www.blackdown.org/java-linux.html JVM'01: http://www.usenix.org/events/jvm01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Serious bug in System.identityHashCode() found.
--On Tuesday, July 04, 2000 1:37 AM +0100 Miles Sabin <[EMAIL PROTECTED]> wrote: > Mo DeJong wrote, >> There seems to be a really serious bug in the >> System.identityHashCode() method in all > JDK 1.2 releases >> derived from Sun code. The problem only shows up in "high >> load" situations. Basically, two different Java objects of >> the same class can return the exact same unique id from the >> System.identityHashCode() method. > Why is this a bug? The only requirement on a hashCode (system > or otherwise) is that two == or .equal() objects should have > the same hashCode. There's no requirement that != or !.equal() > objects should have different hashCodes. While this is true of generic implementations of hashCode(), Object.hashCode() does have this additional constraint from the spec: "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects." For most practical implementations of VM's this means they just return the pointer value, so on systems with less than 2^32 bytes of virtual memory, you can usually get away with the assumption that if (a != b) System.identityHashCode(a) != System.identityHashCode(b). > You shouldn't expect System.identityHashCode() to be usable as > a UID. Assuming otherwise is non-portable ... as you've just > discovered. This I agree with completely. If you really must implement your own. System.identityHashCode() can be used, with limitations, to implement an identity hash table, but you have to be VERY careful and aware of the potential problems involved. In general, using the standard hashCode() methods to implement hash tables in the like is dangerous business. I do think it's unfortunate that the java.lang.* hierarchy doesn't have something which provides a guarunteed unique identifier for an object in memory. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
On Mon, 3 Jul 2000, Christopher Smith wrote:
> --On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
> wrote:
> > Exception in thread "main" tcl.lang.TclRuntimeError:
> >
> > (find) table entry "SomeObject.1512497281" mapped to an invalid
> > entry,
>
> I'm not familiar with the Jacl code base, but this error does not jibe with
> my own experiences with this method under heavy load situations. Is it
> possible that this is a bug in the Jacl engine? A real easy test would be
> take the two object which are supposedly using the same identity hash and
> test if the two objects are indeed identical.
I do not think this is an error in any Jacl code, but if you can
prove me wrong please do so. The error condition is only raised
if the two objects have the same identityHashCode and yet
fail the "obj1 == obj2" test.
If you want to see the source, it is in the method findInReflectTable()
in the file tcljava/src/tcljava/tcl/lang/ReflectObject.java, the
CVSROOT is :pserver:[EMAIL PROTECTED]:/cvsroot and the module
name is tcljava.
Here is the extended output from the error. Note how two different
objects (you can tell they are different because the == test and
the .equals() tests both fail) both return the identityHashCode
1512497281.
(find) table entry "SomeObject.1512497281" mapped to an invalid entry,
Searched (Class = "SomeObject" identityHashCode = "1512497281" hashCode =
"1512497281")
Found ( refID = "java0x464c" Class = "SomeObject" identityHashCode =
"1512497281" hashCode = "1512497281")
Equality Tests ( Class == "true" Object == "false" Object.equals() ==
"false" I
nterp == "true")
at tcl.lang.ReflectObject.findInReflectTable
at tcl.lang.ReflectObject.makeReflectObject
at tcl.lang.ReflectObject.newInstance
> Other items worth noting:
>
> 1) By the strictest of interpretations of the specifications of the
> specifications, it is in fact legal for two different objects to return the
> same value for System.identityHashCode() so long as you don't test the
> values at the same time.
http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#hashCode()
http://java.sun.com/j2se/1.3/docs/api/java/lang/System.html#identityHashCode(java.lang.Object)
The SDK docs (noted above) say the following:
"As much as is reasonably practical, the hashCode method defined by class
Object does return distinct integers for distinct objects. (This is
typically implemented by converting the internal address of the object
into an integer, but this implementation technique is not required
by the Java TM programming language.)
> 2) If the previous object has been garbage collected, this in theory frees
> up the hash code for another object to use. Make sure that you really have
> two objects and this is not just a left over value from an already GC'd
> object.
No, the other object has not been garbage collected. How could I
compare one object to another if I did not have a valid ref
sitting around?
> My suspicion is that you are discovering that the JDK 1.2+ VM's move
> objects around in memory when they GC. This potentially results in
> different return values for System.indentityHashCode() for the same object
> before and after a GC.
The object in the table might have been moved by the GC, but it still returns
the same hash code as it did when I put it in the table. You can see
that this is the case from the extended output where I call the
hash code methods again on the searched and found objects and they
both return the same id.
> So the assertion that:
>
> static MyClass {
> private static MyClass firstInstance = new MyClass();
> private static int fiHashCode = System.identityHashCode(firstInstance);
> public bool assert() {
> if (this == firstInstance)
> return true;
> else
> return fiHashCode != (System.identityHashCode(this));
> }
> }
>
> MyClass.assert() will never return false is not true.
>
> --Chris
No it is more like this (some quick pseudo code).
void add(Class c, Object obj) {
StringBuffer sb ...
Hashtable table = ...
sb.append( c.getName() );
sb.append( '.' );
sb.append( System.identityHashCode(obj) );
Object intable = table.get( sb.toString() );
if (intable != null && intable != obj) {
assert();
} else {
table.put( sb.toString(), obj );
}
}
The check is not to see if the same hash code is
ever reused, it is only to see if two different
objects has to the same id at the same time.
My reading of the docs seems to indicate that
this is exactly what the identityHashCode()
methods is designed for. Would you agree?
Mo DeJong
Red Hat Inc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
On 4 Jul 2000, Juergen Kreileder wrote: > It's no bug, the behavior is absolutely legal. ... > The implementation of Object.hashCode() was changed in 1.2 for > security reasons. ... > It's no bug. > > Mo> The final option would be to write my own UID() method that > Mo> would try to do something to detect a duplicate id and > Mo> generate a unique one. > > That's the better solution, System.identityHashCode() simply doesn't > guarantee unique values. > > > Juergen Ok, so if System.identityHashCode() does not guarantee unique values for different objects, then what is the point of having the System.identityHashCode() API to begin with? Mo DeJong Red Hat Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Serious bug in System.identityHashCode() found.
On Tue, 4 Jul 2000, Miles Sabin wrote: > Mo DeJong wrote, > > There seems to be a really serious bug in the > > System.identityHashCode() method in all > JDK 1.2 releases > > derived from Sun code. The problem only shows up in "high > > load" situations. Basically, two different Java objects of > > the same class can return the exact same unique id from the > > System.identityHashCode() method. > > Why is this a bug? The only requirement on a hashCode (system > or otherwise) is that two == or .equal() objects should have > the same hashCode. There's no requirement that != or !.equal() > objects should have different hashCodes. > > Apart from anything else, hashCodes are ints, so there are at > most 2^32 distinct ones. A 64 bit implementation could support > more that 2^32 objects, in which case there'd have to be some collisions. > > > So far, I have identified a couple of workarounds. I could > > just require that everyone use a JDK 1.1 release. I could > > also require that people use Kaffe (it does not have the > > bug). The final option would be to write my own UID() method > > that would try to do something to detect a duplicate id and > > generate a unique one. > > > > Comments anyone? > > You shouldn't expect System.identityHashCode() to be usable as > a UID. Assuming otherwise is non-portable ... as you've just > discovered. I don't get it. That was the whole point of adding the System.identityHashCode() method to 1.1. It was designed to return a UID in the case that a class overloaded the hashCode() method. Now folks seem to be saying "oh, yeah that was changed for 1.2". Changed to what? How would you suggest I generate a UID for two different object of the same class that return the exact same hash code? I can't get the memory location to implement my own UID method. I guess I could create another table of objects that map to the same hashCode but are not equal. It might also be possible to map every id to a Vector instead of directly to the object. Both of these "solutions" would be really ugly. I am really getting sick of Sun changing the APIs in really sneaky ways. Mo DeJong Red Hat Inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious bug in System.identityHashCode() found.
> I don't get it. That was the whole point of adding the > System.identityHashCode() method to 1.1. It was designed > to return a UID in the case that a class overloaded > the hashCode() method. Now folks seem to be saying "oh, > yeah that was changed for 1.2". Changed to what? > How would you suggest I generate a UID for two > different object of the same class that return > the exact same hash code? I can't get the memory > location to implement my own UID method. Nope, the whole point of System.identityHashCode() was added so that == had equivalent operators to Object.equals(Object). Essentially it allowed you to create an identity hash table. If they had ment it to be a uid they would have called it Object.getUid(). ;-) > I guess I could create another table of objects > that map to the same hashCode but are not equal. > It might also be possible to map every id to > a Vector instead of directly to the object. > Both of these "solutions" would be really ugly. > I am really getting sick of Sun changing the > APIs in really sneaky ways. They didn't change the API. The docs have been the same for quite some time. They did fix a conflict in the spec that said the following: 1) Object.equals(Object) returns true if two objects are equivalent. 2) Object.hashCode() always returns the same value for the same object. 3) if a.equals(b) then a.hashCode() == b.hashCode() They realized that #2 couldn't always be true if #1 & #3 were true. That's the only change I'm aware of with this API. Standard hashtables are based on Object.equals() and as such deal with the hashCode collision issue. So, if you just use a standard Hashtable (or Set depending on your needs), make sure you're using identityHashCode() and =='s, then collisions will be dealt with for you. The thing to keep in mind is that hashCode() is generally speaking an optimization, something that speeds up lookups, rather than being an outright property of an object. If you need is simply have an ID based lookup mechanism for objects in memory, you can just use a double-WeakHashtable and some kind of a counter. --Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
