Java 8.0 Wishlist

We Recommend These Resources

With Java 7 almost out the door talk has now shifted to Java 8 and of course it's the perfect time for me to add my own $0.02 on my own wishlist.

Properties.
Dunno what you can do here without annoying a few people. However I'd happily settle for some type of shorthand notation for getters and setters.

Operator overloading.
This one pops up at just about every Java release. Now it seems that there are plans in the works to add indexers to collections and such like. Quite frankly if you're gonna do that, why not add a full complement of fixed operator overloadings, maybe taking some ideas from how Groovy does it

Alternative deployment formats besides the JVM and a class path.
When you have to do one of those client Java applications that everyone claims nobody does, the Java deployment model really bites: Basically I want to create a fully contained application for a target platform. Now if all this contained application does at the end of the day is bootstrap a JVM together with a classpath who cares. It's also worth pointing out that this would allow Java applications to run quite easily on iOS, that is; if someone takes the time to do the port.

Parameter names in method calls.
Nice to have, but it would make DSLs in java nicer.

Finish Autoboxing.
I still can't do 1.toString().

Proxies on Abstract Classes.
Not sure about the technical constraints on this, but it would be great if you could also create proxies on abstract classes and not just on interfaces.

Make JavaFX useful.
Ok so JavaFX is not actually part of the JDK. Whatever the case, it's Oracle's chance to make client side Java really slick.

Well that's my list for now...

From http://dotneverland.blogspot.com/2011/04/java-80-wishlist.html

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Fisher replied on Wed, 2011/04/27 - 12:24am

Cleanup the classpath... get rid of stringbuffer, date, etc

Annotation based JMX

Michal Xorty replied on Wed, 2011/04/27 - 1:27am

Operator overloading is disaster, it makes code much less readable. As for properties - IDE autocompletion works better with bigger classes, when you type "ge" you get list of your getters and when you type "se" you get list of all your setters. So you don't have to remember names of properties so much.

Properties look better at paper, but are actually harder to use with bigger classes.

Alexander Smirnov replied on Wed, 2011/04/27 - 3:08am

1) Proxies for all classes, including concrete ones. It's already here - JEE, JDO, Spring, Guice and others do that, with a hacks like bytecode manipulation. 2) access to the Classpath content or annotation scanner at runtime. Once again, it's already in production systems. 3) Some kind of 'binding' , for GUI components. Dream about typesafe UIxxx.setValue(myObject#property);

Andrew Osipenko replied on Wed, 2011/04/27 - 3:46am

The feature I would like to have most of all is method annotations to check pre and post conditions.

For example annotation could check that parameter being passed is not null. Then this annotations can act as docs and assertions in the same time.

It will be fantastic to teach compiler to consider this annotations also.

Pavel Tavoda replied on Wed, 2011/04/27 - 3:57am

PLEASE:
- no operator overloading
- no properties

DSLs in java are fine. Just do it right.
Your autoboxing sample is just academic debate. Nothing practical.

Is anybody here developing rich GUI application in Java? Go for WEB e.g. http://www.smartclient.com/smartgwt/showcase/
You have much richer set of components than in JavaFX.

Dominique De Vito replied on Wed, 2011/04/27 - 4:06am

properties => we don't need that if we think get/set methods as access boxing.
Just read Next JDK wishlist-6: let's simplify the use of get/set methods

And to say the truth, I am not very fond of operator overloading.

I have another suggestion.
Take a look at how Orache Coherence is managing data.
Today, it's difficult and not efficient to put data in JVM memory but off-heap.
So, Coherence pushes users to put data on SSD, instead of in memory but off-heap.
Then, at first glance, it looks like I/O Java management code is better written than the Java code to manage the data in memory but off-heap! And from that point of view, it looks like a shame...

So, for JDK 8, I strongly would like an efficient way to define, manage and use data areas in memory but off-heap, that is a much more better direct java.nio.ByteBuffer implementation.
For such features, Java SE may take inspiration from Java RT.

Or, may be a simpler way (and also the way I prefer) is to do the following:
- allow users to allocate primite type arrays (like byte[], int[], etc.) in memory but off-heap.
- such primite type arrays would be used like ordinary array counterparts, but would be stored off-heap, just like direct java.nio.ByteBuffer instances.

Hontvári József... replied on Wed, 2011/04/27 - 4:25am

Getters and setters must be completely eliminated from Java, either with properties or otherwise. A class with 40+ getters and setters and 3 meaningful funtions is as awful as it is possible. The feel of temptation to remove those 3 meaningful functions just to make the class more clear is even more awful. The idea linked in by Dominique is good from a user point of view, but I would add that implementing it is far from being trivial, because already compiled classes currently does not notice the introduction of a getter/setter.

David Grace replied on Wed, 2011/04/27 - 5:09am

1. Modulize the JRE so it is faster, has faster startup and is less memory intense.

2. Massively improve deployment process.

3. Complete JavaFX.

4. Get the JRE on more platforms - Make sure MAC is covered as good as Windows - Android? iOS? etc

Surely these are achievable, and more important than these 'language' modifications?

Andrea Del Bene replied on Wed, 2011/04/27 - 6:25am

There's one feature i DON'T want in Java and is 'Extension methods'. I find this feature very anti-OOP and confusing.

Charlie Mordant replied on Wed, 2011/04/27 - 7:34am

C#-like getters and setters for more readability

Jess Holle replied on Wed, 2011/04/27 - 7:44am

When most folk ask for properties, they're largely asking for uniform access, i.e. so they can refer to:

public Foo bar;

and

private Foo bar;

public Foo getBar() {...}

public void setBar(Foo bar) {...}

the same way in the rest of the code. That's fine and good *but* they generally insist on using obj.bar syntax for this. There's an issue with this -- the meaning of all existing code that makes a point of accessing the field directly is now changed. Even without existing code, I believe this is just too subtle. How do you access the field without the accessors? Within the implementing class? Within other classes in the package if the field if the field has package-level access?

If you simply use "->" rather than "." here, then all such issues go away. Yes, you need to type one more character, but in return there is no funny change in meaning in any existing source code and no ambiguity as to when the accessors are to be used.

Jess Holle replied on Wed, 2011/04/27 - 7:51am in response to: bitstorm

Agreed. Extension methods are awful. I'm not sure that they're anti-OOP, but they're a confusing mess in any case.

That said, the *default* methods proposed as part of interfaces in Java 8 are a very nice alternative. Unfortunately, Oracle folk seemed to be considering introducing unnecessary syntax to make people call these extension methods, when they're not -- they're a much cleaner alternative.

On a related note, I would like to see Java have traits. They don't need to be called traits. Really they can just be interfaces with more generalized default methods than those proposed for Java 8.

Michael Fortin replied on Wed, 2011/04/27 - 7:53am

I’d be content with letting Groovy and Scala take the niche or DSL’s and properties, keep java fairly simple.
I’d like to see the libraries cleaned up and reorganized, and remove deprecated code. Have java start with a switch for legacy libs or the new minimal lib set, (no swing,etc). I’d also like to see the jvm easily distributed, and bring some cloud computing lessons learned directly to the jvm. Have the jvm launch on many os’s, discover each other and automatically distribute a deployed application.

Erwin Mueller replied on Wed, 2011/04/27 - 8:34am

Properties

A big no to C# like properties. Everyone who claims there are shorter to read or whatever:

First I need to declare the attribut and than I need to declare the property again? Than I have 3 levels of indentation just for one property, add if-statement and you have 4 levels, add a namespace (C#) you have 5 levels of { }, you got to be kidding?

Yes for Groovy like properties. Add a new keyword "property" (or whatever) as an access modifier, so I can access the property as getPropery setPropery or as object.property.

Operator overloading

No way in hell. Op. overloading adds nothing to the language and complicates the language too much. Just so you can write file << "text" instead of file.write("text")? But think: with file.write() you know what it means, how about file << "text"? Does it mean "save", "append", "add to file" or something else?

Operators should be defined in the language so everyone can read the language and understands it without knowing a large context. Why is math so easy? Because everyone knows that 1+1=2. If you have op. overloading it could mean 1+1=11 or something else. Why confuse people more than it's needed?

With op.ov. is just that: confusing people for no good reason. Now the reader of your code can't just trust his knowledge of the language but needs to ask himself every time he sees an operator if some trickery is behind it.

Parameter names in method calls.

Useless. Why are programmers always think this is the best thing since sliced bread? Just use variables, is it so difficult? Instead of writing foo("text", "more text", "even more text") just use variables and write foo(name, description, helpText).

Further, if you have a method with many parameters, than you have a bad design. A method should have maximum of 3 parameters. You even have Enums to name them, so instead of foo(5) you can write foo(MyTypes.SomeNiceType).

I think people who ask for named parameters wants just cover up their 10 parameters methods with no enums and integer or boolean flags.

My opinion

Java should remain a conservative language with a solid JDK and a fast JVM. Let the other languages do all the stuff like op.ov., named parameters, DSLs, etc. There are many languages out there who already filling this gap, like Groovy, Scala, etc.

My wish would be closures, because there are many issues closures are solving really well and reducing the amount of boilerplate code in Java. But besides closures, I don't want Java to be changed at all.

Oracle should more concentrate on tools, swing, the JDK and the JVM. It should make the other languages a more easy time by making them faster and make new languages for the JVM more easily to get developed.

With the rise of Groovy, Scala, Python, Ruby we should really abandon the idea to have one language to rule them all, like to shove in to the language even more stuff (like in C++).

With the JVM it's so easy to just mix the languages that are suited for a specific task, and thank to the JVM and the JDK they can all integrate well with each other and with the core Java.

Javin Paul replied on Wed, 2011/04/27 - 9:16am in response to: cj91

I am wondering if Java 8 even remain open source , its now Oracle and Oracle is not a big fanof to giving something free or open source , they might ask for license of using Java going forward :)

My ultimate wish is Java remain Opensource as it is now .

Javin
How HashMap works in Java

JD Evora replied on Wed, 2011/04/27 - 12:30pm in response to: Xorty

> Properties look better at paper, but are actually harder to use with bigger classes.

I used to be a Delphi programer and I can asure you that properties is one of the big things that I miss from those days.

Jonathan Fisher replied on Wed, 2011/04/27 - 1:13pm

I also vote for NO operator overloading. Horrible for so many reasons...

Maybe instead of getter/setters, we could annotate public fields with

@BeforeSet(#methodName)
public String field0;

public void methodName(String field0){
 //do something
}

Dan Howard replied on Wed, 2011/04/27 - 1:24pm

Properties. NO. No good conventions for this and they can hide performance defecits in code. Explicit setters ans getters are OK as-is.

Operator overloading NO. OMG how many times does this LOUSY idea have to be repeated?

Magnus Smith replied on Wed, 2011/04/27 - 3:00pm

There are some great ideas coming from Scala.

I love the match functionality it is just so much more powerful the switch

Imagine being able to switch on regular expressions, types, evaluated expressions, ..

Also how about the compiler giving us more meaningful equals and hash implementaions for free.

Also I think a big thing has to be to reduce all the java boilerplate stuff around beans.

Liam Knox replied on Thu, 2011/04/28 - 12:29am in response to: cj91

Yeah, get rid of date etc... Sounds an absolutely great idea if you want to break 99% of all backward compatability across the known Universe. Thankfully they won't be doing that.

Liam Knox replied on Thu, 2011/04/28 - 12:34am in response to: cj91

And how does this improve anything ? Seems like your just increasing the complexity and making the language less concise. I can see reasons for precondition annotations like @NotNull etc. but to add more tenious hops around your code base just seems looking to solve problems that arent there. Personally I never really bought properties. They really dont add much in any mertic.

Magnus Smith replied on Thu, 2011/04/28 - 3:43am in response to: andrewosipenko

check out the new hibernate validator 4.2. It does method annotations to check conditions.

http://musingsofaprogrammingaddict.blogspot.com/2011/01/method-validation-with-hibernate.html

Martijn Verburg replied on Thu, 2011/04/28 - 5:52am in response to: cj91

Modularisation is coming in Java 8 and will effectively get rid of the CLASSAPTH
StringBuffer and Date will almost certainly never be removed. However it is very possible that Date might be set to @deprectated as JSR-310 (new date and time) will hopefully replace it in Java 8
JSR 255 (JMX enhancements) is currently inactive, I encourage you to jump on their mailing list to show interest and help get it started again!

Cheers,
Martijn (twitter: @java7developer, @karianna)

Martijn Verburg replied on Thu, 2011/04/28 - 5:57am in response to: dutchiedave

This is happening under "project Jigsaw"
See above, interoperability with OSGi is a goal
Full Java FX 2.0 should be completed by this time (e.g. The embedded Webkit engine)
MacOS will be covered, but at this stage only because of a strong OpenJDK community around that port. Android? Pending lawsuit iOS? Would require Apple's permission - short answer - ain't gonna happen

Martijn Verburg replied on Thu, 2011/04/28 - 6:01am in response to: javinpaul

Java will remain open source, period. It's GPL licensed. Yes there is the eternal debate/battle calling alternative implementations 'Java' (due to TCK field of use restrictions), but Oracle is not going to charge you, the developer for Java. It would kill it dead, fast.

Josh Chappelle replied on Thu, 2011/04/28 - 9:37pm

I really like the idea of alternative deployment formats. The java "write once run anywhere" is great but in reality a lot of companies have a target platform that they support. If they spend some time on a deployment mechanism that would be great. However, I disagree on the autoboxing feature. I can't think of a use case for this. As we all know there is only so much time to develop new features so it would be best if they spent that time on developing things like the deployment mechanism, which has real world value.

David Whatever replied on Thu, 2011/04/28 - 11:42pm

Method generation of getters and setters via field annotation or other mechanism. If I want a pure data object to be a bean I should not need to write a single method.
Code generation via annotation (for example, checking an input parameter is @NotNull , @NonNegative, @NonEmpty, etc.). This would be a field annotation on getter/setter generation, and a method parameter annotation on traditional calls.
Modularity built into JVM. This should help create a faster download and also make the difference between the JDK and JRE command-line tools, samples, and JNI headers.
Superinterfaces/Extension Methods/Concept Maps or some other mechanism to allow closed objects to

Be adapted to an interface without requiring the class instance to be wrapped
Gain additional functionality as if additional methods were added to all instances of a class or interface implementation.

Using the above mechanism for importing functionality and modules, take all deprecated methods and objects from Java 6 and before and move them to separate modules
Deprecate Enumeration and banish it to a module. Rev Servlets and other specs that still use Enumeration (over a decade after Iterator came out) so that they stop
Consider properties over get/set syntax. If EL can drop getters/setters, so can Java.
Make EL a core module for interacting with beans
Evaluate apache commons and other popular third party libraries for ideas to move into java.lang and java.util
As an example, finally provide a way to do Base64 encoding/decoding in the JRE
As another example, provide a decent HTTP client library
Operator overloading, if done, should be shorthand for regular java methods with operator precidence applied, e.g. a + b * c should be evaluated as a.plus(b.times(c)). I personally don't buy the 'hiding complexity' argument, as you should be writing code first and profiling later once you determine you are not meeting your performance requirements
A whole lot more closures
Reified Generics

Liam Knox replied on Fri, 2011/04/29 - 2:30am in response to: dwaite

I would say most of this is redundant. Indeed the idea of apache common libs seems mad. Google collections is almost valid but the idiots inflict it with @Guice or @Andoid which makes me think that Kevin, Bob etc. know about as much about design as Adam.

Indeed don't use Google collections because we've bundled it into another load of crap that you wont use because a) we don't understand modularity and b) the platform doesn't... Hint...

Closures, yes minimal please. Generics, it was a Sad experiment but yes it should be closed. The main problem with the language is inconsistency in the primitive and reflection points. That can be improved but should never be at expense of compatibility

Face it Java is not very bad and thankfully will out last us all.