Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Strings on HP-UX

 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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 ]
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, what you're all saying is, I was right the first time
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, almost all of us are saying that, yes.
 
Chris Harris
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aha! Good to know. Thanks for the followup.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 283
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I got true, false, false as you did using jdk1.5 beta
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
perhaps there is a possibility to configure the obfuscator, not to obfuscate Strings?
String-literals.
[ March 13, 2004: Message edited by: Stefan Wagner ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic