Re: 7.0 wishlist?

Mark Space wrote:
Harold Yarmouth wrote:
There's probably plenty of these floating around already, but here's

<http://tech.puredanger.com/2008/08/02/java7-prediction-update/>


* Sort-of structural typing. Any object can be used where an interface type is expected if it has the right set of method signatures, whether or not it "implements" the interface using that keyword. (It still must

Interesting but not my cuppa. Break down and just type "implements" on your class please.

The whole point is that sometimes you have a class that effectively does implement some interface, except for lacking the actual "implements" bit, and that you didn't write and don't get to edit. Generally you can subclass it and slap "implements" on the subclass, but instances might be getting created by code you don't get to edit that you'd like to treat as implementing the interface ...

* Allow extending final classes, subject to the constraint that new instance fields cannot be defined and none of the final class's methods

Feels yicky. Consider composition instead of inheritance.

Eh, the main use for this would be so you could tack on utility methods to existing types, if they seemed to belong there more naturally than somewhere else, and still use the resulting objects where the base type is expected. Basically an auto-wrapper.

* Add an unsigned byte type.

Probably too late for this, but sure it would have been handy.

Too late to change byte itself to unsigned, perhaps, but not to add an additional type.

* Add some way to specify that something should never be null. Perhaps a ! or a * before or after the variable name or type name.

Does this require a runtime check on each assignment? Could be a lot of overhead...

My thought was that the compiler would issue warnings if a might-be-null reference (not either marked never null or found to be non-null by static analysis, such as f in the else block of if (f == null) { this } else { that }) was assigned to one marked never null, or errors, with a cast needed to get rid of the warning or error that would produce NPE at run-time. No run-time checks added anywhere else.

There'd only be anything different if the left hand side of assignment (or a formal parameter being assigned) was of the "not supposed to be null" variety AND what was being assigned was not either "not supposed to be null" or demonstrably non-null by static analysis.

Error if demonstrably null instead.

If neither, one of three things might be done:
* Error, cast needed.
* Warning, cast can remove.
* Implicit cast.

Getting the NPE when the null first tries to get somewhere it doesn't belong is valuable, though. I don't know how many hours I've spent tracking how this null snuck into this ArrayList, that one into that variable, etc., not to mention how some instance variable or another managed to avoid being initialized.

* Allow omitting the names of unused parameters. Common cases would include:

I agree with Joshua, typo-city.

Eh?

* Constructor type inference. Also allow an alternate constructor

Generic methods can do this now.

Methods, but not constructors.

Rolling your own for your own classes isn't hard.

But we have to use other peoples' classes, including especially Sun's own, every day.

* Disallow public constructors on abstract classes. They are not
callable by any more code than a protected constructor anyway.

super();?

Called by a descendant, which can see protected constructors.

* When a type has a one-argument plus() method, + can be used when the
left hand operand is of that type and the right hand operand is of an

OK with me but apparently this ran into technical troubles.

How so?

* Clean up ImageIO and JAI. A lot of the code in these throws various
RuntimeExceptions in response to seeing something it doesn't like in

At least they shouldn't be throwing unsubclassed RuntimeException. Are they?

Yup -- com.sun.media.imageioimpl.plugins.pnm.PNMImageReader throws unsubclassed RuntimeException instead of IOException or whatever when the file format is unfamiliar.

java.lang.RuntimeException: What in the stream isn't a PNM image.
at com.sun.media.imageioimpl.plugins.pnm.PNMImageReader.readHeader(PNMImageReader.java:187)
at com.sun.media.imageioimpl.plugins.pnm.PNMImageReader.getWidth(PNMImageReader.java:153)

calling getWidth on a PNMImageReader invoked on a jpeg.

Really, though, unexpected/malformed/wrong/generally bogus input from a source external to the program should produce checked exceptions.

* Dead code in a method should be a warning, not an error.

Sure, makes debugging hard.

How? Warnings are just as visible as errors, whether using NB, Eclipse, or command-line javac. You know it's there when you see it.

* Hiding a local variable with a nested-scope local variable should be a
warning, not an error.

Dunno about this, just pick a different variable name.

Well, at least it should be consistent, so either that or hiding a field should be an error too, at least if the field isn't inherited.

* Provide a better way to deal with OutOfMemoryError or low memory in

Hmm, I haven't looked at any existing frameworks for using SoftReferences, but I'd head over to Apache.org and take a look.

I'm not presently in the market for a web server, but thanks anyway. :-)

Personally I think the garbage collector is probably about as complicated at Sun can handle at this time.

Who said anything about changing the GC? I was thinking more along the lines of the allocator, and having a listener API for memory-running-low.

the OS will give it. In this, it may maintain a "load factor" similar
to a HashMap for the entire heap, trying to keep it near 75% full, and

It's been discussed here, at least. I don't know how hard this would be, but I'm in favor of it, Sun willing. The incremental garbage collector gets pretty close to this, imo. It slowly prunes out un-used objects as the program runs, thereby keeping actual memory footprint to a minimum.

My observation is that a) -Xmx still exists and b) Java apps tend to bloat to a fixed and large fraction of their -Xmx regardless of the incremental garbage collector (now the default, isn't it?). My hope was for -Xmx to go away (or be able to be set infinite, and perhaps default that way) and the process size to tend to hang around a fixed multiple (say, 4/3) of the actual amount of memory taken up by live objects (since gc is more efficient if there's some slack space, similar to hashtables being more efficient with some slack space).

I think they already have as nice a method as they can. Use finalize() if you must. Personally I set all my windows to "DISPOSE_ON_CLOSE" so they just to it for me.

I/O is the area where this tends to get the messiest. There really should be a shortcut to the effect of

foo = whatever();
try {
do something
} finally {
foo.release();
}

Especially awkward is the situation where you want to actually return the open resource after doing something with it. If you just use try/finally your return will go through the finally and the stream will close or whatever that you intended to return open. So you need to set some boolean right before the successful-case return statement that the finally clause looks at ...

One thing that might help there would be a deferred return syntax:

return = expression;
....
return;

with the former performing an assignment to a special sort of local variable and the latter returning it. The idea being that if the return type was a Releasable, the method might implicitly release anything assigned to "return" but not actually returned, because of reassignment (say of null) or an exception throw. Reassignment would release the resource and an exception throw leaving the method would release the resource referenced by "return" that isn't actually going to get returned.

Plus, say, the using or with block:

with (InputStream in = new FileInputStream(file)) {
actions
}

is three lines of boilerplate shorter than the try/finally above.

Three lines of boilerplate that get written thousands of times over a Java programmer's career, mind. So it adds up.

* Allow array literals in expressions other than assignment RHS.

Java arrays need a type, I think, which isn't aways inferable from the context. Not sure how well this would work in practice.

Tightest bound on a common supertype of the arguments, obviously.

* Have array constructors added to the collection classes:
new HashMap({{"key1", "value1"}, {"key2", "value2"}});

This would be handy, but what type are those arrays?

* Add java.lang.Pair<K, V>. Make some existing classes Pair

This is so easy to roll your own, I'm sure that's why no one has done it for you.

Except that putting it in the base library code and giving the compiler special knowledge of it would allow for pair literals, which makes the arrays above able to work type-safely with the map's generic type parameters; and it could be employed elsewhere to clean up parts of the core API.

implementations, e.g. Dimension extends Pair<Integer, Integer>,

I think if Sun started messing with these, they'd go the other way. Dimension is slow. Use the individual X and Y methods instead.

Dimension is raw field access. With JIT it should be as fast as anything else.

* [int x]; defines a final box containing an int, an instance of a

SwingUtilities.invokeLater({foo:setVisible(true);});

Or you could substitute a "." for the ":" and save yourself a lot of useless code.

The point was to get it into the anonymous inner class in a mutable form, by shortcutting what you can already do, which is use a one-element array instead of a straight reference. (What was that old saw about adding one more layer of indirection?)

I'm with Joshua, the ternary operator is fine.

At least shorten it to allow x?foo:bar :P

No opinion. I've written your "yuck" code myself. It's really not that common though, usually just doing file IO, which can be encapsulated pretty well.

Begging your pardon, but that's like putting nuclear waste in lead-lined casks and burying them instead of avoiding producing the nuclear waste to begin with. :-)

JSR is done, I think. I'm not really fond of more anonymous classes though, I wish something more efficient could be used.

More efficient in what sense -- typing/source code bloat, not creating lots of extra little full-blown classes, run-time memory use, or run-time speed? Or some combination of these?

* Object.identityHashCode().

An un-overridable hashcode?

Yes, it should probably be final.

I guess, though I wonder if all platforms can always provide an
"identity" for each object.

It would just return Object.hashCode() -- that is, the return value hashCode() either does have or else would have if it weren't overridden anywhere in the ancestry.

What happens when an object gets shipped across a network several
times? Will it loose it's identity?

Object hashes are already not guaranteed to be the same in different sessions or on different JVMs, save for some whose formulas are specified somewhere (String's, perhaps).

* WeakValueHashMap, LinkedWeakHashMap, and LinkedWeakValueHashMap.
These would all be useful implementing caches where you want the

I think the Apache folks may have a framework or three. Didn't actually check though...

These deserve to be in java.util. Third-party stuff sees less use, since users don't a) discover they exist as easily, b) have as easy a time using them (they need to be found, then downloaded separately, and then their Javadocs don't integrate well with Sun's, either not doing so at all or going to Sun's website instead of your local copy and therefore not working if you're offline, also eventually not pointing to the current version anymore), or c) have as easy a time packaging up their app after using them (and then the jar equivalent of DLL Hell may be inflicted upon their users).

Plus, nobody goes looking for third party collection classes. They go looking for third-party math libraries, web app frameworks, other domain-specific libraries, and ImageIO plugins and the like.

* Allow subclassing an enum with the subclasses able to REMOVE (not

Probably going to break a lot of stuff and make enums a lot less efficient.

I specifically determined how to avoid doing so, which discussion you didn't bother to quote one word of. :P
.

Relevant Pages