Java 1.6 Wish List

Sun is the final stages of collecting requirements for the releases that will follow Tiger, which means the next 3 years. So here's your chance to tell Sun what you would like to see in J2SE versions 6 and 7. Once we gather all of the ideas, we can try to see if we can prioritize the list.

Please use general@jakarta.apache.org (so that we have one open list) to discuss your ideas.

PLEASE NOTE: In order for this information to have the most impact, Sun needs it by end of this week (October 29th). [The short time is not Sun's fault. They had asked earlier in the summer, but the ball got dropped. I just ran into the J2SE lead, who raised the issue again].

Prioritized List

Stefano Mazzocchi's Wishes

There are three thing that I would like to see:

  1. continuation support: the ability to freeze the state of a thread and resume it. Just implementing Thread.stop() that returns a Continuation object would be good enough. I don't care about making these continuations transportable across machines and I don't care if they don't work if JNI is in the mix.
  2. pluggable lifecycle handlers: java has a few underlying mechanisms that you can extend and modify (URL factories, classloading) but there is no way to implement a different way to handle object lifecycle in a more aspect-oriented way. It would make POJO-oriented COP a lot easier.
  3. allowing cascading URLHandlerFactories: you can have one and only one URLHandlerFactory in a given JVM, this is very bad, especially in a server-side environment. Just like classloaders, URLHandlerFactories should be allowed to be cascaded.


Philip Jacob's Wishes

Support for closures would be mighty useful.


Matthew Hawthorne's Wishes

1. Literals for creating Collections, Maps, and maybe even Beans (with keyword arguments). It's a bit scripty, but these types of things take way too many lines of code.

Collection c = {"c", "d", "e"};

Map m = {"key1"=1, "key2"=2};

Person p = new Person(name="Joe", id=345)

Henri Yandell's Wishes

  1. Multiple-object returns. Basically the ability to do: int a, b = foo(); with foo defined as public int,int foo() {... This has use both for returning error/notification codes, and also for algorithms which create more than one type of return value.
  2. Complex number support, both a java.math.Complex class, literal support and operator overloading.
  3. Where possible, new features should be released as jar upgrades to previous JDKs. The java.util.logging library should be available as a java-logging.jar that works in 1.2+ and regexps could have also been available (ignoring the String enhancements). Would make life nicer for OS-X and other non Sun supported JVM users too.
  4. Class modification. Seems tricky, especially for encapsulation, but adding methods to classes/objects would be very nice. For the java-regexp.jar mentioned in the previous wish, why couldn't the String-regexp methods be added in that jar, even when String is defined elsewhere.
  5. More pluggability of standards in the Sun JVM. While a JDK vendor can create a new JVM and put their own regexp implementation in, why can't a regexp-vendor (Jakarta ORO) plug their own regexp implementation into the Sun JVM. Same for Logging, same for Collections, same for URLs etc. Given that JDBC does this, and has been a roaring success, and J2EE tries to do the same thing, why not apply the idea at the lower level too?
  6. Add Map support to the Bean spec.
  7. Matthew's literal-wish should in fact just be a Bean-creation wish; with arrays, collections, maps being supported as a part of a bean. Possibly use the => or -> style of syntax if a simple = is tricky.

  8. String.capitalise method. Or toCapitalise or toTitleCase or whatever name you want.
  9. Multiple Exceptions in a catch block. ie) try { ... } catch(IOException, SQLException, RemoteException e) { .. }

Rich Feit's Wishes

  1. Inheritance for annotations (e.g., public @interface foo extends bar). Not having this really hurts when you want to specialize an annotation, which happens all the time.

  2. The ability to mark as const:

    • methods (can't change member data)
    • method arguments (on which you can't call non-const methods)

Stephen Colebourne's Wishes

JDK language enhancements should be added if the problem it solves is common, and there is no easy way to work around the issue (either by a basic or OSS solution). Thus aspects seems to be doing fine as OSS projects and don't need JDK support.

1. Continuations. From the descriptions I have read, these are a really valuable addition to the language, and are very difficult to simulate in other ways.

2. String implements Iterable. JDK1.5 added the new for constructs which handle List and Array equally. However, they do not handle Strings, which are essentially just Lists of chars. This request is not just for String to implement Iterable, but for the JDK to access the internal char array within the String during iteration. This would enable fast looping around each char of a String. for (char c : str)

3. Language level support for resizable arrays. I originally would have gone against this concept, but it actually has real merit in improving performance of libraries like Commons Collections if it maps down to native routines in modern machines.

4. const. Its really difficult to work around, we use a naming convention at my company and thats a poor substitute. I want to declare a variable as const and then not be able to alter any field within that object or other object in that object graph.

Library changes should focus on improving what already exists. Adding whole reams of new libraries is A Bad Idea - OSS does it better.

1. Add array constructors to maps and collections.

2. Review Commons IO, Commons Lang, Commons Collections, Commons Codec, etc for methods that should be in the JDK. For example, IOUtils.closeQuietly(InputStream), a very useful method in finally clauses (in fact all the IOUtils and FileUtils methods to read and write a file/stream in one go).

3. Write the JavaBean specification version 2. JavaBeans are now ubiquitous, but the base specification has never been updated and says nothing about Collections or Maps, key elements of all modern systems. The specification desparately needs updating.

4. Generally unifying the access to various APIs to use the collections API, providing access via iterator, not enumeration, List not Vector.

Stephen Colebourne comments & votes

Alex Karasulu's Wishes

  1. Continuations support
  2. NIO and SSL working nicely together
  3. A selectable FileChannel where you can register for changes to files 3a. Better File support in general

  4. 1:1 mapping of LDAP constants to JNDI exceptions in SUN LDAP JNDI Provider
  5. Asynchronous IO
  6. Revamped security model in J2SE that unifies across J2EE security as well
  7. +1 to the jar in jar
  8. +1 to auditing only security setting
  9. +1 to comma-delimited list of Throwables in catch blocks
  10. +1 java compilation API: being able to compile without going throuh the commandline or some undocumented API like janino http://www.janino.net/changelog.html

Paco Nathan's Wishes

1. Expect-like features on control structures for handling streams, e.g., timeout, regex, in addition to testing eof. Each of these can be performed, but the coordination is clumsy.

2. XQuery support added to the javax.xml package. Given the XSL support already, this should not be too far off.

3. RSS parsing/aggregating/generating in I/O streams.

Tim Vernum's Wishes

1. Ability to determine the current class in a static context. Mostly useful with logging frameworks where instead of doing

you can do

This would basically be a compiler change to have this.class resolve to the currently class currently being compiled.

2. Something approximating closures. Anonymous inner classes (in their current syntax) just don't cut it.

Danny Angus' Wishes

1/ Ok don't flame me... "Method pointers"

I *know* it is possible to accomplish all the delegation one might want by using polymorphism, but this often leads to unncessary screeds of boiler-plate, so I still I believe there is a case for some kind of streamlining of delegation by allowing it to be achieved on a method level rather than at a class level.

For instance it might make sense for a Class to provide several sort methods, polymorphism would require this class to implement a different interface for each one, function pointers could be used instead to have a method take a parameter and return a refrence to the appropriate method thereby correctly (IMHO) encapsulating the decision/conditions within the class and not exposing it externally.

2/ Jar versioning

Lets see a JVM which has the capability to accept simultaneous registration of multiple versions of a package and resolve them to satisfy dependence with an appropriate version, and without breaking the classloader model we've grown to love (or perhaps merely accept!). The version resolution could be, by default the most recent, where specified to the classloader by "specification version" the most recent implementation of the spec by "implementation version" a specific version.

Manifests could specify inter-package dependance declaratively.

This would surely be a huge boon to integration.

(Oh and a big +1 to Henning's "jar-in-jar" below.)

Henning Schmiedehausen's Wishes

1/ Pretty simple thing: Allow the Class loader to load jars from jars. Currently, when repacking applications, people unpack a jar, then repack all the classes into a single, huge jar. Allow application to put an existing jar into a jar to get the java -jar <jar name>.jar run feature without having to repack all the classes.

2/ How about simpler getter/setter syntax a la C#? Like

private property String foo = null;

automatically creates

public void setFoo(String foo) { this.foo = foo }; public String getFoo() { return this.foo; };

would reduce lots of clutter.

Henri Yandell comment

+1 to the jar in jar. The property syntax would also need things like:

The private is unnecessary I think. It would always be a private member and public methods. The above would need to work with the proposed literals, and the (String,Object) is another use of my suggested multiple-typed returns. Basically a tuple way to specify types.

James Strachan's Wishes

In order of priority, most important first

Torsten Curdt's Wishes

Noel J. Bergman's Wishes

Gary D. Gregory's Wishes

Tim O'Brien's Wishes

TitleIndex

JavaFutures (last edited 2009-09-20 23:36:21 by localhost)