Skip to main content

What one feature would you most like to see in JDK 7?

Closures
15% (260 votes)
New properties syntax
6% (102 votes)
Language-level XML support
6% (97 votes)
Module system (JSR-277)
11% (179 votes)
Modularized JRE
9% (153 votes)
Removal of deprecated API's
9% (161 votes)
Improved multimedia libraries
18% (310 votes)
Resolution-indpendent Swing
7% (112 votes)
USB support (JSR-80)
16% (266 votes)
Something else
3% (59 votes)
Total votes: 1699

Comments

Operator overloading

for me java is the best object oriented language ever invented. i think java will be better language with operators overloading. for example i tested the java virtual machine and the C# virtual machine, and the java virtual machine is more than 3 times faster. but i think the operator overloading in C# and have string as primitive data type is a competitive advantage to C#, although i think java is well better than C#. i think good thin gs can even go better.

I hope Sun is paying attention

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.

wish the default encoding of .properties file set to UTF-8

instead of current ISO-8859-1

None of the above ...

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.

None of the above ...

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.

Isolates in Java7

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

Multimedia Support

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

I want ALL features

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

I want ALL features

I agree All features are cool and much anticipated. :)) Java rules

handing control to ISO

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.

handing control to ISO

Hmm. C# is an ISO standard.

handing control to ISO

(Note that I'm not saying Java should have every C# feature. There are several things in C# that I think are redundant, unneeded, not-Java-like, or just plain wrong. But that doesn't mean I think it's all bad. It also doesn't mean that it's not an ISO spec.)

handing control to ISO

Nor am I saying everything in C# is bad (in fact I like the language). But Java is being swamped with "features" that are added for no reason other than that some other language has them. There is no longer a process to determine if there's any real use or value for something it seems, if C# (or Ruby, or C++, or whatever) has it, then so should Java.

In contrast C++ (for example) is developed as a language with far more thought, at a deliberately slow pace in order to assure that only things that are of actual value make it into the language.

I've no problem with things making it into the language, but they should have real added value above (or maybe instead of) making for nice marketing slogans. "Now new and improved, with embedded XML support!!!", "now with embedded database, get it while it's hot!!!!!", "no more need for expensive application servers, full SOAP stack built into the core installation. Save NOW!!!!!".

Swing Databinding and application framework

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

Swing Databinding and application framework

I've been waiting to see what the databinding group has come up with for a long time now. My company donated a chunk of code to them from our own framework but I don't know if Sun's lawyers ever let them look at it.

Please don't clone C#!

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.

Developers vs Users

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?

Developers vs Users

I voted for multimedia improvements as well. I work on a Java UI for a high-end video encoding application. I would also like to see better support for image capture devices like scanners and cameras. Support for Faxing directly from Java. And, of course, JMF done right and completed.

JMF had so much promise when I first spotted it, but it never matured. If you've ever used Microsoft's DirectShow you know how poorly it can be done. JMF could have been a great thing.

Developers vs Users

If I wanted it to be cross-platform I certainly would.

multiple applications in the same jvm

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.

multiple applications in the same jvm

I second that. Also this could lead to Java being useful as system programming tool. You could do that little tools in Java that take way too long to start up in Java now and need C or Perl or scripting.

multiple applications in the same jvm

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.

multiple applications in the same jvm

What if two applications run in the same JVM and one has native code and this native code crashes ? Do you remember Win95 or MacOS9 ? How to prevent that a crashing application brings down the whole JVM with all applications?

multiple applications in the same jvm

If I'm not wrong, the single-JVM approach is effective in Mac OS X for years now and it's stable - a crash in a single application doesn't affect others for what I can see.

multiple applications in the same jvm

The mac starts every JVM as a new instance. Jars used by several programs are loaded only once in the memory, just as shared libs in the native world. So e.g. the Swing classes are loaded only once in the memory which reduces the memory footprint, but this is not a single JVM running multiple programs! If I remember correctly, this is already implemented in JRE 5 by Sun too. The advantage of the Mac is that it has a single JVM installed (OK, to be correct, two versions). And during updates this JVM gets updated. This is much better than the Sun appoach with dozens of old JVMs on a typical computer. During an update you just add another one to the chaos. But all your Java apps remain linked to the old JVMs, so the update dosen't buy you anything. Yes, please Sun, improve this situation with Java 7.

parallel processing

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.

Runtime generics support

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

Erase Erasure

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.

Erase Erasure

Absolutely!!! This is at the top of my wish list!

Verbatim Strings

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 @” ”

Verbatim Strings

One thought I've had for syntax in Java is to prefix the string with \. Seems related, doesn't overload the meaning of @ (which has a different meaning in C#), and it shouldn't conflict with separate oddness like Unicode character literals because of following characters. So for example:

\"\(\s+\)"

I hope Sun is paying attention

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.

Why just one favorite?

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.

Why just one favorite?

Oh, and I also want instant start-up time, so we can finally start writing shell-level scripts in Java and JVM-based languages. (It does seem to have improved in Java 6 some, already?)

Most important: A versioning strategy

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.

Protection agains NullPointerException

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

Introspection for lists

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 ....