Slashdot Mirror
State of the OpenJDK Project and Java 7
LarsWestergren writes "David Flanagan, the author of Java in a Nutshell, has a nice writeup on the state of the open source development of the next version of Java. The article explains the difference between the JDK7 and the OpenJDK projects and how to join them. Furthermore, it has an overview of the release schedule, proposed language changes and projects of interest. A more technical and in-depth tracking of the language changes and proposed new features can be found at Alex Miller's blog. This is the first in a series, and 'each future installment will provide an update on what's currently happening in the latest builds from the project, along with a deep dive into a new feature or API that's tracking for inclusion in Java 7.'"
Isn't the OpenJDK just a waste of time (or a reinvention of the wheel?). The Sun JDK is already open, with the source code available...
Simply happy to have a 'modern' jdk on a modern machine running a modern OS. Very slick stuff. :) Something new again? I call that real progress.
It sounds like they still have no idea which new language features will make it into the release. What is driving them to add new features? Are they just trying to move the language "forward"? If the developer community isn't pushing new requirements then why muck with the language?
No javaws, no Mozilla plugin.
Install Linux on your iBook and you're all set.
http://www.mhall119.com
Awesome, just what I've always wanted. Parsing XML is an extremely important requirement in determining the expressiveness of a language, mind you. Except, they're gonna be screwed when CSV files come back. And don't even get me started on what a pickle they'll be in when those .DAT files return to claim their rightful place!
As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.
Ask Apple. They're the ones that maintain Java for Mac OS X, which is why it's close to impossible to get a recent version of Java for any Mac OS X not released in the last three years.
Swing itself has better performance than AWT, it's just the way people wrote Swing applications that made them seem slow (like performing time-consuming operation on the repaint thread). Several additions to Java 7 will make it easier to write well behaved Swing applications.
http://www.mhall119.com
It's good to see that there is at least one project aimed at cleaning up old legacy code. The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib. The packages and classes need to be rearranged logically, renamed, made to have consistent API's and naming patterns. Redundancies need to be removed (like 3 different RPC schemes and APIs), and deprecations finally need to be pruned. Collections- and non-collections-containers need to be merged, and AWT and Swing need to be reconciled. There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that. And the long-promised merging of Swing and Collections needs to happen, too. (Like a popup list could be accessed as a java.util.List)
I have thought for years that there needs to be a "JDK 2.0" series started which would be a clean break from the 1.x series. Keep maintaining the 1.x series, but make a fresh start.
In the latest JDK6 and JDK7 builds, Swing has been replaced with something that doesn't suck in terms of performance and looks halfway decent-- it's called "Swing" and has the same API as Swing. Seriously, there have been vast improvements in Swing lately, from using hardware acceleration to themes that very closely match native L&F's. I'm not sure what year you last tried Swing, but give it another look.
In the latest JDK7 build, they even fixed the "mixing heavyweight and lightweight" z-order problem, so you can mix native AWT widgets into a lightweight Swing UI.
E pluribus unum
Can Swing please be replaced with something that doesn't suck in terms of performance?
;)
I think it is doing quite well these days. Have been working quite hard on the OpenGL and Direct3D pipelines. See this recent blog on OpenGL shaders for instance.
Can it also look halfway decent?
Now that they have open sourced it... let's hope.
Being bitter is drinking poison and hoping someone else will die
Swing made it easy to write bad code. I actually like Swing as a toolkit. The one problem for java applications is still startup time. I just don't know what can be done about that except preloading java at boot. Which is a waste if you are not running a java app that day.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
The default "cross platform" look and feel is indeed hideous, which is why most people would enable the native platform look and feel. The native platform look and feels were pretty bad in the past, but in Java 6 they're close to perfect, both on Windows and GTK. As for the cross platform look and feel, the Swing team have been working furiously to produce a modern replacement that will be available in a Java 6 update release early next year. It's called the Nimbus look and feel. Early screenshots available at http://www.galbraiths.org/blog/category/nimbus/ and http://www.jasperpotts.com/blog/category/nimbus/
Ahem: When was the last time you looked at Swing. Swing is very good performancewise nowdays. As for look and feels. In Windows and OSX, the skinning data is used from the underlying os, so nowadays in XP and Vista you will get excellent look and feel coverage (JDK6 that is) Same goes for the mac.
the main problem is still Linux/Unix and the GTK2 themes. As for other skins than the default one, Swing has been skinnable from day 1, there are several different look and feels out there in the wild, I guess google is your friend.
Besides that the current default L&F does not look too shabby anymore, it looks quite nice.
Yes, but Sun are the ones to whom Java success matters. If they cared about the Mac platform, they'd make sure the releases at least happened in the same year. Apple has never seemed to care much about Java. The only saving grace is that with the Intel switchover, the Apple JDK will be a lot closer to the Sun JDK. I would expect a rapid dropoff of PowerPC support in future JDK offerings on the Mac, because it will be so much easier to just tweak Sun's code than maintain your own JIT compiler and port to another ISA.
E pluribus unum
It's really cute to see that Java lately has just been playing a game of catch-up with C#. C# 3.5 has closures, is currently in beta 2 with a slated release date late this year and a launch event already planned for February 27th. C# also has pretty much every other feature slated for JDK1.7, either in the 3.5 release or in earlier releases.
And before people start complaining that Java is getting these ideas from other places, that C# copied them from other languages that had them first, you're absolutely somewhat right. I never claimed that MS or C# invented these concepts, but they are bringing them to market and now Sun is looking to do the same thing. Still not convinced? Look up the JLINQ project. IBM even stole the fucking name from MS.
The one problem for java applications is still startup time. I just don't know what can be done about that except preloading java at boot. Which is a waste if you are not running a java app that day.
Actually, Chet Haase recently blogged about the changes being done in this area. Unfortunately many of these quickstart "cheats" are for Windows only, when questioned about this at JavaOne they said they didn't have enough engineering hours to do this for other operating systems but would welcome community contributions to this with open arms.
Linux and other users WILL still benefit from the Java Kernel work by Ethan Nichola's team though, this will be backported to Java 6 as part of the Consumer JRE project.
Being bitter is drinking poison and hoping someone else will die
Try using the GTK+ native l&f. Everything looks very bad and wrong. None of the controls look right. Spacing is off. All the layout is weird. Font rendering looks awful. The select boxes look horrible and don't work properly. Nothing behaves correctly. Hell, even Firefox looks and acts more native than it and Firefox sticks way out and looks hideous compared to a truly native app. This is why I just use the 1993-ish ugly purple default Swing theme.
http://www.mhall119.com
Yes, I noticed that on a Java app I used, it did a very good imitation of a standard Windows XP open file dialog.
Except that I've changed my places bar with Tweak UI and have 'recent folders' and 'favorites' buttons from FileBox eXtender. Oops.
Pretty pretty please, if you're not programming for DOS, use a native GUI for rendering, and especially for dialogs. This is one of the worst forms of code duplication. It is directly visible to the user as a myriad of small inconsistencies in the interface.
Yes, Microsoft, we know you hate the blind, and that no one will buy the latest version of MS Office without the bling.
Do we have a decent declarative GUI language yet?
While I agree with most of your post, you should check out the Metamorphosis Demo from JGoodies.com. It really does wonders to make an app feel more native on Windows.
LOAD "SIG",8,1
LOADING...
READY.
RUN
ahh the horrible practice of hiding your applications startup time in the systems startup time. It is practices like that which make low end machines horrible to use and contribute to the feeling of bloat in a modern desktop OS.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Sun doesn't think much can be done evidently, seeing as they added splash screen support into Java 6 instead of actually fixing the problem. The problem being that they need to load megabytes of code to support the runtime environment when most of it doesn't get used. There's one word for that: bloat.
Man, I've been programming Java since 1.x (yah, yah, I know). Is it me or does it just seem like the versions are getting a little whacky. I don't do much Java programming anymore, but it always seems like a jump in major number was a big issue if you have to maintain apps. Shit, how many people out there in the 'real' working world use 1.6? Prob no one. Last project I did (for a major bank) required 1.4.2 and it was deployed at the beginning of this year.
I feel like it's great (again, even tho I'm not using it this year) that Sun is on top of stuff and 'looking ahead'. But I really wish they would do meaningful SMALL dot increments and quit shoving out a now major release every year or so. I know 1.5 was out a while ago. But why not keep making 1.5 REALLY super stable and optimized and make 1.6 ONLY the one with the new uber-Swing and whatever else.
It's sorta like Microsoft coming out with Vista even tho no one want's to use it cuz all the 'new stuff' (which seems to have been cut at the last minute) isn't stable. Continuously having big releases makes people feel like they have to abandon the older releases so they can focus on re-learning all the new features that haven't made it out yet. I've seen this on teams I've worked with.
I just think more stable, optimized, smaller point releases are the way to go. And Sun being an 'enterprise' company should know this.
I am TheRaven on Soylent News
I remember when Java was still in its first beta that Mitsubishi (among others, mostly Japanese) announced a Java CPU that executed bytecode in HW, not a SW JVM. It integrated a DSP, evidently targeted at consumer multimedia apps. Maybe a "set-top box" which was the main vision for "converged" PC/TV/network devices back then, around 1995.
What ever happened to Java CPU/DSPs? By now, if they'd worked out, I'd expect most consumer devices to include them, but I don't know about any. Maybe they required development of a "Java OS", which also never went "mass market". Where are they now?
--
make install -not war
Appears the reason for using TCP is that Java has no (cross-platform, at least) support for POSIX local sockets or even named pipes.
So, um, because I'm too lazy to dig through JDK docs right now - is this jEdit developers' fault, or is the state of local IPC on Java really this worrisome? I'm sure local IPC that doesn't depend on TCP/IP ports would be really nice and would undoubtedly help Java's desktop application adoption.
Perl got this right. If you want to concatenate strings (using the string concatenation operator
Automatic type coercion is, in general, a good thing -- it removes clutter (in the form of unnecessary function calls). However, it breaks down when using "overloaded" operators (that have different meanings in different contexts), when the context in which the operands are meant to be evaluated is ambiguous. It's not always obvious whether something is supposed to be numeric or a string. Perl's rules are that only strings can be concatenated and only numbers can be added. Obviously this can only make sense if the operators themselves are different. (The reason + worked OK in BASIC was that there's no automatic coercion [except between integer and floating-point, in dialects that support integers -- some BASICs treated everything numeric as floating-point]; you have to call STR$ to convert numbers to strings, or VAL to convert strings to numbers. In some BASIC dialects, auto-coercion was introduced and with it a new string concatenation operator, most commonly &.)
Also, ditch the requirement to have function arguments in brackets. They are just more clutter. The computer can work out for itself how many arguments belong to a function. I'd rather see than anyday.
Je fume. Tu fumes. Nous fûmes!
Well, it's a bit like VHS versus Beta with the tape loading. VHS machines laced up the tape when you pressed PLAY, then unlaced when you pressed STOP -- fast-winding was always done in the cassette. Beta machines laced up the tape the first time you pressed PLAY, and didn't unlace until you pressed EJECT -- fast-winding was done in the cassette if you hadn't pressed PLAY since inserting it, or with the tape laced (and so able to switch from fast-wind to visual search) if you had. I think Philips' weirdy-but-nice V2000 system allowed you to lace or unlace more or less at will.
One more area Apple has been neglected in the Java world is access to Core Audio. The limited support it used to have is now deprecated with no cross-platform replacement. I'm mainly interested in Core Audio Midi access from a web applet, and there are some third party (Plumstone/Mandolin, MMJ) jars/jnilibs which help, but have their own problems. Is there any other cross-platform web based technology to access midi? Flash perhaps?
The only open source java project worth noting these days is GCJ.
Anything deriving from Sun's JVM is over. Done. Good riddance.
Right. Because all we really need is an implementation of the language that's mostly compatible with a five year old version, and which as of the latest released version doesn't yet support generics, a critical improvement to the language definition that was made nearly 3 years ago now.
Can Swing please be replaced with something that doesn't suck in terms of performance?
So you don't like the packaged class library. Have you considered using an external library (e.g. SWT) to achieve the same thing, rather than complaining about the packaged one?
The fine folks at Red Hat have been working on the IcedTea project to replace all the non-GPL'ed parts of OpenJDK with the appropriate bits from GNU Classpath.
high like someone above said, much of the real world is perfectly fine with 1.4
What stability do you need? I've been a full-time java programmer for 7 years and have yet to see real instability at the JVM level? Also, to answer your question, I am using JDK 1.6 for a large enterprise project on a 20 node cluster supporting 200k users. I'm not using any language features (because there really weren't many), but we do use the hot spot profiler. We moved to the JDK 1.6 recently to take advantage of the performance refinements. I don't have good benchmarks for you, but I noticed high single-digit performance increases, particularly on server startup.
Do you genuinely have an issue with Java stability or are you simply having a bad day and taking it out on Java?
Regarding your statement about smaller releases, the language has much room to grow and refine itself. Look at Groovy's multi-line String operator or collections syntax as an example. I'd LOVE to have that in Java. It seems stupid to do things a certain way simply because that's what you're used to if there are superior alternatives in terms of simplifying the code and increasing developer productivity.
"Try using GTK+. Everything looks very bad and wrong..."
:)
There, fixed that for you.
- I don't need to go outside, my CRT tan'll do me just fine.
Anybody else confused by Java's branding and versioning? Stop calling version 1.7 of the language Java7. When Java2 was released, I thought it'd be Java 2.0; no, it was Java 1.2.
Now we have OpenJDK, Blackdown, Sun, and so on... Somebody should take Java, call it "Java," and give it logical versioning like Java 1.6.0 and Java 2.0.0. Worked for Linux and Apache. It could work for Java too.
OpenJDK-1.4.3 is the SOLUTION to ALL the PROBLEMS!!!
.class files can be easyly decompiled.
OpenJDK-1.4.3 = like 1.4.2 + features from C.
OpenJDK-1.4.3 = like 1.4.2 + enum + varargs.
Genericity is forbidden.
The generated
> When was the last time you looked at Swing. Swing is very good performancewise nowdays.
I didn't benchmark anything but I don't think that Swing got much better performance wise. It is the machines that have become fast enough to handle Swing. Swing in the latest JDK (1.6 update 2) still sucks on my AMD XP 2000+. But it is very acceptable on any dual core.
Sun doesn't use Java on ANY of their internal projects. Does the new version mean they are going to change this? Or is what they know about Java which nobody else knows still relevant to any new versions?
Indeed, it is a real shame nobody sees this sort of deception for what it is. There is someone running around defending the fact that the JRE system libraries will be memory resident regardless of whether a Java application is actually used. This is not an optimal solution: the real solution is to reduce the enormous size of the JRE libraries to something more reasonable.
1- use strictmath
2- You must still be using JVM 1.0, nowadays JVM is faster than C++ most of the time
3- Trim down C++ libs first
4- Java is actually a very standardized language
5- use command-line switches for previous version compatibility
There, fixed that for you.
SWT is mediocore at best.
The phrase "more better" is acceptable English. suck it grammar Nazis
Indeed, it is a real shame nobody sees this sort of deception for what it is. There is someone running around defending the fact that the JRE system libraries will be memory resident regardless of whether a Java application is actually used.
They had a session about the Consumer JRE at JavaOne, and they are NOT putting it in memory. They are doing a touch of the files at startup (or possibly after login) to put the files in the disk cache. Still a cheat, if everybody did it the situation would be hopeless, but still.
the real solution is to reduce the enormous size of the JRE libraries to something more reasonable.
Which indeed is what they are doing.
Being bitter is drinking poison and hoping someone else will die
Actually it really depends on the OS, I noticed that Swing used to be substantially slower under Linux than Windows. In windows you can run a native app and swing side by side and menus etc... all of this is way faster than the native widgets, while utilizing the native skin, this comes from the fact that Swing basically goes directly into DirectX for rendering, now once you switch to Aero in Vista everything becomes dog slow because Aero is a major pain from the felt performance. In Linux things might be different, but to my knowledge in Linux Swing has the possibility to add opengl rendering (never tried it since my main work currently is in Windows where swing behaves nicely) Anyway on either platform I dont think the widget speed really is an issue anymore, at least from a felt perspective, your mileage may vary, but the last complaint I would get nowadays is why is the user interface slow. Mozillas is almost twice as slow and I wont even talk about GTK2 on Windows :-)
Same goes for the mac, but there the limiting factor is Aqua itself which is not the fastest and feels sort of slowish.
They had a session about the Consumer JRE at JavaOne, and they are NOT putting it in memory. They are doing a touch of the files at startup (or possibly after login) to put the files in the disk cache. Still a cheat, if everybody did it the situation would be hopeless, but still.
last I checked disk cache was still memory.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Which indeed is what they are doing [java.net].
that project seems to be aimed at reducing download times to start using say a java applet not reducing the ammount of crap that has to be pulled in to ram from disk to start the JVM and load all the classes that are vital to a gui.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I use java6 everyday cause I think it is a fantastic program. I write tons of applications as well. However, I still have to use SWT when writing applications cause swing is NOT consistant at all with the ubuntu default look and feel. It has many gaps in drop downs, window frame, most especially in any 3d accelerated desktop (where nothing not even a hello world will show up at all). The system tray is not even swingable so it shows up as ugly old motif which makes it even more hideous to do anything requiring a system tray as well.
Java6 has made a lot of good work, I haven't tried java7 but I'm sure they will have fixed most of these but java 6 in its current form is not close to perfect. Not on GTK anyway.
A little offtopic, I've always considered the heavyweight/lightweight terminology for AWT/Swing to be backwards. All the people I know initially confuse those. Swing looks more heavy with respect to both its API and user experience, yet it's called "lightweight" when compared to the "heavyweight" AWT (which runs faster and has simpler API).
I understand that this is in relation to the cross-platform unifomity (where Swing should be easier), if I remember correctly, but gosh, this is so counter-intuitive naming.
On the contrary, MS with .NET understands that the developers are humans too and tries not to confuse them since the sheer enormity of today's families of technologies makes them complex and hard to grasp, no need to make it harder with strange naming conventions (yes, I know that they have mess too, but it seems that with .NET they try to redo Java in a more developer-friendly way).
I'm still preferring Java, though, since it feels more open and multi-cultural (you can feel the legacy of Netscape, Sun, IBM cooperation from old times in there...).
There's Qt Jambi for you: here. Seriously, Qt is plainly the best toolkit around, and with Jambi, it has come to Java, too. Much more useful than Swing, IMO.
At this point, I'm not really sure what can be done. People want more conveniences from software, and due to software engineering's penchant for abstracting everything, we wind up with interfaces to subsystems that call dynamically-loaded libraries that invoke kernel routines that shuffle buffers to drivers that don't even control the hardware, but instead instruct another abstraction layer. It's no wonder software is slow, the wonder is that it works at all. the real solution is to reduce the enormous size of the JRE libraries If you split up the JRE libraries, all it means is that instead of having to load one huge library, now you get to load a bunch of interdependent libraries. While there probably is some refactoring that could be done, I doubt you'll really see that much of an improvement (is it really quicker to load five 100K libraries than one 500K one?).
Just junk food for thought...
No way. Impossible. int main() { return(0); } is much faster than public static void main( String []args ) { }, simply because copying the JVM into RAM takes some amount of time. More than copying a small binary. Oh, and don't forget the time it takes to run the JIT. What the JVM might be faster at than C++ is large arrays in memory. The JVM can allocate a large amount of RAM from the kernel once, and then dish that out to the calls that want memory, which might be a bit faster can making many syscalls for small amounts of RAM. Of course, some programmers grew wise to this and implement their own memory managers... In which case, most LARGE C++ projects will be faster than large Java projects...
Why UNIX?
Please talk to another side... your mouth still smells funny
Ubuntu is an African word meaning 'I can't configure Debian'
The changes the Netbeans guys did to the metal LAF are nice. When I first installed Java6 and the new netbeans I was impressed. Until I ran some other Swing apps.
One of the big problems for me is that default font is bold. The other aesthetic issues I can deal with. The bold font is just stupid.