Size of primitive types?

[Ken]

Hi. Does the Java spec mandate set sizes for primitive types (e.g.,
int, float, char, etc.)? I know the ANSI C++ standard does not do
this, which makes these sizes compiler dependent. So I guess I'm
trying to figure out if in Java these sizes are compiler or JVM
dependent.

Thanks!

Ken

 

[P.Hill]

So I guess I'm
trying to figure out if in Java these sizes are compiler or JVM
dependent.

The language specifies their size and sign explicitly, see:
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9151
"4.2.1 Integral Types and Values"

HTH,
-Paul

 

[Ryan Stewart]

The language specifies their size and sign explicitly, see:
http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9151
"4.2.1 Integral Types and Values"

HTH,
-Paul

Actually, as I pointed out in comp.lang.java (please don't multipost, OP),
the spec doesn't mandate the size of primitive types. It only specifies the
range of values they may take on.

 

[Roedy Green]

Hi. Does the Java spec mandate set sizes for primitive types (e.g.,

yes. This is one of its most pleasant features, and is necessary for
platform independence. See http://mindprod.com/jgloss/primitive.html

 

[Roedy Green]

Actually, as I pointed out in comp.lang.java (please don't multipost, OP),
the spec doesn't mandate the size of primitive types.

It specifies the size to the extent there is no way you can tell if
the actual size inside is larger. I/O sizes and endianness are fixed.

Arithmetic cannot give extra precision.

Unlike C, the JVM is completely free to add padding and alignment
bytes wherever it chooses, and you would never know.

 

[Ryan Stewart]

It specifies the size to the extent there is no way you can tell if
the actual size inside is larger. I/O sizes and endianness are fixed.

Arithmetic cannot give extra precision.

Unlike C, the JVM is completely free to add padding and alignment
bytes wherever it chooses, and you would never know.

I took the OP's question to mean actual size on the hardware since he's
comparing it to C++. To my understanding, there is no standard for that in
Java.

 

[Mark Thornton]

Actually, as I pointed out in comp.lang.java (please don't multipost, OP),

I don't think comp.lang.java is an authorised newsgroup (has not been
officially created).

Mark Thornton

 

[Ryan Stewart]

OP),

I don't think comp.lang.java is an authorised newsgroup (has not been
officially created).

I thought it was created but then "uncreated". That doesn't keep people from
posting there. Unfortunately I saw his post there first.

 

[P.Hill]

I thought it was created but then "uncreated". That doesn't keep people from
posting there. Unfortunately I saw his post there first.

You read an group you know to be old and out of date? That's odd.
Try to encourage it's death by leaving it alone and using
comp.lang.java.programmer or .help

-Paul

 

[Andrew Thompson]

I thought it was created but then "uncreated". That doesn't keep people from
posting there. Unfortunately I saw his post there first.

What about setting the follow-ups*
to a valid group?

* A trivial matter when using 40tude Dialog..

It also warns of cross-posting, and
posting to groups not listed on the
local server (my local server does not
support c.l.j and 40tude warns me when
I am about to reply to a thread cross-posted
to it ..or 'comp.lang.java.javascript').

It also warns you when F'ups are set to
the poster themselves, which is a very
irritating practice.

 

[Roedy Green]

I took the OP's question to mean actual size on the hardware since he's
comparing it to C++. To my understanding, there is no standard for that in
Java.

Java standards don't say HOW something has to be implemented, just the
net effect on the programmer. So even though the logical sizes of
primitives to the programmer are rigidly specified, exactly how that
is pulled off with the hardware is none of our business.

In a similar way Java is says nothing about how many bits a reference
is, or whether it must be a pointer a handle (indirect pointer), and
what additional information it carries besides address.

It does not even insist that 0 be used to represent null.

Java does not specify byte sex internally, just that when you do i/o
it looks as though the machine were 2's complement big endian. This
way a little-endian machine is not in the least slowed down, except
when it comes time to do binary i/o.

 

[Roedy Green]

What about setting the follow-ups*
to a valid group?

You have to put some answer back in the bad group to tell the OP who
where the rest of us are hanging out.

 

[Andrew Thompson]

You have to put some answer back in the bad group to tell the OP who
where the rest of us are hanging out.

The *answer* *does* go back to the original group..
It is only *responses* to that post that
go to the 'follow-up' address..

 

[Ryan Stewart]

You read an group you know to be old and out of date? That's odd.
Try to encourage it's death by leaving it alone and using
comp.lang.java.programmer or .help

I do encourage its death. I do so by encouraging people who post there to
instead use one of the aforementioned groups. I think I failed to include
that in my reply this time though...

 

[Roedy Green]

The *answer* *does* go back to the original group..
It is only *responses* to that post that
go to the 'follow-up' address..

Unless you mention that you have done that, people won't notice the
follow-up to and their responses just disappear as far as they are
concerned. In the political groups, it is a standard dirty trick to
flame then set the follow-up to some irrelevant bitbucket group like
alt.test so the replies will be thrown away.

 

[Andrew Thompson]

Unless you mention that you have done that, ..

<snip Roedy going off on a tangent>

I make a point of mentioning it.

 

[Michael Borgwardt]

It specifies the size to the extent there is no way you can tell if
the actual size inside is larger. I/O sizes and endianness are fixed.

Arithmetic cannot give extra precision.

Actually, it *can*, disproving your claim above. That's why there is an
extra feature, the "strictfp" keyword that allows you to *avoid* having
extra precision...

 

[Mark Thornton]

Actually, it *can*, disproving your claim above. That's why there is an
extra feature, the "strictfp" keyword that allows you to *avoid* having
extra precision...

Sorry, it can provide an extended exponent range but not extra
precision. Using strictfp ensures that the exponent range is that of
standard double (float), it makes no difference to the precision (number
of mantissa bits) which is always fixed at 53 for double expressions and
I think 24 for float expressions (after allowing for the implied leading
1 bit in each case).
Non conforming VMs may behave differently (e.g. Microsoft's VM).

Mark Thornton

 

[Mark Thornton]

Wait. I thought the idea was to allow the extra guard bits to be used
which happens naturally when you use the Pentium FP registers.

No, the main idea was to allow x86 to execute with little loss of speed.
The strict mode requires that the range of the exponent be respected
and this requires the load/save technique to ensure an outsize exponent
is not carried through intermediate results. The x86 processors have a
mode to specify the precision to use (float, double or extended) so it
isn't necessary to allow extended precision in order to use these
processors at maximum speed.

Yes, some people did want a way to allow extended precision as well, but
this was not approved. Also worth noting is that the fastest way of
performing many floating point operations now is via the SSE and SSE2
instructions, which provide float and double precision respectively.

Mark Thornton

 

[Mark Thornton]

No, after googling around a bit I found that I had been wrong and Mark is
right. Leaving out strictfp only allows the JVM to use the extra bits
for the exponent, not the mantissa, in intermediate results (apparently
the FPU allows you to choose how to distribute them). This makes FP
arithmetic faster and succeed in some instances where strictfp arithmetic
has to produce an overflow, but it does not make it more precise.

Yes, it appears idiotic to me, too. The only people who would object to
some results being more precise (and thus different) on some platforms
will be using strictfp anyway, won't they?

Actually no, this is a very complicated business. Algorithms to provide
quad precision (based on doubles) require the precision to be exactly as
expected, but also want as much speed as possible.

Mark Thornton