aspose file tools*
The moose likes Java in General and the fly likes Strings on HP-UX Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Strings on HP-UX" Watch "Strings on HP-UX" New topic
Author

Strings on HP-UX

Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi all,
I know this is not the best way to compare String but as they are literals so it is possible to get away with it.

On windows you always get true. However I saw a fault today that looked as if it was being caused due to the comparision returning false. The person who reported the fault are on HP-UX. I am in the process of getting a HP-UX test system set up so I can try it myself.
My question is, does anyone know a fault within a JVM on HP-UX that could cause false to be returned?
Is there an easy way of searching the fault database for HP-UX JVM?
Thanks
Chris
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

If this were true of HP's JVM, then it's definitely a bug, as this is not compliant with the JLS.
I would think HP would have their own bug database, although it may not be public. Since it's HP's code, Sun obviously isn't going to track their bugs for them.


[Jess in Action][AskingGoodQuestions]
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
It's my understanding of the Java Language Specification that ("10" == "10") may be either true or false. It's up to the individual JVM whether to reuse strings or not; if it doesn't, the two strings may be stored in different locations in memory and thus not be "==" even though their individual characters may match.
You should use "equals" to compare strings rather than "==". In this case:
System.out.println(m.equals("10"));
should always return true in your code snippet above.
Warren
[ March 09, 2004: Message edited by: Warren Dew ]
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi Warren
Thanks for you comment. I am aware that using == is not the best way of comparing Strings, but I am looking at an code that has been working fine for years on windows. However someone is trying to use it on HP-UX and are now having problems. It looks like it could be this issue but I can not find any proof.

It's up to the individual JVM whether to reuse strings or not;

Do you have any proof of this?
Thanks
Chris.
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
I have looked up the JVM Specs and have found:

The Java language requires that identical string literals (that is, literals that contain the same sequence of Unicode characters) must reference the same instance of class String.

As it is part of the specs I would say all JVMs must follow this. Would HP be able to call their a JVM a JVM if it did not follow this spec?
Chris.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Chris,
It's my understanding that the JLS indicates that two String which embody the same sequence of characters must return true when compared to each other using the .equals method.
Further, the spec says that two String(or any two objects) which point to the same address in memory must return true for == comparisons.
However, the specs does not state that two Strings which are created sequentially must have the same memory address: it just so happens that they do on windows. Thus, a JVM can be perfectly spec compliment and still not display the sort of behavior you're looking for.
If the theory is that a given JVM is non-spec compliment because it doesn't return true from == comparisons, then the theory must be supported by evidence (which is lacking), or the theory must be dismissed.
So, basically, the proof lies in the fact that there is no explicit requirement.
All best,
M


Java Regular Expressions
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi Max,
Thanks for you help so far. I have gone back and re-read chapter 5.4 of the specs. I am still a little confused:
In my example the String 10 would have been added to the constant pool. My understanding of the specs is that the compiler would have found the String "10" in the pool when I did the comparison and should have returned true.
However are you saying that the String in my comparison would not be in the same memory location as the "10" from the assignment?
I really want to get this issue right before I go to my boss and tell him we have to pull all the version of the app.
Thanks
Chris.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Actually, I went back and read section 5.4 of the JVM spec, and my reading is the same as Chris': as long as the compiler flags two strings as literal constants, the VM is required to resolve their references to the same memory address. So it actually might be a problem in the JVM.
On the other hand, it's also possible that it's a compiler error - either taking shortcuts with unicode or optimization, or not flagging the struct as a constant. In addition, I didn't find any information on how long that requirement has been in the JVM spec, so it might not apply to older virtual machines.
And of course it might be some other bug that just looks like it's in this section of code, or we could both be reading the specs wrong....
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Max]: So, basically, the proof lies in the fact that there is no explicit requirement.
You mean, other than JLS2 3.10.5 (especially here), JVMS2 5.1 (especially here), and the API for String's intern() method?
Chris, both the JLS and JVMS sections above include sample code, and specify the required output. You can use these on your test machine when you get it. Though the code you already provided is good enough - if (m == "10" ) returns false, the JVM is broken, in violation of spec, kaput, finito, etc.
[Warren]: In addition, I didn't find any information on how long that requirement has been in the JVM spec, so it might not apply to older virtual machines.
Well the second editions of the JLS and JVMS have been out a long time. But these requirements were in place in the first editions of each as well - see:
JLS1 3.10.5
JVMS1 5.4
If you're dealing with a JVM that predates the first editions of these specs, well, there's really not much hope of expecting it to comply with anything I think...
[ March 09, 2004: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

So, what you're all saying is, I was right the first time
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, almost all of us are saying that, yes.
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi all,
I found out what was causing the problem with the ==. We have started to obfuscat our code with klassmaster before it goes out.
One of the features of this tool is String Encryption.

Zelix KlassMaster's String Encryption technology encrypts your String literals where they are stored in the Constant Pools of your class files. It then adds fragments of code to your classes so that your Strings are decrypted at runtime.

So what this means is that String can not be compared by memory location. Therefore my test example returns false.
Thanks everyone for your help with this.
Chris.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Aha! Good to know. Thanks for the followup.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Hi Chris, Warren,
You're correct, the JLS does require that two strings which resolve to the same literal value return true for ==, as Jim pointed out: I actually was not aware of this, so now I know a bit more than yesterday.
What I was getting to was that the JVM is free to return true or false for the following


Of course, if I had read your question just a little more carefully, I wouldn't have led you down a dark path
All best,
M
[ March 10, 2004: Message edited by: Max Habibi ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Originally posted by Max Habibi:

What I was getting to was that the JVM is free to return true or false for the following...

I don't want this to be "pile on Max" day, but this actually isn't true, either. Invoking new String() must result in the creation of a new, unique String object; I think JLS 15.9.3 is the authority for this, but there may be a stronger statement elsewhere.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Ernest Friedman-Hill:

I don't want this to be "pile on Max" day, but this actually isn't true, either. Invoking new String() must result in the creation of a new, unique String object; I think JLS 15.9.3 is the authority for this, but there may be a stronger statement elsewhere.

No, bring the pain. But I'm actually not aware of this in the JLS. I don't think that 15.9.3 is what you meant, though I suspect you're correct and I'm missing something.
M
<
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Your link is to the first edition; I was looking at the second edition. Even so, you're right, I didn't mean 15.9.3 -- I meant 15.9.4! See
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#41147
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hmm just thinking out loud:
"The whole point of the String pool would be to improve the performance of your code as less objects would be created. But now it is ofuscated the two String literals are not in the same memory location. Does this mean that it is creating new objects for each String literal. (No it can't be as that would really hit my memory usage). So what is happening?"
Any ideas?
Chris.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Originally posted by Ernest Friedman-Hill:
Your link is to the first edition; I was looking at the second edition. Even so, you're right, I didn't mean 15.9.3 -- I meant 15.9.4! See
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#41147

I see what you mean: There does, indeed, need to be a new instance per new invocation. This is interesting (and somewhat pointless in the case of Strings), but it's definitely clear that I was wrong.
Thanks
M
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
So what you are saying is that:

But when using klassmaster when they will all be false.
[ March 10, 2004: Message edited by: Chris Harris ]
Eddie Vanda
Ranch Hand

Joined: Mar 18, 2003
Posts: 281
I got true, false, false as you did using jdk1.5 beta


The nice thing about Standards is that there are so many to choose from!
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

perhaps there is a possibility to configure the obfuscator, not to obfuscate Strings?
String-literals.
[ March 13, 2004: Message edited by: Stefan Wagner ]

http://home.arcor.de/hirnstrom/bewerbung
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Strings on HP-UX