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

Groups > comp.lang.java.programmer > #27945

Re: how actually string store in java machine

Show all headers | View raw

On Wednesday, April 2, 2014 10:15:22 AM UTC-4, Eric Sosman wrote:
> On 4/2/2014 8:47 AM, taqmcg@... wrote:
> 
>>itself.  Are there examples where the system dependencies are explicitly >>called out in the JLS, i.e., similar to allowing non-strict math results?
> 
> 
> 
>      I dunno.  In Original Java the == operator behaved the same way for 
> all reference types (it asked "Do these two references denote the same
> instance?"), so the results of using == on two Integer references, for
> example, could differ depending on how many values the particular JVM
> chose to cache.  But then they changed the meaning of == for the
> primitive wrappers, so that difference went away (and that's why I
> mentioned using System.identityHashCode() in the comparison).
> 
> 
>      It strikes me, though, that you seem to argue Java's platform
> independence by progressively whittling away the dependencies that
> arise. You began with "We'll just ignore strictfp" and "Oh, let's not
> worry about anything involving the host environment," and now it seems
> "Methods don't count, either."  With an approach like this, I might
> well argue that all birds are crows: We'll just agree not to consider
> peacocks, and emus don't fly so they scarcely count, and finches aren't
> big enough to worry with, and ... eventually I'll have proved universal
> crowhood!  ;-)
> 

Maybe!  I'm not trying to weasel out of this. I think it's useful to understand the limits of the WORM mantra.

Non-strict math is certainly an example where one is allowed to have system dependent results based solely upon the language of the current JLS.  But in terms of the design process for the language, that wasn't because they didn't want to eliminate that dependency.  Indeed the original spec precluded non-strict math.  It was only when they faced the issue that the spec was not feasibly implemented (in the sense that this requirement drastically affected floating point performance on most existing systems) that they changed the spec.  And even then they did not generally allow extended precision calculations, which would have potentially affected large numbers of results, but only calculations that used extended ranges in the exponents.

So I think a reasonable question that's not a "who is a real Scotsman?" is "Are there areas where the JLS itself allows a system dependency that was overlooked in the design of the language?"  Non-strict math wasn't overlooked.  It was explicitly added for feasibility.  A second question would be "What system dependencies are explicitly permitted by the JLS?" That would include non-strict math, at least for versions > 1.0.

With autoboxing one now has the same issue with constant Integers fields that we had with String (without involving any methods):

    class A
    public Integer xxx = 1111;
    end

    class B
    public Integer yyy = 1111;
    end

I hadn't checked but would have presumed we had a defined results for

    A.xxx == B.yyy

regardless of its magnitude.  

But that's not the case:  The actual language in the JLS that I see is (5.1.7):

>>>Start quote
If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.
<<<End quote

So somewhat to my surprise, the result is not well defined, but it's pretty clear that this is not an unconsidered system dependency, but a second case that the designers were fully cognizant of and explicitly decided to permit for expediency but were not especially happy about.

I'd be interested in understanding other areas in the JLS where either the language is unintentionally underspecified, or where there is an explicit deferral to the system.

     Regards,
     Tom McGlynn

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web