jMar"s Blog DevSmash Developer Portal

Tuesday, March 11, 2008

My Java 7 Wishlist

Well, the JDK7 Project is underway, and despite the fact that I am being moved into the .NET world for some new projects, I wanted to leave some parting thoughts with the Java community. By no means do I consider myself the ultimate authority on the following topics, however, these are a few things that I propose would make Java a better, more friendly, more flexible language.

So here they are, in no particular order, my wish list for Java 7:

1. No More Primitives!

Seriously, primitives had their place and their time, but it's time to let them go. If you're using a boolean instead of Bool to save system resources, then you need to get a server that was made in the last decade. Performance is no longer a valid argument on this one (and that was about the only argument there ever was). OOP is OOP and primitives don't belong in OOP!

2. Tuples

Let me put it this way... how many times have you wanted to do something like this:

return (object1, object2);

See, now you want tuples too. Of course you always have the option of shoving them into some sort of a generic Collection, and then recasting them on the other side. But here's the problem: Collection's are meant to hold a collection of objects, they are NOT intended to be a form of community transit.

Another cool thing about tuples is they let you swap values without using a temporary variable, e.g. (x,y) = (y,x). That one's just for free...

3. Singleton Class Modifier

Do we need it? No. Would it be nice? Absolutely. Just let rules of a singleton Class be handled by the JVM, rather than leaving "singletoness" to be implemented by the designer. I suppose more importantly, singletons would be made thread safe by the JVM, a consideration that is often overlooked by singleton design patterns.

4. Scriptlets Inside JSP 2.0 Custom Tag Bodies

Ya, I know this is JSP, not strictly Java - but I'm stroking with a very broad brush here. I mean, why in the name of all that is good can't we do this?? Yes, scriptlets are inherently evil since the advent of JSTL, but what about those of us cursed with terabytes of legacy code that we do NOT want to convert to JSTL functions? Presumably custom tags still implement doBody() at some point or another, which already supports scriptlets. So again, why???

5. Heredoc String Support

This again is something that we don't need, but that I would definitely like to see. Java developers generally externalize any Strings large enough to justify heredoc format into a properties file - but this has its limitations; take for example a String that needs to contain a variable. I really don't care how it's implemented (e.g., StringBuilder, StringBuffer, plain Jane concatenation), but I want it.

6. Closures

While Java let's you get close to closures (using anonymous inner functions), your code ends up being really ugly and hardly readable. I think closures would be a big step towards making Java a more flexible language (without hurting your eyes at the same time).

7. Rationalize the Collections API

This would be big, it would be rough, and it would make a lot of developers angry. The idea of it actually scares me a little, but I'd contend that it has to happen sooner or later - and the sooner the better. Since my whole argument here is completely stolen, I'll just let you read it at the source.

And that's it. I wanted to make it a top 10 list, but I really didn't have enough to go on. I realize several of these topics are controversial - so let's hear it in the comments.



17 comments:

Mike Thomas said...

Nice choice moving to the .NET platform. We have closures here... :)

Good to see you blogging - quite interesting.

-Mike

Jeremy Martin said...

Hey man - thanks for leaving a comment. And just since I know it'll make you happy - we'll definitely be coding in C#!

Tech Per said...

+1 on no more primitives, tupples, and closures too I guess. If we get closures, I guess there will be real good value in reorganizing collections api too.

For the rest of them, I don't care :-)

I feel for you, making the move to .net. C# is nice, but you will have to live with Visual Studio :-(

david said...

Can you elaborate on item 5? Don't really get what you mean.

Ivan said...

my java 7+x wishlist:

copy the syntax of c# 3.

i love java and the fact that sun opensources everything around it. but most people inside the java community seem to have strange ideals like:
- nooo operator overloading! evil! too complex! misuse possible! better wrench yourself without!
- properties the c#-way? nooo! evil! "i hate properties" "me too" "yeah me too" better do getThis() setThat()! it's not annoying! its toootally comfortable! ok, IF we ever introduce properties in java, then NOT the c#-way, we better invent some own crappy syntax. but be aware! misuse possible! better wrench yourself without!

possible misuse of proposed features seems to be a very 'powerful' argument. here my example of misuse:
one can compare the current system time with the number of running threads. it really works! it is misuse! so better introduce a special NumberOfThreadsClass and CurrentTimeInMillisClass, to avoid this ;)

sorry for flaming. still remember: i love java and it's opensourceness!

to c#'s dependence of visual studio: http://monodevelop.com/ ;)

Anonymous said...

primitives: i agree, but too difficult to fix.
tuples: i do not agree. necessity of tuples are *usually* result of bad design.
singleton: it is ok, not a must.
scriplets: nope. almost nobody uses scriplets anymore.
Heredoc what?
Closures: not a big deal. i prefer simple comprehensions. But it is ok is syntax is clean.
Collections API: i think one of the strongest and most elegant part of the Java API is the collections. only issue could be making them part of the language. list, set, map etc.

mantrid said...

yeap, I also think tuples are result of bad design. if you need to return several values, you want to return a data structure - that's what classes are for.

closures would be nice but I'm almost sure it will hurt your eyes baaadly..

personally I'd like properties in c# style

I think I'm gonna have a look at groovy..

Jeremy Martin said...

@David
I assume you're asking what heredoc is? PHP is an example of a language that supports heredoc syntax. This page shows a PHP example: http://www.hudzilla.org/phpbook/read.php/2_6_3

david said...

Thanks for the pointer Jeremy! To be honest, I don't really see where I would need that. I'd rather have built-in XML support like Scala.

Ogma said...

Nice list. +1 on tuples.

Those who voted against tuples are mistaken to think it is primarily to avoid defining a class.

The usefulness of returning multiple values is similar to the usefulness of passing multiple arguments into a method. Surely, few think that passing multiple arguments is trying to avoid defining a class for this "tuple" of parameters, nor are passing multiple parameters into a method more of a sign of bad design than wanting to produce multiple values.

Jeremy Martin said...

@David
On several of the projects I've worked on we've used some sort of a "DisplayUtil" class for generating highly dynamic markup. Heredoc would just be a convenient syntax in the case where you need to generate several lines of markup (for example). And I would maintain that this doesn't violate separation of concerns, as the class exists solely for presentation.

@Ogma
Couldn't agree with you more!

Anonymous said...

"Tuple": don't you need out/ref parameters?

Anonymous said...

We are working on Java Tech for 10+ years as I see the most disadvantage of Java is now ,
its still Virtual , for 10+ years of experience I've seen is , always hardware friendly software won the race like
OpenGL and DirectX on Graphics side.
Hardware compatible systems forces developers to use them as a standard more.
If OpenGL was just software layer , all people would do their own Engine.
But its stopping them to use they use them for best performance.
And for end users , they are happy because OpenGL hardware friendly and
that makes OpenGL very fast and make both end user happy.

Whats the lack of things on Java Tech ?
Its still Virtual Machine.
Java should be real machine on PC's !!!

As i read , AMD LWP will be released for .NET and Java VM
but in my opinion , it cant help Java for to be faster.
Java has IO and memory problem so how can these problems can be solved ?
In my opinion , if you implement simple Gigabyte i-RAM on 1 PC ,
http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180

You will see Java will run very fast startup time and class loads , image loading operation will be very fast !!!

That means on just IO operations java will be faster.
Yes but its not solving problem %100 , so ?

You should implement static caches for Java on PC's instead of making java on Operating System.
Some people know about UPNP ,
I've opened JUPNP project on dev.java.net :

https://jupnp.dev.java.net/

UPNP is now being used on hardwares of PC's on modems especially!
But i wished to see JXTA on ADSL and future of modems.
JXTA would be cool technology having all modems these tech.
UPHP doesnt have capabilities what JXTA has !
But it forces developers to use UPNP because all hardware modems have that Technology!


The most disadvantage of Java Swing Apps is ,
They all store their Swing Images on HDD ,
They also should be stored on GPU hardware.
Yes I've read Java can access on GPU too but i mean all swing images and object must be in seperate static cache of Graphics card so
when PC startup , they must be loaded on Graphics Card.


Java must have a classes that accesses,
MMX , SIMD capabilities of hardwares.
But they shouldnt be done on JNI !!!
JNI makes penalty calls , they sould be native instructions.


You should make new Generation of PC's having
static java caches like Gigabyte iRam
same iRam should be on Graphics adapter Swing too...
Maybe you say it will be expensive PC's but people paying 250$+ for DirectX compatible graphic hardwares!
think more how much cost iRam on Java/Swing Graphic Adapter or JXTA Compatible ADSL/Cable/?

If , these technologies will be done , i'm sure within 7 years Java will take place much and much more on markets!
Send Java and .NET Technologies to hell and as i read your all hardware servers is World's best ,
if you do same best hardwares for end users it will change destiny of Java/JavaFX.
Never think virtual , real machines!!!

PC's really important technology then any other technology to force people accept technologies!


Dont forget Java needs Fast IO Hardware System now!

Take care all Sun Group
Regards,
Kadir BASOL

Anonymous said...

Heredoc would be very useful for me.

I am dealing with large JSON strings

even for testing being able to create a large string within a source file, and then feed it to various unit tests functions would be great.

Also full and well-tested JSON support would be nice.
as this standard is becoming more and more popular due to it being a data structure description for every Javascript code outthere.

Thierry Milard said...

Very nice Post here.
I am a java + Swing + (beginer javaFx).
So a Front-end or "rich web client" developer ("à la Flash").

jmar, nice list of improvments you have here for java 7. I agree with you for a large number.
Nevertheless, I will tell you my three personnal wished fom java 7.



number 3: (1. No More Primitives!)
Oh yes, it would of course be a java-new language but this would be great.

Number 2 : (2. Tuples)
Oh yes this would be great to just sent back from a function more than one Instance.

Number 1: [this one is mine !)==>
A REALLY FAST VM + JNLP STARTUP-UPDATE
This is might most important issue. I admit there were some good sign with java 6 update 14. But Man, if you do like java-swing or java-javaFx on a web page, the process of having my jvm ready PLUS checking that other jars are ready ... takes still 10 seconds.
Way to much for a Web page.
This is STILL the BIG-ISSUE most Front end developpers desesperatly need the most. Only when it will take 2 seconds for the java+libraries to be ready... then I can go to my company CTO and say : "Flash is good but hè man : look whan we can do with java".

Jocelyn Ireson-Paine said...

Heredoc: suppose you could store your large strings in a JSP (Java Server Pages) file, and had a compiler that would translate this to Java which you could call from inside the method that wants this string. Would that be a reasonable alternative? I don't know whether such a compiler exists.

Which makes me think that the natural Java equivalent to heredoc would be the ability to include JSP notation in Java code.

valjok said...

> Performance is no longer a valid argument on this one (and that was about the only argument there ever was). OOP is OOP and primitives don't belong in OOP!

1. Wrong. Tasks scale with computers.

> Collection's are meant to hold a collection of objects, they are NOT intended to be a form of community transit.

2. Nonsense. Collections = transit. There is no need for collections if you are not going to transit them from one space/time to another. The true argument is coding. Collection wrapping/unwrapping makes it much more difficult.

> I wanted to make it a top 10 list, but I really didn't have enough to go on.

Let me add two:

8. .class keyword to the fields and methods of class, not the class name only. This would return the Method and Filed objects of the respected class. This would replace the ugly and fragile class.getMethod(String name) and make Pass-By-Ref a reality!

9. named arguments. This would make code more self-descriptive and optional arguments feasible (optional arguments are needed to replace the tons of overloaded methods, I do not consider ... a solution) http://valjok.blogspot.com/2009/01/programming-language-constructor-design.html