Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #27850 > unrolled thread

how actually string store in java machine

Back to article view | Back to comp.lang.java.programmer

Contents

  how actually string store in java machine Rishipal Singh <95rishipal@gmail.com> - 2014-03-25 09:56 -0700
    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 10:32 -0700
    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 10:33 -0700
    Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 13:49 -0400
      Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-25 20:29 +0100
        Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-25 20:31 +0100
          Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-25 19:37 -0700
            Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-26 09:03 +0100
              Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-26 09:11 +0100
              Re: how actually string store in java machine Jan Burse <janburse@fastmail.fm> - 2014-03-27 10:27 +0100
            Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-26 08:32 -0700
              Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-26 13:54 -0400
                Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-26 12:57 -0700
                Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-26 16:37 -0700
                  Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-27 08:54 -0400
                    Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-27 08:23 -0700
                      Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-27 11:50 -0400
                        Re: how actually string store in java machine taqmcg@gmail.com - 2014-03-28 06:58 -0700
                          Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-28 11:02 -0400
                            Re: how actually string store in java machine taqmcg@gmail.com - 2014-04-02 05:47 -0700
                              Re: how actually string store in java machine Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-04-02 10:15 -0400
                                Re: how actually string store in java machine taqmcg@gmail.com - 2014-04-03 08:58 -0700
              Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-26 17:07 -0700
        Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:07 -0400
          Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:16 -0400
            Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 16:19 -0400
              Re: how actually string store in java machine markspace <markspace@nospam.nospam> - 2014-03-25 14:00 -0700
                Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-25 17:21 -0400
                  Re: how actually string store in java machine Jeff Higgins <jeff@invalid.invalid> - 2014-03-26 11:40 -0400
                    Re: how actually string store in java machine Roedy Green <see_website@mindprod.com.invalid> - 2014-03-26 17:46 -0700
    Re: how actually string store in java machine Lew <lewbloch@gmail.com> - 2014-03-25 15:07 -0700

Page 1 of 2  [1] 2  Next page →

#27850 — how actually string store in java machine

i have read so many articles about how string store in java .
but i have still problem 
most of the sites says that the string is stored in run time constant pool memory .
but how 
please help me  explain in detail ...

[toc] | [next] | [standalone]

#27855

On Tue, 25 Mar 2014 09:56:24 -0700 (PDT), Rishipal Singh
<95rishipal@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>i have read so many articles about how string store in java .
>but i have still problem 
>most of the sites says that the string is stored in run time constant pool memory .
>but how 
>please help me  explain in detail ...

In theory this is secret however, Internally a String is a char[]. The
reference is just a 4 byte (or 8 byte) pointer to the String object.
There are no methods to modify the contents of the string after
instantiation, or to modify the length.  The char[] is allocated like
an other char array, an a block of contiguous RAM somewhere in the
free space pool.

Actually, the pointer may be indirect to make it easier to move the
string around in RAM for garbage collection.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates

[toc] | [prev] | [next] | [standalone]

#27857

On Tue, 25 Mar 2014 09:56:24 -0700 (PDT), Rishipal Singh
<95rishipal@gmail.com> wrote, quoted or indirectly quoted someone who
said :

>i have read so many articles about how string store in java .
>but i have still problem 
>most of the sites says that the string is stored in run time constant pool memory .
>but how 
>please help me  explain in detail ...
 

have a look at the implementation of String in src.zip.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates

[toc] | [prev] | [next] | [standalone]

#27858

On 03/25/2014 12:56 PM, Rishipal Singh wrote:
> i have read so many articles about how string store in java .
> but i have still problem
> most of the sites says that the string is stored in run time constant pool memory .
> but how
> please help me  explain in detail ...
>
Please provide links to the article(s) that you are having trouble
understanding, along with pointers to the parts you do not understand.

[toc] | [prev] | [next] | [standalone]

#27859

Jeff Higgins schrieb:
> On 03/25/2014 12:56 PM, Rishipal Singh wrote:
>> i have read so many articles about how string store in java .
>> but i have still problem
>> most of the sites says that the string is stored in run time constant
>> pool memory .
>> but how
>> please help me  explain in detail ...
>>
> Please provide links to the article(s) that you are having trouble
> understanding, along with pointers to the parts you do not understand.
>


See also:
http://stackoverflow.com/questions/10209952/java-constant-pool

If I remember well some of the newer JVM have reorganized
their memory a little so as to avoid the limitations of
the permanent store.

http://openjdk.java.net/projects/jdk8/features#122

[toc] | [prev] | [next] | [standalone]

#27860

Jan Burse schrieb:
> See also:
> http://stackoverflow.com/questions/10209952/java-constant-pool

Android DEX further removes redudancies across classes,
and not only inside a single class.

http://stackoverflow.com/questions/16690815/shared-constant-pool

[toc] | [prev] | [next] | [standalone]

#27872

On Tue, 25 Mar 2014 20:31:50 +0100, Jan Burse <janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

>
>http://stackoverflow.com/questions/16690815/shared-constant-pool

I was under the impression all string constants lived in the same pool
along with the interned strings. That would imply a shared constant
pool since day 1.  Have I had this wrong since Java 1.0?
-- 
Roedy Green Canadian Mind Products http://mindprod.com
"A great lathe operator commands several times the wage of an average lathe
operator, but a great writer of software code is worth 10,000 times the
price of an average software writer."
~ Bill Gates

[toc] | [prev] | [next] | [standalone]

#27873

Roedy Green schrieb:
>> http://stackoverflow.com/questions/16690815/shared-constant-pool
> I was under the impression all string constants lived in the same pool
> along with the interned strings. That would imply a shared constant
> pool since day 1.  Have I had this wrong since Java 1.0?

Yeah, probably the answer is not a good one. Blurring
the compiletime format of byte code with the runtime
representation of a string.

But I guess there is a difference between Hotspot
and Dalvik in compiletime, the Hotspot Bytecode has
different pools per class, and the Dalvik has a single
pool.

What this implies for the runtime, I don't know. I
even don't know whether the constants from the pools
go into memory via intern(). The constant pool can
also have floats etc.. And there are complications
such as:

"Class data sharing (CDS) is a feature introduced in J2SE 5.0 that is 
intended to reduce the startup time for Java programming language 
applications, in particular smaller applications, as well as reduce 
footprint. When the JRE is installed on 32-bit platforms using the Sun 
provided installer, the installer loads a set of classes from the system 
jar file into a private internal representation, and dumps that 
representation to a file, called a “shared archive”. If the Sun JRE 
installer is not being used, this can be done manually, as explained 
below. During subsequent JVM invocations, the shared archive is 
memory-mapped in, saving the cost of loading those classes and allowing 
much of the JVM's metadata for these classes to be shared among multiple 
JVM processes. etc.."
http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#VM%20Class%20Loading|outline

Possibly the best idea is to say it is implementation
dependent what happens with the Strings in the constant
pool. You can try the following test code:

     class A {
         String t = "hello";
     }

     class B {
         String t = "hello";
     }

     if (A.t == B.t) {
        System.out.println("yes");
     } else {
        System.out.println("no");
     }

The bottom line could be, that we are not in position to
say what the above program does alone from the Java
Language Specification, since it is JVM implementation
dependent. But I might be wrong.

Bye

[toc] | [prev] | [next] | [standalone]

#27874

Jan Burse schrieb:
> http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#VM%20Class%20Loading|outline

 From the above description:
"The interpreter calls out to the VM runtime for complex operations 
(basically anything too complicated to do in assembly language) such as 
constant pool lookup."

Leaving me puzzled.

[toc] | [prev] | [next] | [standalone]

#27885

Jan Burse schrieb:
> The bottom line could be, that we are not in position to
> say what the above program does alone from the Java
> Language Specification, since it is JVM implementation
> dependent. But I might be wrong.

I am wrong, see also other poster who looked up JLS.

Test results so far, for a slightly modified code:

     public static void main(String[] args) {
         String t1 = A.getT();
         String t2 = B.getT();
         System.out.println(t1==t2);
     }

jdk1.5.0_22: true
jdk1.6.0_45: true
jdk1.7.0_51: true
jdk1.8.0: true

[toc] | [prev] | [next] | [standalone]

#27875

On 3/25/2014 7:37 PM, Roedy Green wrote:
> On Tue, 25 Mar 2014 20:31:50 +0100, Jan Burse <janburse@fastmail.fm>
> wrote, quoted or indirectly quoted someone who said :
>
>>
>> http://stackoverflow.com/questions/16690815/shared-constant-pool
>
> I was under the impression all string constants lived in the same pool
> along with the interned strings. That would imply a shared constant
> pool since day 1.  Have I had this wrong since Java 1.0?
>


Yes, I'm pretty sure you've been wrong if that's what you thought.  Each 
class has its own pool of strings.  If you have a class with a constant 
string:

   String a = "a";
   String b = "a";

The constant "a" is only stored once, and a==b will be true.  But that's 
only for a single class file.  Outside of the class file, each string is 
unique and a different object.  I don't think any implementations of the 
JVM called String.intern() for each constant string read in each class file.

And certainly if you read a string from a file or the network, the VM 
does not call String.intern() for you.  That would be silly.

[toc] | [prev] | [next] | [standalone]

#27877

On 3/26/2014 11:32 AM, markspace wrote:
> On 3/25/2014 7:37 PM, Roedy Green wrote:
>> On Tue, 25 Mar 2014 20:31:50 +0100, Jan Burse <janburse@fastmail.fm>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>>
>>> http://stackoverflow.com/questions/16690815/shared-constant-pool
>>
>> I was under the impression all string constants lived in the same pool
>> along with the interned strings. That would imply a shared constant
>> pool since day 1.  Have I had this wrong since Java 1.0?
>>
>
>
> Yes, I'm pretty sure you've been wrong if that's what you thought.  Each
> class has its own pool of strings.  If you have a class with a constant
> string:
>
>    String a = "a";
>    String b = "a";
>
> The constant "a" is only stored once, and a==b will be true.  But that's
> only for a single class file.  Outside of the class file, each string is
> unique and a different object.  I don't think any implementations of the
> JVM called String.intern() for each constant string read in each class
> file.

	// Foo.java:
	public class Foo {
	   public static String HELLO = "Hello";
	}

	// FooBar.java:
	public class FooBar {
	   public static void main(String[] unused) {
	      System.out.println("Foo.HELLO == \"Hello\": "
	         + (Foo.HELLO == "Hello"));
	   }
	}

... prints

	Foo.HELLO == "Hello": true

... on my Java 1.7.0_51 system.  You might also want to re-read
Section 3.10.5 of the Java Language Specification; for Java 7 and 8
it reads (in part)

	"Moreover, a string literal always refers to the /same/
	instance of class String. This is because string literals -
	or, more generally, strings that are the values of constant
	expressions (§15.28) - are "interned" so as to share unique
	instances, using the method String.intern."

Java 6 words it a bit differently:

	"String literals-or, more generally, strings that are the
	values of constant expressions (§15.28)-are "interned" so
	as to share unique instances, using the method String.intern."

... and goes on to give a multi-class, multi-package example.

> And certainly if you read a string from a file or the network, the VM
> does not call String.intern() for you.  That would be silly.

     That would be silly, yes.  But the handling of literals is
a different matter, and does not behave as you described.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27878

On Wednesday, March 26, 2014 1:54:28 PM UTC-4, Eric Sosman wrote:
> On 3/26/2014 11:32 AM, markspace wrote:
> 
> > On 3/25/2014 7:37 PM, Roedy Green wrote:
> >> On Tue, 25 Mar 2014 20:31:50 +0100, Jan Burse 
> >> wrote, quoted or indirectly quoted someone who said :
> >>
> >>>
> >>> http://stackoverflow.com/questions/16690815/shared-constant-pool
> >>
> >> I was under the impression all string constants lived in the same pool
> >> along with the interned strings. That would imply a shared constant
> >> pool since day 1.  Have I had this wrong since Java 1.0?
> 

If we extend Eric's comments with the relevant quote from the Java 1.0 spec (in 3.10.5):

Each string literal is a reference (§4.3) to an instance (§4.3.1, §12.5) of class String (§4.3.3, §20.12). String objects have a constant value. String literals-or, more generally, strings that are the values of constant expressions (§15.27)-are "interned" so as to share unique instances, using the method String.intern (§20.12.47).

So just as Roedy suggested this is the way it has been since day 1.

   Regards,
   Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#27880

On 3/26/2014 10:54 AM, Eric Sosman wrote:

> ... prints
>
>      Foo.HELLO == "Hello": true
>
> ... on my Java 1.7.0_51 system.  You might also want to re-read
> Section 3.10.5 of the Java Language Specification; for Java 7 and 8
> it reads (in part)


Well, that I did not expect.  No wonder it takes so long to load a class 
if each class has to be parsed for string literals and each one added to 
a hash map someplace.

Grrr, I'm actually mad about that.  String are *required* to be 
intern'd?!  That's really funky.

[toc] | [prev] | [next] | [standalone]

#27886

On 3/26/2014 7:37 PM, markspace wrote:
> On 3/26/2014 10:54 AM, Eric Sosman wrote:
>
>> ... prints
>>
>>      Foo.HELLO == "Hello": true
>>
>> ... on my Java 1.7.0_51 system.  You might also want to re-read
>> Section 3.10.5 of the Java Language Specification; for Java 7 and 8
>> it reads (in part)
>
>
> Well, that I did not expect.  No wonder it takes so long to load a class
> if each class has to be parsed for string literals and each one added to
> a hash map someplace.

     There's surely no parsing to speak of. The string literals'
data arrives in the class' constant pool, along with a lot of
other stuff, and is pretty easily located therein.  I suspect
that the time required to fish them out and intern() them is
peanuts compared to the time spent on the rest of class loading
and initialization (but I have absolutely no data to support my
suspicion).  And then there's the JIT ...

> Grrr, I'm actually mad about that.  String are *required* to be
> intern'd?!  That's really funky.

     I think so, too.  It feels like an implementation detail
that might better have been left unspecified.  Similarly, I
feel that the span of pooled Integer and suchlike objects ought
not to be part of the language definition, but should have been
left to the discretion of a JVM's implementors.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27887

On Thursday, March 27, 2014 8:54:36 AM UTC-4, Eric Sosman wrote:
> On 3/26/2014 7:37 PM, markspace wrote:
> 
> > On 3/26/2014 10:54 AM, Eric Sosman wrote:
> 
> >
...
>      I think so, too.  It feels like an implementation detail
> that might better have been left unspecified. 

But that would mean that the behavior of programs that compared constant strings was subject to subtle implementation dependencies, anathema to the spirit behind the development of Java.  I'd suggest the fact that the designers spelled this out is a testament the to the concern they had to making Java a really portable language and the thoroughness of their analysis.

   Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#27888

On 3/27/2014 11:23 AM, taqmcg@gmail.com wrote:
> On Thursday, March 27, 2014 8:54:36 AM UTC-4, Eric Sosman wrote:
>> On 3/26/2014 7:37 PM, markspace wrote:
>>
>>> On 3/26/2014 10:54 AM, Eric Sosman wrote:
>>
>>>
> ...
>>       I think so, too.  It feels like an implementation detail
>> that might better have been left unspecified.
>
> But that would mean that the behavior of programs that compared constant strings was subject to subtle implementation dependencies, anathema to the spirit behind the development of Java.  I'd suggest the fact that the designers spelled this out is a testament the to the concern they had to making Java a really portable language and the thoroughness of their analysis.

     Yes, it would change the behavior -- of programs that relied
on the dubious practice of comparing "value" objects with == rather
than with equals().  All I'm saying is that I think it would have
been better not to encourage the dubious practice.  Too late now,
of course.

     As for "subtle implementation dependencies" -- Well, Java is
certainly not free of them.  It has fewer such dependencies than
many other languages I've used, but still has enough to make life
interesting.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27895

On Thursday, March 27, 2014 11:50:22 AM UTC-4, Eric Sosman wrote:
> On 3/27/2014 11:23 AM, taqmcg@... wrote:
> 
> > On Thursday, March 27, 2014 8:54:36 AM UTC-4, Eric Sosman wrote:
> 
> >> On 3/26/2014 7:37 PM, markspace wrote:
> >>> On 3/26/2014 10:54 AM, Eric Sosman wrote:
> > ...
> >>       I think so, too.  It feels like an implementation detail
> >> that might better have been left unspecified.
> 
> > But that would mean that the behavior of programs that compared 
> > constant >strings was subject to subtle implementation dependencies,
> > anathema to the spirit behind the development of Java.  I'd suggest 
> > the fact that the designers spelled this out is a testament the to 
> > the concern they had to making Java a really portable language and 
> > the thoroughness of their analysis.
> 
>      Yes, it would change the behavior -- of programs that relied
> on the dubious practice of comparing "value" objects with == rather
> than with equals().  All I'm saying is that I think it would have
> been better not to encourage the dubious practice.  Too late now,
> of course.
> 
>      As for "subtle implementation dependencies" -- Well, Java is
> certainly not free of them.  It has fewer such dependencies than
> many other languages I've used, but still has enough to make life
> interesting.

Personally I've been very impressed with how carefully consistency of execution is addressed in the Java design.  The only places I've seen real implementation dependenciy is in the interaction with the world external to the Java environment (notably the file system) and multithreading.  Not sure that there's really anything one can do about the first.  I don't use multithreaded tasks much but I gather the technology was not sufficiently developed to fully specify this.  Regardless my sense is that most of the variability in multithreaded applications is not so much differences in implementation of threading but in the interactions between the threads and the scheduler which again might be thought of as something external. 

I'd be interested in understanding other areas where Java programs can legally give different answers absent some difference in external inputs.  The only one I'm aware of is the non-strict handling of floating point.  They tried to enforce consistency there originally -- strict was the original requirement, but the performance cost there was simply too great and the tiny degree of implementation dependency that's allowed there now affects a miniscule fraction of calculations.

My sense of the spec was not that they wanted to encourage users to use == to compare constant strings -- nor to discourage it -- but they recognized that it was a legal operation and so that it needed a defined result.  From that perspective they might have chosen that constants in different classes would use different instances.  I don't know that that would be a better or worse choice, but either would -- from the perspective of Write-once, run many times -- be better than leaving it unspecified.  I used the word anathema above, and I think that was appropriate for their (i.e., the designers of Java) view of leaving something undefined as a mechanism to discourage its use.


Regards,
Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#27896

On 3/28/2014 9:58 AM, taqmcg@gmail.com wrote:
> On Thursday, March 27, 2014 11:50:22 AM UTC-4, Eric Sosman wrote:
>> On 3/27/2014 11:23 AM, taqmcg@... wrote:
>>
>>> On Thursday, March 27, 2014 8:54:36 AM UTC-4, Eric Sosman wrote:
>>
>>>> On 3/26/2014 7:37 PM, markspace wrote:
>>>>> On 3/26/2014 10:54 AM, Eric Sosman wrote:
>>> ...
>>>>        I think so, too.  It feels like an implementation detail
>>>> that might better have been left unspecified.
>>
>>> But that would mean that the behavior of programs that compared
>>> constant >strings was subject to subtle implementation dependencies,
>>> anathema to the spirit behind the development of Java.  I'd suggest
>>> the fact that the designers spelled this out is a testament the to
>>> the concern they had to making Java a really portable language and
>>> the thoroughness of their analysis.
>>
>>       Yes, it would change the behavior -- of programs that relied
>> on the dubious practice of comparing "value" objects with == rather
>> than with equals().  All I'm saying is that I think it would have
>> been better not to encourage the dubious practice.  Too late now,
>> of course.
>>
>>       As for "subtle implementation dependencies" -- Well, Java is
>> certainly not free of them.  It has fewer such dependencies than
>> many other languages I've used, but still has enough to make life
>> interesting.
>
> Personally I've been very impressed with how carefully consistency of execution is addressed in the Java design.  The only places I've seen real implementation dependenciy is in the interaction with the world external to the Java environment (notably the file system) and multithreading.  Not sure that there's really anything one can do about the first.  I don't use multithreaded tasks much but I gather the technology was not sufficiently developed to fully specify this.  Regardless my sense is that most of the variability in multithreaded applications is not so much differences in implementation of threading but in the interactions between the threads and the scheduler which again might be thought of as something external.
>
> I'd be interested in understanding other areas where Java programs can legally give different answers absent some difference in external inputs.  The only one I'm aware of is the non-strict handling of floating point.  They tried to enforce consistency there originally -- strict was the original requirement, but the performance cost there was simply too great and the tiny degree of implementation dependency that's allowed there now affects a miniscule fraction of calculations.
>
> My sense of the spec was not that they wanted to encourage users to use == to compare constant strings -- nor to discourage it -- but they recognized that it was a legal operation and so that it needed a defined result.  From that perspective they might have chosen that constants in different classes would use different instances.  I don't know that that would be a better or worse choice, but either would -- from the perspective of Write-once, run many times -- be better than leaving it unspecified.  I used the word anathema above, and I think that was appropriate for their (i.e., the designers of Java) view of leaving something undefined as a mechanism to discourage its use.

     As I said, Java behaves more consistently across platforms than
other languages in my experience.  "Write Once, Run Anywhere" was a
goal of the language, but like "Don't Be Evil" it's not a goal that
was attained in perfection.  A few examples of variability:

     - Integer.valueOf(int): "This method will always cache values in
       the range -128 to 127, inclusive, and *may* [emphasis mine]
       cache other values outside of this range."  Hence, a test
       like `System.identityHashCode(Integer.valueOf(200)) ==
       System.identityHashCode(Integer.valueOf(200))' may yield
       either true or false, depending on the implementation.  Much
       the same holds for other primitive wrapper classes, too.

     - HashMap: "This class makes no guarantees as to the order of
       the map; in particular, it does not guarantee that the order
       will remain constant over time."  Also, "Note that the fail-fast
       behavior of an iterator cannot be guaranteed."

     - Map: "The behavior of a map is not specified if the value of
       an object is changed in a manner that affects equals comparisons
       while the object is a key in the map."  Also, "Implementations
       are free to implement optimizations whereby the equals invocation
       is avoided, for example, by first comparing the hash codes of the
       two keys," so you might *or might not* hit a breakpoint (etc.)
       in an equals() method when searching or inserting.

     - Class.getMethods(): "The elements in the array returned are
       not sorted and are not in any particular order."  You might
       get differently-ordered arrays for the same class from
       different JVM's, and the same goes for getConstructors()
       and so on, too.

     - Evaluate `Object.class.hashCode() > System.class.hashCode()'.
       Discuss.

     I'll grant that a "sane" program would not be affected by these
or similar implementation dependencies.  It seems to me, though,
that a "sane" program wouldn't compare String instances with `=='.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27934

On Friday, March 28, 2014 11:02:45 AM UTC-4, Eric Sosman wrote:
> On 3/28/2014 9:58 AM, taqmcg@...
> > On Thursday, March 27, 2014 11:50:22 AM UTC-4, Eric Sosman wrote:

>      As I said, Java behaves more consistently across platforms than 
> other languages in my experience.  "Write Once, Run Anywhere" was a
> goal of the language, but like "Don't Be Evil" it's not a goal that
> was attained in perfection.  A few examples of variability:
> 
... examples delete ...
Thanks Eric.  The first is pretty close to the situation with strings.  But it's interesting to note that these are all (I think) in the implementation of methods so that the documentation of these system dependencies is not in the language standard itself, but in the Javadocs for the standard library.  No methods are involved in the == comparison of strings, so if it were to be system dependent, then presumably that would have to be noted in the JLS itself.  Are there examples where the system dependencies are explicitly called out in the JLS, i.e., similar to allowing non-strict math results?  

Regards,
Tom McGlynn

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web