Re: Virtual files
Kenneth P. Turvey wrote:
On Sat, 17 May 2008 13:33:45 -0500, Logan Shaw wrote:
I was going to suggest that, but it appears that all the offsets are
ints, so the same 2^32 limitation (actually, 2^31 limitation, I guess)
would apply.
This kind of thing is coming up more an more often. The API is going to
require some major rewriting in the not too distant future. Sun is going
to emphasize backward compatibility and what we are going to end up with
is a rather broken and fragmented language. I don't know any good way to
handle this, maybe a new set of packages for parts of the API based on
longs instead?
That's good point. It's too bad that ints and longs and other basic
data types aren't treated as more like objects and able to be handled
polymorphically.
I wonder how bad it would be just to take the existing API, say to heck
with the spec, and replace all ints with longs, in place, without
changing any method names or class names?
You'd get a lot of "need to cast from long to int here" but the you
could suppress that and it would still run, right? And then you could
upgrade your code at some leisure. I'm not sure of the best way for Sun
to do this. Maybe some future version (Java 8?) and give the current
version an extra long life so everyone has time to react.
The worst part would be in the transition, narrowing casts do not throw
overflow errors, so you could have a big issue and not know it.
(*coughfixthisSuncough*) I'd like to see this changed at the same time,
just so such errors are caught a runtime.
I know some here are against that, because of how "important" and
"convenient" bit slicing integers is, but that's a load of b.s. The
obvious solution is that the idiom of catching and ignoring a cast
related overflow error could be optimized to the older, faster operators
that simulate bit slicing.
int i;
long val = 0;
try {
i = (int)val;
} catch( CastOverflowException x )
{}
means "just bit slice it." For convenience, Sun could add an annotation
that does the same thing:
@SupressCastOverflow
public int longToInt( int i ) {
return val;
}
will also use the "faster bit slice operator." (Sun could also make it a
warning rather than an error to narrow primitives without an explicit
cast, and use SuppressWarnings.) Yes, you'll have to touch your code.
Sorry.