Skip to main content

Planned New Features and Enhancements for Java/JDK 7.0 (What should be new)

15 replies [Last post]
kari_cz
Offline
Joined: 2007-01-31
Points: 0

Could you, please, add a short structured article with
Planned New Features and Enhancements for Java/JDK 7.0
easily reachable from http://jdk7.dev.java.net.

Something, where it will be mentioned, what is expected to be pretty new in this release from a high level point of view (with some descriptions).

i.e. for version java 6.0:
annotation, generics, ...

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mthornton
Offline
Joined: 2003-06-10
Points: 0

try X[][].class

it even works where X is int as shown here

public class TestClassLiteral
{
public static void main(String[] args)
{
System.out.println(int[][].class);
}
}

alexdmiller
Offline
Joined: 2007-02-21
Points: 0

I maintain a page of possible features for Java 7 at http://tech.puredanger.com/java7. Also, I post weekly updates of new information that is coming out on my blog at http://tech.puredanger.com.

Alex Miller

sxpert
Offline
Joined: 2007-03-08
Points: 0

if you ask me, the *one* thing that would make this new version useful would be if it featured (finally ?) a firefox plugin that worked in gnu/linux/AMD64 environment.
see, I'm currently stuck with blackdown 1.4.2_03 and this is getting rather old and useless, now that everyone and their mother compile their applets with 1.5...

talden
Offline
Joined: 2006-06-19
Points: 0

Another area I'd like to see given attention in Java 7 is programming by contract.

Even making the changes as low impact as possible by limiting changes to nothing more than optional annotations you can get some interesting improvements in method definition.

Adding a simple @NeverNull annotation (method return values and arguments) would allow the compiler to be able to evaluate whether code might illegally allow a null value to be returned or passed as arguments. It would also allow IDEs to establish whether unnecessary defensive code is unreachable.

The annotation would need to propagate by inheritance and implementation so the retention would need to be class but not runtime.

@NeverNull
public static Value greatest( @NeverNull Value s1, @NeverNull Value s2) {
return s1.compareTo(s2) >= 0 ? s1 : s2;
}

This method would guard at compiletime against invocations with nulls and indicate that the method can also never return null.

Now consider an overloaded version that will delegate to this method. This overloaded version will accept an array of length 2. We need to test the arguments to satisfy the compiler that nulls cannot propagate to methods where they would violate contracts.

@NeverNull
public static Value greatest(@NeverNull Value[] pair) {
assert pair.length == 2 : "This method only accepts arrays of length 2 (found " + pair.length + ")";
assert pair[0] != null : "The first item in the pair was null. This is not allowed";
assert pair[1] != null : "The second item in the pair was null. This is not allowed";

return greatest(pair[0], pair[1]);
}

Comments?

Are there other annotations that might help a programmer to better communicate their intentions to the compiler and other developers?

jaypeevoss
Offline
Joined: 2004-02-20
Points: 0

Have a look at JSR 305: http://jcp.org/en/jsr/detail?id=305

That might make into JavaSE 7.0.

Regards,
Jens

tecgnull
Offline
Joined: 2006-07-22
Points: 0

How about a better (for example: Executible MIMI types, *.jar, *.sh, *.pl, *.py, *.pyexec, etc.) executables and identification system for all executable MIMI types for all plattforms of all plattforms.

KDesktop Environment needs more support than it currently does.

Gnome Desktop needs more support and features than it currently does.

MS Windows Vista ( Redmond Vista OS ) needs more support than it currently does.

MacOS needs more support than it currently does.

Linux and Unix needs more support than it currently does.

Solaris needs to be more user freindly then it currently is. I can not seem to get the user accounts to work on Solaris 10. I am always stuck using the root super user account. Oh well, I like Redhat Enterprise Linux and Fedora Core.

We need a Java, Perl, C++ and Python build of our favorite Flashplayer, Shockwave player and Autherware utils and to combine 'em with the JRE, JDK and NetBeans.

How about a Net Beans based control station plug-in(s) for all OSes and GUIs

sarima
Offline
Joined: 2007-02-26
Points: 0

One Vista feature I would very much like to see is compatibility with the Aero interface. I find it rather annoying that running a Java app kicks me out of Aero into the Basic interface.

talden
Offline
Joined: 2006-06-19
Points: 0

When we start talking about what we want fixed rather than what is planned it's easy to turn up a myriad of stupid little JDK short-comings that have been there, for all intents and purposes, since the beginning of time.

Consider the effort of getting the Class instance for a '2 dimension array' for the class X.

This is the only way right now AFAIK.

Class c = Array.newInstance(X.class, new int[2]).getClass();

Of course the JDK should be able to provide this without generating two superfluous array instances and should be an inverse method for Class.getComponentType() (and should be located on Class).

This would be easily solved by adding the following two methods.

Class Class.getArrayType(Class c); // A true array (1 dimension)
Class Class.getArrayType(Class c, int dimensions); // Shorthand for deeper dimensions.

This has, it seems, been a task Sun has been unable to solve since August 1997.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071439

How many more of these obvious cleanups are there in the Bug Parade - here I'm only referring the small easily solvable problems for which the only existing solution is an inelegant performance-eating mess.

It would be nice to find, solve and close as many of these trivial issues as possible.

sjasja
Offline
Joined: 2004-08-15
Points: 0

My tired old PC can execute about 3,000,000 of those Array.newInstance() statements per second. Is there a common class of programs where that presents a serious performance-eating problem? And where that statement can't be executed once and stored in a variable, or moved out of the innermost performance-critical loop of the program, or executed for all needed classes and the results stored in a hash table for a quick lookup?

I'm just thinking if there would be any problem in adding a myriad little features for once-in-a-blue-moon corner cases that can be done some way already. A problem such as complexity and learning curve (see C++, Perl 6, and the Second System Effect). So I think it would be nice to see a real non-artificial business case for each feature.

talden
Offline
Joined: 2006-06-19
Points: 0

There are 3 issues to deal with

1. Unnecessary performance costs. Yes it's not large but there are situations where the process is both data-driven and of a massive scale. Caching the results and identifyign it as equivalent to subsequent requests incurs overhead, effort and maintenance complexity all unnecessary with this small fix.

2. Unnecessary garbage. GC pauses are always undesirable but some applications have real-time demands on response with a granularity smaller than human observance. This small change would eliminate this cost without introducing the overhead of cache management.

3. Simplicity. Class has a getComponentType for the cases that require it. There are, admittedly, fewer cases requiring this fix but they do exist - message archives on the web, our own demands and the registration of a Bug Parade entry show that an inverse is required for a few cases. The solution is more elegant, more logical to find in the documentation and closes a gap in java reflection that currently requires that is currently a hack workaround.

This fix lowers the learning curve. It's simpler and more obvious than the current workaround.

ivanooi
Offline
Joined: 2005-06-27
Points: 0

Java Module System (JSR 277),
Java Kernel and

Solve Java I/O problem and make it fast start up time. (Adobe Flash speed)

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

> Java Module System (JSR 277),
Yes, quite interresting.

> Java Kernel and
I am looking foreward to hear eaxtly you guys crying for this about your app not running because the user is not always connected, and that the idea is great but Sun implemented it wrong, to be continued...

> Solve Java I/O problem and make it fast start up
> time. (Adobe Flash speed)
Short answer: Impossible.
Word-6.0 loads much fast than Word2007. Thats the price to pay for functionality and flexibility java has.
I also complained about that a lot - but today where a 1Ghz-P3 can be sonsidered as low end startup time of java is mostly a no-brained. (because most people work on 2ghz+ machines).

lg Clemens

talden
Offline
Joined: 2006-06-19
Points: 0

>> Java Module System (JSR 277),

> Yes, quite interresting.

>> Java Kernel and

> I am looking foreward to hear eaxtly you guys crying
> for this about your app not running because the user
> is not always connected, and that the idea is great
> but Sun implemented it wrong, to be continued...

Agreed in part, this one is likely to bring many headaches - It's also likely to improve acceptance of java desktop applications (especially if the packaging and deployment information in the java modules help extend this incremental distribution to client packages as well (with a minimum of fuss)).

In reality I think most developers are well aware this may not truly reduce the total transmission times for end-users. It may very well help deliver user gratification at an earlier point in acquiring an application for the firs time.

This is likely to be critical for wider acceptance of desktop applications and applets.

>> Solve Java I/O problem and make it fast start up
>> time. (Adobe Flash speed)

> Short answer: Impossible.
> Word-6.0 loads much fast than Word2007. Thats the
> price to pay for functionality and flexibility java
> has.
> I also complained about that a lot - but today where
> a 1Ghz-P3 can be sonsidered as low end startup time
> of java is mostly a no-brained. (because most people
> work on 2ghz+ machines).

I have to disagree here. While improvements are probably unlikely to reach 'adobe flash' startup times, there are numerous things that can be done to improve the IO throughput during a JVM invocation that could help startup.

Suggesting current startup times are to simply be accepted 'as is' is to turn a blind-eye to the expectations of the users accustomed to technologies that do exhibit much faster startup.

The java modules work might actually help this process with a tighter packaging format, better indexing of content and clearer expression of dependencies. A pre-loading mechanism might take advantage of the information to improve IO throughput (albeit most likely at the expense of larger initial heap requirements).

talden
Offline
Joined: 2006-06-19
Points: 0

Just a bullet-list of 'probables' and 'possibles' would be nice.

We have the myriad RFEs from the bug-parade as an implicit 'wanted' list - It would be nice to know what various contributors realistically (or even hopefully) expect to be working on and perhaps what high-demand features are yet to find contributors.

It's sounding like some sort of closure notation has at least made its way onto the 'possibles' list (or is it more likely than that).

kari_cz
Offline
Joined: 2007-01-31
Points: 0

of course, example is for 5.0