Thanks largely to the open sourcing of the JDK, 2007 promises to be the most exciting year in Java programming. With the developer community in the driver’s seat, expect to see Java programming propelled forward, backward, and sideways, probably all at once. This article takes a look at what’s ahead for Java in Open Source and predicts what is coming for the Java platform.
#1 Please restrain yourselves.
#2 Lets make it more modular. Strip out the deprecated stuff into a jar file that people can include if they rely on those classes. Make SWING/AWT separate so that if I have a command line only or web application I don’t have to include those things on my server. Those two things will help strip the size down.
#3 Let us FIX things before getting “radical”…see #1
I hope that open sourcing it will help Java more. I was not thrilled with it (less so because of GPL3) but since it is here and I do like Java lets make it better but not forget its purpose.
>#1 Please restrain yourselves.
I’m not sure that there is a real danger here: as long as these Java ‘extensions’ are clearly labelled as ‘not Java’, there’s not much danger in these experimentations..
Currently there is already Scala, Nice, Groovy, JRuby, Jython,.. and I don’t see people being confused.
Any extension to Java (the real thing TM) will have to be done by the JCP already in place..
I couldnt agree with you more on the deprecated stuff. And lets see them working on a multitasking VM.
Well, I must agree with #2. Not only must there finally be a pruning away of deprecated stuff (since 1.0, even), but there needs to be a logical rearrangement of the packages and a reduction in redundancy (for example, 3 different mechanisms for RPC, with 3 APIs?!). Make a clean break and have a fresh start with JDK2.0 (not Java2). Keep maintaining JDK1.x for legacy, but clear out the cobwebs and make it a sparkling efficient system. Bring back that “new car smell.”
Actually what I want to know as well is why Sun decided to bundle in Derby with the JDK! Its not as if the JDK needs more things in it…its about time they started taking things out!
“Actually what I want to know as well is why Sun decided to bundle in Derby with the JDK! Its not as if the JDK needs more things in it…its about time they started taking things out!”
Because it is a Java DEVELOPMENT kit? It is not in runtime that users get, its just a little helper database for developers to prototype with.
I agree to nearly everyone
Modularity, and getting rid of deprecated stuff should be prio 1. As is an MVM, if they really mean to conquer the desktop.
I wouldn’t mind if they really started a new “java #2”. I would like to welcome tail-call elimination, say goodbye to primitives, etc.
If only…
As the Bile Blog so profanely puts it ( http://jroller.com/page/fate?entry=gpl_java_who_cares ), outside developers have already been able to submit patches for the JDK and sometimes get them accepted (after GPL patches to official Java will still have to go through Sun). The only ones who couldn’t do so were those working on open source reimplementations who couldn’t look at the original’s code to keep the clean room clean.
While it will be nice to have them too, I think the real benefit will be the possibility of porting Sun’s VM to other platforms, places like Linux PPC and whatnot. Licensing issues with Linux distros will be another area of improvement. Personally I’m most excited about having Java in Debian main. I just don’t know that there will be a huge change in quality/speed as some seem to assume.
with java being opensource, regardless of whether changes must be approved by sun/jcp, will make it more interresting for free software people to work on it.
with lots more people interrested in it, working on it, its almost certain quality will improve.
This year there will be a true revolution on desktop, since KDE4.0 provides a complete desktop solution for all major desktop OSes. Java promised this since its beginning, but several attempts have failed. So if KDE4.0 will be as succesfull as say Firefox, so lot of people will install QT and KDE libraries on their computers, then it will be very easy to provide multiplatform applications.
Maybe Java makes sense on the server, but the battle for the multiplatform programming environment on the desktop will be lost very soon. Way to go QT and KDE. Java as a language may still be used with QT-JAVA bindings (Jambi).
I’m very excited by this,
Anton
Actually, I see java possibly being the answer to the KDE/Gnome common application problem. Imagine you build a java app with a default widget. Then when you run it on KDE or Gnome, it automatically uses the widget set that your Desktop uses. Then, people could build any DE they want and as long as it meets certain minimum requirements for widgets, you know all java apps will working in it without having to have libraries from all the different DE loaded.
This default widget set of JAVA is as alien to KDE/GNOME as the widgets from OpenOffice and Firefox. They do not really integrate into the desktop environment (best example cut&paste of anything except pure unformated text). So Java widgets just mimicry the look of the default environment without further integration. So unless freedesktop.org provides something really clever, which can also be integrated in JAVA I prefer QT/Jambi variant.
They do not really integrate into the desktop environment (best example cut&paste of anything except pure unformated text).
I think clipboard is actually a bad example, because Java, or more precisely AWT, handles the X11 clipboard just fine.
Copy&Paste problems are usually a bug in one of the applications involved in the transfer or in both, e.g. checking for any supported MIME type instead of using the most useful one.
If i want to release an KDE app as non GPL, then i have to buy a QT License that costs more than 3 complete developers workstations.
For Java there will be an classpath GPL exception, which means i can release software under whatever terms i like.
Also KDE for different OSses doesn’t mean multiplatform KDE apps. Whiles there obviously will be common librarys, cross compiling problems raising from different hardware like for examples endianess problems will still be around.
What I am not sure to agree with is the notion that “Ruby wins” when he write about the scripting languages support. It seems to me that variety is the subject of having that support.