I respectfully disagree in part. A possible snag is if a proprietary (by one definition or another) codec is used on, say, a windows machine, but there is no version of that for Linux or Mac OS X (or the Wii or your wristwatch,etc)-although it seems like it would be a liberation to hand control to the OS regarding codecs as far as quanitity goes, the reliability between platforms would be at risk of getting shaky as now the codec developers have to do Sun's job, making a codec for every native platform. The issue would arise when some of these developers choose not to do that.

instead of current ISO-8859-1

but a few minor fixes would be nice like chdir or ability to see windows' special keys. And generic arrays. Give me operator overloading before closures.

but a few minor fixes would be nice like chdir or ability to see windows' special keys. And generic arrays. Give me operator overloading before closures.

I would like to see Isolates in Java7 so that multiple applications could share the JVM.

JOGL and JOAL are becoming more and more famous and more application appear to me oriented on these APIs... Why not embedded in JDK7?

VERY VERY MUCH !!!!!!! They are all so sweet !!!!!!!!!!

That way the marketing boys at Sun can no longer add "features" to the language for no other reason than that C# (or Ruby, or Python, or VB, or Delphi) has them and the language may finally settle down into a reasonably stable state where you know one day what the language you're working with will look like the next.

I would like to see strong effort in the Swing data binding and application framework that Hans introduced at last years Java One.

When Microsoft launched .Net I was working at a company that was working on the beta version. My feelings towards C# changed from "Another Java clone" to a language that has its place. At least on the Microsoft world. Now please, don't make Java an schizophrenic language by reimplementing all C# features, just with another syntax. We do have more things to worry about like improving the JVM, the multimedia support, bluetooth, USB and so on.

Pity that better multimedia support did not get more! I think that features that imply better user experience and/or features that make it easy to write better applications, that may compete with applications created with other technologies, are far more important than features that are more developer oriented. What is the point of having a wonderful language if no one uses it. If your application relies on heavy use of sound (like multi track audio editing) and/or video (like video editing), would you use Java?

Taking the broad view of Java, that is, including the JVM, by far the single biggest current deficiency in Java, IMHO is the lack of the ability to run multiple applications in the same JVM (robustly, efficiently, of course). In other words, implement JSR 121 and JSR 284, but with JSR 284 explicitly including memory as a managed resource in JSE. And include an option to start the JVM at boot time, and the ability to have multiple JVM's, each with multiple applications, for separation where needed. I really surprised nobody else has mentioned this. The inclusion of scripting languages in Java, that is, another category of small programs, makes this more pressing. Applets will always be perceived as slow until this is done, and, when it is done, the perception will be reversed: they will be perceived as very fast. Startup time (if the JVM is loaded at boot time) will be ZERO, and the memory footprint will go down, since there will be only one JVM, typically. The class data sharing work is great, but this is needed to go the rest of the way.

Taking the broad view of Java, that is, including the JVM, by far the single biggest current deficiency in Java, IMHO is the lack of the ability to run multiple applications in the same JVM (robustly, efficiently, of course). In other words, implement JSR 121 and JSR 284, but with JSR 284 explicitly including memory as a managed resource in JSE. And include an option to start the JVM at boot time, and the ability to have multiple JVM's, each with multiple applications, for separation where needed. I really surprised nobody else has mentioned this. The inclusion of scripting languages in Java, that is, another category of small programs, makes this more pressing. Applets will always be perceived as slow until this is done, and, when it is done, the perception will be reversed: they will be perceived as very fast. Startup time (if the JVM is loaded at boot time) will be ZERO, and the memory footprint will go down, since there will be only one JVM, typically. The class data sharing work is great, but this is needed to go the rest of the way.

I'd like to see better support for symmetric multiprocessing and for vector based operations. We're entering the multiprocessing era and our languages need to adapt. Maybe transactional memory support? None of these other things seem at all important to me.

I'll have to vote #1 as runtime generics support, but the new module system comes in at a close second.

My biggest wish for a future version of Java, not necessarily Java 7, is to have the other half of Java generics (runtime support for generic types) implemented, thus remove the need for erasure.

It would improve readability if the String “” could span multiple lines so that when embedding foreign language like SQL the developer would not have to break up the String with + operator. This would also make it easy to cut and past code back and forth between an SQL editor. Regular expression would be a lot easier to read to. The expression “\(\s+\)” would not need to look like this. “\\(\\s+\\)” C# does something like this with the @ symbol. Something like @” ”

The most popular choice is improved multimedia support. It's something that is very important to developers and mostly ignored by Sun. Yes yes, I know all about JMF. Java Media Framework just confirms my point. Nothing has been done with JMF in over two years. It's time to either support multimedia or not. Sitting on the fence isn't enough.

I voted improved multimedia support, but close seconds for me (from this list) are closures, resolution-independent Swing, and USB support. Personally, I like the not-null support thing and better properties, too. But I'd them after my above list. I'd also like to see HotSpot support immediate Integer objects (or more clever since the JVM is strongly typed) for higher-performance support of purely object-oriented languages. To give more detail, this is the trick where you know (for some CPUs) that all pointers are on 4-byte boundaries, so you cheat with the extra bits as flags to store immediate values and pretend they were pointers.

Beside XML support or properties I want them all :-). But I think most important is a kind of comprehensive versioning support that should build on the module system. It would have to be a smart system so that it becomes possible to bundle older versions of libraries and newer ones. Older programs automatically link to the older version, newer programs to the new version. Then it would be possible to refactor or improve the APIs. Imagine, Swing could use enums, support Closures, the Date class could be fixed and so on. If the whole thing is really smart this should also allow the language to be improved without complete backward compatibility of the source: One can specify the compiler the 'incarnation' of the language to be used and code converters in the IDE point to conflicting sites in the source that have to be modified to upgrade or downgrade 'incarnations'. A 'incarnation' is a range of versions that are source compatible. This would allow clean implementations of new features (e.g. new keywords) and the removal of old ones. (e.g. closures in, anonymous inner classes out) While you are at it, improve the class format to fix inner classes support and runtime representation of generics. Altogether this would be a strategy for Java to stay young, because old things can be left behind, but old programs still run and old libraries can still be used and old source still be compiled.

Something like C++ references, for example. I don't mind the particular approach, but I would love to see a solution. Why? Generics where said to solve ClassCastException. But ClassCastExceptions aren't a problem for me. NullPointerExceptions are a plague however: There's hardly a day without a NullPointerException in either foreign code or my own code. If some means to extinct this issue would exist, then probably 80% of my trouble would be gone. Regards, Christian

so you can tell what types of objects are supposed to go in them at runtime. As a tool builder, I find the fact that you can't do this makes simple problems a real pain in the ....