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

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

Re: Java vs C++

Show all headers | View raw

On Sun, 06 Feb 2011 10:55:15 -0800, Patricia Shanahan wrote:

> Arne Vajhøj wrote:
>> On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
>>> In message<iijrj2$i0g$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> Also take into consideration the fact that the C++ standard does not
>>>> try to pin stuff down into unambiguous interoperable statements,
>>>> e.g., a precise size definition for size_t.
>>>
>>> It seems to me that’s another drawback of Java, that it explicitly
>>> defines
>>> the sizes of things from the viewpoint of 32-bit architectures like
>>> those current in the 1990s. Some of those decisions look less
>>> wonderful on current
>>> 64-bit architectures.
>> 
>> There are nothing in defining the size of the simple data types that
>> are tied to 32 bit architecture.
> 
> I am aware of one issue in the simple data types that reflects 32 bit
> architecture, JLS section 17.7, "Non-atomic Treatment of double and
> long".
> 
> The big way in which Java is tied to 32 bit architectures is not in the
> simple data types. It is the maximum size of an array, String, Set, List
> etc.

It was unfortunate that they didn't define the get, size, etc. methods 
for the java.util collections as taking/returning longs. If they had, 
they could have just quietly dropped the 2^32 size limit on them at some 
point without any existing code breaking. They'd have to add a new array 
supertype for long-indexed arrays, which means new bytecode and a syntax 
for declaring such arrays, but the collections could then have had their 
innards quietly changed.

As it stands, they'll have to introduce a parallel hierarchy of long-
indexed array types and a syntax for declaring these, and then make more 
complicated changes to java.util. Making existing collections support 
bigger sizes is difficult, because a lot of code likely depends on the 
size method returning an accurate count. Having size clamp at 
Integer.MAX_VALUE while the real size gets larger would therefore break 
things. Redefining size to return a long will also break things, whether 
or not they also dropped the error on implicit narrowing assignments from 
long to int. (They'd have to at least keep it a warning, for obvious 
reasons; I'd vote for leaving it an error.) Redefining List.get() to take 
a long maintains source compatibility (the implicit conversions here will 
be widening) but not binary. Overloading List.get() to accept int or long 
inputs maintains both, but with the size problem it's academic anyway.

They'll have to add BigCollection, BigList, BigMap ... or else create 
java.util.big or java.util2 with parallel versions of everything.

What a pain.

The funny thing is they could have anticipated this and had longs in all 
these places from the outset, with a soft limit based on when OOME got 
thrown or even an exception throw at runtime for exceeding 
Integer.MAX_VALUE and a compile-time error for too-big literal array 
indices and sizes that could later be removed, if they didn't actually 
implement giant arrays yet at that point. The language could have been 
designed to allow for them later. But it wasn't.

Heck, they had BigInteger from the outset and could have gone so far as 
to include a true numeric tower, implicit conversions all the way up to 
BigInteger and not just long, Integer an abstract class with 
ShortInteger, SmallInteger, LongInteger, and BigInteger as subclasses, 
and Integer the return types of size methods, allowing for potentially 
unlimited growth. (BigInteger uses an array under the hood and so 
presumably has a limit of 2^31-1 words of size, but in this world it 
would of course be capable of being bigger because arrays would be. Of 
course, the bigger everything got the slower it would get ...)

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

Thread

Re: Java vs C++ Ken Wesson <kwesson@gmail.com> - 2011-02-07 04:38 +0100
  Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-08 09:47 +1300

csiph-web