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.'"

Comments

Java 7?

[Anonymous Coward]

I'm still waiting on a non-broken implementation of Java 6 for my iBook.

Re:Java 7?

[mhall119]

Install Linux on your iBook and you're all set.

Re:Java 7?

[Anonymous Coward]

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.

Re:Java 7?

[samkass]

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.

Re:Java 7?

[TheRaven64]

The only saving grace is that with the Intel switchover, the Apple JDK will be a lot closer to the Sun JDK. Not that much more similar. The JIT will be the same, but the JIT has been fairly stable for a while. The big differences are things like 2D drawing (Quartz Vs X11/GDI), sound (OSS Vs CoreAudio), and input.

Waste of time?

[thunderlizard]

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...

Re:Waste of time?

[aled]

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...

OpenJDK IS the SunJDK, is just that Sun open sourced the SunJDK under GPL with the name OpenJDK, minus some proprietary components that are being replaced by the community.

Re:Waste of time?

[trampel]

According to the article, not all of the JDK is Free Software - it mentions e.g. audio codecs and font rasterizers, for which Sun does not won the copyrights.

OpenJDK plans to provide GPL'd equivalents for these APIs.

Re:Waste of time?

[mhall119]

The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to what you can do with it.

Re:Waste of time?

[thunderlizard]

Yes, I'm aware of the fact that only a few pieces are being replaced -- but it is still a waste of time. I think it's more a case of a "it isn't open source, so it can't be any good" kind of mentality, instead of trying to fix an actual problem...

Re:Waste of time?

[mhall119]

I think it's more a case of a "it isn't open source, so it can't be any good" kind of mentality, instead of trying to fix an actual problem. You couldn't fix the actual problems under Sun's old license, that was the problem. Sure you could submit patches, but you couldn't distribute your fixed version, so if your patch doesn't get accepted, nobody benefits. You were also limited as to how you could distribute the unmodified JDK or JRE, which is why most Linux distros shipped with GCJ and Kaffe/Classpath instead of Sun's JDK. This further meant that most Linux distros wouldn't ship Java applications, even open source ones, in the default install. Finally, most take a look at Mac OS X support, or 64bit support, they're both lacking in Java, and there isn't much people could do about it under the old license.

Re:Waste of time?

[Anonymous Coward]

rihanna

Re:Waste of time?

[wawannem]

The OpenJDK is Sun's JDK, only under the GPLv2 license. Sun's JDK may make the source available, but you are limited as to how you can re-distribute it or derivatives of it.


There, I fixed it for you. -W

Re:Waste of time?

[mhall119]

Thanks, that's pretty much what I meant.

Re:Waste of time?

[Selivanow]

I for one want to see OpenJDK succeed. You see, I run Linux on a SPARC box. Guess What....I don't have any recent version of Java. There was Blackdown, but even that hasn't been updated in a while...license issues I believe.

Swing Sucks

[Anonymous Coward]

Can Swing please be replaced with something that doesn't suck in terms of performance? Can it also look halfway decent? That theme is hideous and the "Native" Look&Feel looks even worse.

Re:Swing Sucks

[mhall119]

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.

Re:Swing Sucks

[samkass]

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.

Re:Swing Sucks

[LarsWestergren]

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. ;)

Re:Swing Sucks

[LWATCDR]

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.

Re:Swing Sucks

[loubs001]

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/

Re:Swing Sucks

[MemoryDragon]

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.

Re:Swing Sucks

[LarsWestergren]

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.

Re:Swing Sucks

[Anonymous Coward]

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. Yeah, Swing has improved, but it's still awful. Last used date, umm, right now. I have use several Swing apps every single day and can't stand using them (Netbeans, JAP, others are internal only). Version? 1.6.0 (Ubuntu Feisty package). The two non-Swing programs I use are so much nicer (Eclipse, pdftk (command line)). I actually enjoy using those two, though several things in Eclipse aren't native and get very irritating.

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.

Re:Swing Sucks

[mhall119]

The one problem for java applications is still startup time. The slowest part of startup time is actually just pulling the JRE from the disk. From there, mapping it into memory and starting bytecode execution is actually quite fast. Java 7 (or maybe an update to Java 6) will put the JRE into disk cache on system startup, so even a cold startup of a Java application will be significantly improved, without sacrificing system memory when you aren't using it.

Re:Swing Sucks

[Anonymous Coward]

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?

Re:Swing Sucks

[eric2hill]

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.

Re:Swing Sucks

[petermgreen]

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.

Re:Swing Sucks

[Anonymous Coward]

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.

Re:Swing Sucks

[julesh]

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?

Re:Swing Sucks

[ttfkam]

"Try using GTK+. Everything looks very bad and wrong..."

There, fixed that for you. :)

Re:Swing Sucks

[jma05]

> 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.

Re:Swing Sucks

[mattgreen]

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.

Re:Swing Sucks

[Anonymous Coward]

"Try using GTK+. Everything looks very bad and wrong..."

There, fixed that for you. :) Try using Clearlooks or Ubuntu looks (with a blue theme). It looks awesome.

Re:Swing Sucks

[Tweekster]

SWT is mediocore at best.

Re:Swing Sucks

[LarsWestergren]

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.

Re:Swing Sucks

[MemoryDragon]

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.

Re:Swing Sucks

[petermgreen]

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.

Re:Swing Sucks

[petermgreen]

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.

Re:Swing Sucks

[Serpent Mage]

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.

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.

Re:Swing Sucks

[the_olo]

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.

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...).

Re:Swing Sucks

[rumith]

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.

Re:Swing Sucks

[Doctor Memory]

the JRE system libraries will be memory resident regardless of whether a Java application is actually used. This is not an optimal solution Dunno, seems to work for Microsoft. I know when I fire up XP, I can't do anything useful until 2-3 minutes after I log in (and this is after I spend 2-3 minutes waiting until I can log in), because "svchost" is busy loading the .NET runtime.

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?).

Re:Swing Sucks

[Anonymous Coward]

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.

v1.6 at 64bit on FreeBSDv7.0

[billsf]

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.

Bad requirements

[bchernicoff]

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?

Re:Bad requirements

[mhall119]

Half the developer community is pushing all kinds of new language features, and the rest of the developer community is pushing to keep those same new language features out. There is no consensus about any of them at the moment.

Re:Bad requirements

[icepick72]

By "forward" they might be trying to mimic competing feature sets like those found in the Standard ECMA-334 C# Language Specification

Still limited AMD64 support

[Enry]

No javaws, no Mozilla plugin.

Re:Still limited AMD64 support

[bcrowell]

Still limited AMD64 support [...] No javaws, no Mozilla plugin.
Huh? I'm posting this on my AMD Athlon 64 X2 4200+, running Firefox under Ubuntu. In another tab, I have a java applet running.

Re:Still limited AMD64 support

[j79zlr]

So you are using a 32-bit browser. The only 64-bit java plugin available for 64-bit browsers is the insecure Blackdown java plugin which is still at version 1.4.2-something. It hasn't been updated in years.

Re:Still limited AMD64 support

[dolcraith]

Ummmm..... You're running windows xp 32 bit right? Yeah.... that would be x86 support, not amd64 (x86_64, commonly referred to as amd64 as it was the first consumer level 64bit processor to reach market). Now there are alternatives to sun's java plugin, but they all suck because there wasn't really any openness to help those projects. Hopefully someone will realize that if they produce a working 64bit java plugin, then pretty much everyone running 64 bit will be using their product... But whatever.

Re:Still limited AMD64 support

[bcrowell]

You're running windows xp 32 bit right?
No. Read my post. I stated what OS I was using.

Re:Still limited AMD64 support

[bcrowell]

I see. I'm just running whatever version of firefox ubuntu installed by default, and I guess that must have been a 32-bit browser. Is there any particular advantage to running a browser that's been compiled natively as a 64-bit application? I would imagine it would actually perform worse, since the code it had to load would be bigger. Or do you need to have >4 Gb of data loaded in your browser, for streaming video or something?

Re:Still limited AMD64 support

[ak3ldama]

Is there any particular advantage to running a browser that's been compiled natively as a 64-bit application?

Yea, if you count not having plugins an advantage.

Re:Still limited AMD64 support

[dolcraith]

key thing is its 32 bit... sorry i skipped over ubuntu. The whole point is some people see the need for 64bit os (more memory, higher precision, etc, etc) and its seems the economy is tending towards 64bit hardware, its just that its taking *FOREVER* for the software industry to capitalize on 64bit, and on another note multicore systems.

Re:Still limited AMD64 support

[j79zlr]

Yea, if you count not having plugins an advantage.

The only 32-bit plugin that doesn't work via nspluginwrapper allowing you to run 32-bit plugins on a 64-bit browser is Java.

Re:Still limited AMD64 support

[cortana]

You save on disk space and memory use by not having to have a copy of all your libs compiled for i386 lying around.

It's a real shame that the Java browser plugin is not a part of the OpenJDK release. :(

Re:v1.6 at 64bit on FreeBSDv7.0

[Anonymous Coward]

My wife and I have a great sex-life, but I have always been interested
in more than just sex. I love the view of a cream pie. Every time I
cum in my wife's pussy, I make her spread her legs so I can watch it
dribble out of her snatch. I also eat her out if she has not yet had
an orgasm. I love to lap every last drop of my love juice out of my
wife's hotbox. I usually fantasize about my wife fucking another guy.
The
thought of her riding another guy's cock drives me insane. I always
tell her about my fantasies, but she said she will never fuck another
man.

I travel a lot for work, and my wife often accompanies me. Although
she says she will never fuck another guy, she does try to somewhat
satisfy
my desires. When we go to clubs out of town, she never wears panties.
She'll lift her dress or skirt for unsuspecting men to see her snatch.
My wife never shaves her pussy, so it is a wonderful view. She shaves
her legs and pits, so she is not a granola or hippie or anything, but
I just love the sight of her hairy pussy. Her hair is very long and
thick, but not curly. It reaches all the way from her belly button to
around her asshole, and about two inches down her legs.

Sometimes we will even enter a club separately, and she'll seduce men
that she thinks are sexy. She'll talk to them and show them her pussy.
Sometimes, if she has had enough to drink, she'll even let them finger
bang her. However, at the end of the evening, she'll never go home
with the guy. All of this is an incredible turn on, but I really want
her
to fuck another guy. My wife is exceptional at fucking, and I would
love
to see her please another man. She says that she feels like that would
be cheating, and she will never fuck another guy.

The more I mention this fantasy, the more frustrated she became. A
couple of months ago, she stopped showing her pussy at the bars,
wouldn't talk to other guys, and got pissed every time I mentioned it.
Last week, I finished up work before five o'clock, so decided to go
home early. When I arrived at home, my wife was in her nightie, and
was acting very strange. She said that she had just masturbated and
took a
shower. I noticed that her hair was not wet, but did not think much of
it. I went to the bedroom to undress and take a shower, and get ready
for a relaxing evening at home. Just as I got naked, my wife came in
and told me to sit on the chair next to the bed. I thought that I was
in for a tremendous blowjob. My wife gets really hot and horny after
finger fucking herself. As I sat down, she cuffed my wrists to the
back of the chair, and tied my ankles to the legs of the chair. At
first, I
did not think anything of it, until she stood up from tying my legs,
and I saw a drip of something white come out of her snatch. Before I
could think of anything to say, she had me gagged.

She laid down on the bed and started to finger her hairy cunt. As she
spread her legs, I about blew my load as I saw a huge load of cum
begin to drip out of her pussy. Before I could figure out what was
going on,
a guy walked into the room, naked. He was not anybody I knew, but my
wife obviously recognized him. Neither of them spoke a word, my wife
just pulled him close to the bed, and started to kiss the tip of his
huge cock.

I was in total awe, and flooded with emotions. I did not know what to
think, but I had an erection harder than I had ever had before. She
slowly started to suck his cock, and eventually started to deep throat
all nine inches of the beast. She continued to fingerfuck her hairy
snatch harder and harder while this guy's last load of cum coated her
fingers and dripped all over the bed. She got herself off in no time,
while the guy started to moan louder. I was certain he was about to
cum. Just as he arched his back, my wife yanked his cock out of her
mouth, and beat his cock juice all over her tits.
My wife finally made eye

Language-level support for XML?

[mattgreen]

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.

Re:Language-level support for XML?

[Anonymous Coward]

You got your data in my code! You got my code in your data!

Re:Language-level support for XML?

[WWWWolf]

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.

First of all, Java already has pretty good "language-level" support for XML for short while now - it's called JAXB. Basically, you can say things like "this class, Foo, represents XML tag <foo>" in your code, and use the JAXB Marshaller and Unmarshaller to save and load XML.

And when the CSV files come back, all you need to do is implement String toCsvRow() or String toCsv() in your class and implement a marshaller/unmarshaller that walks your data structure and crunches it into CSV, or back. It's not like CSV would be some sort of rocket science or anything =)

As for mysterious .dat files, Java has had ObjectOutputStream / ObjectInputStream / Serializable for ages for that exact purpose. Producing mysterious binary crap for over a decade now! =)

Re:Language-level support for XML?

[Anonymous Coward]

No; as cool as JAXB is for data binding, it is NOT _LANGUAGE_-level support. Language does have support for annotations, and annotations are used for enabling data binding, but there are no specific constructs to support it. Some might consider it a good thing, as compared to stuffing language itself with usage/domain specific extensions.

Re:Language-level support for XML?

[Anonymous Coward]

is that some kind of sick joke?
I'm a terrible programmer, and know only java.
I parse CSV, and have never written a SQL query, or used a relational database in my life.

And even I know that CSV in the language would be ridiculous. maybe MAYBEMAYBE xml. definitelyDEFINITELYDEFINITELY databasing? maybe ODBC? maybe SQL? I always mix up what the hell those two are, but this much is sure:

databases are for real programmers.
XML is for the next best thing to real programmers (or real programmers with a really good reason).
everything else is for amateurs; that's why i use everything else.

anyone caring to prove me wrong is welcome to submit a claim.
-b

Re:Language-level support for XML?

[kramulous]

As such, I move to recommend that Java incorporate support for parsing CSV and DAT files into the language.

I second that that motion. Hopefully motion will be parsed.

Re:Language-level support for XML?

[Anonymous Coward]

People who ever face the choice between using XML and using a database would be called "buzzword" programmers: it'd seem that they have understood at most one of the concepts.

XML is a way to structure data—a "file format", though it can be used for more than files saved on disk. XML is very flexible and in theory human-readable, though the latter point depends immensely on how you use it. Some people find it to be rather bloated; e.g., configuration files(for "modern" programs) written in XML are harder to read and write, both for people and machines, than ones written in a more conventional manner, because the XML is overly verbose.

Databases are servers that store data. SQL(Structured Query Language) is a standardized language to communicate with databases. Databases are a must in large-scale data processing because they can read, write or modify large amounts of data in a safe and efficient manner. ("Flat-file" storage would generally entail rewriting the entire file to disk regularly, and probably not searching as efficiently as a real database could.)

"Everything else" is not for amateurs. There's quite a lot to programming which has nothing to do with either databases or XML.

Re:v1.6 at 64bit on FreeBSDv7.0

[Anonymous Coward]

That was great, where can I find more?

Refactoring

[ishmalius]

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.

Re:Refactoring

[bchernicoff]

That would break compatibility with all the existing code.

Re:Refactoring

[ishmalius]

Of course. That's why I said "keep maintaining 1.x." ^^ Yes, I know that there is a huge installed base of 1.x. Keep 1.x runtimes in maintenance mode in perpetuity to support them, but allow people to benefit from years of lessons learned about what is needed in the runtime.

Re:Refactoring

[teknopurge]

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. Ok Linus...

Re:Refactoring

[Anonymous Coward]

... needed ... need ... need ... need ... need ... need ... needs ... needs ... needs ...

You keep using this word. I do not think it means what you think it means.

Re:Refactoring

[ishmalius]

You're right! After years of writing documents, I try to avoid stuff like that, along with "should" and "must," as if it's implying something official. I nee^H^H^H will try to be more careful.

Re:Refactoring

[ZeroConcept]

I would argue that a cleaner API is one of the advantages of .NET over Java, cleaning up the Java libraries would certainly bridge this gap.

Re:Refactoring

[mhall119]

AWT and Swing need to be reconciled Reconciled in what way? Mixing AWT and Swing widgets has been fixed in current Java 7 builds. Other than that, I don't know what kind of reconciliation is possible.

There needs to be a declarative GUI design grammar. Maybe JavaFX's grammar could be borrowed for that. JavaFX's grammar was taked from F3, which is a declarative GUI language for Java.

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) Beanbindings (JSR 295) is already in the works, and will allow you to "bind" a java.util.List as the data model for a JList widget. Meaning that you can read JList info from the java.util.List, or write to a java.util.List and have the changes appear in the JList on the next repaint.

Re:Refactoring

[ishmalius]

Mixing AWT and Swing widgets has been fixed in current Java 7 builds. That sounds wonderful. I didn't know that this had happened. Good news! So there is no longer a split between the NNNN and JNNNN widget classes?

Meaning that you can read JList info from the java.util.List, or write to a java.util.List and have the changes appear in the JList on the next repaint. This is another much-anticipated feature that will be greatly appreciated. Good to see that the new development efforts are paying off.

Re:Refactoring

[dintech]

This sounds a lot like Java's evil twin, C#. :)

Re:Refactoring

[dintech]

I would agree that there is lots of legacy detritus left in the class libraries. However, I'm not sure it really causes that much of a problem. If you don't use those classes for anything, they're pretty much invisible to you.

Re:Refactoring

[mhall119]

That sounds wonderful. I didn't know that this had happened. Good news! So there is no longer a split between the NNNN and JNNNN widget classes? Oh they are still separate, as they are still very different things. Swing != AWT. But you can now put Swing widgets on top of all or part of an AWT widget, which you couldn't do before.

Re:Refactoring

[Tupper]

Haven't you heard? Java 2.0 is out. It broke source but not binary compatability. It's called Scala.

Re:Refactoring

[julesh]

The thing needed most by Java, IMHO, is not more features, but a thorough cleanup of the runtime classlib.

Agreed. There are huge problems with the Java classlib as it stands, and these problems account for most of the issues that Java has. The biggest one is the huge list of dependencies typical classes, including some of the most basic classes in the library, have.

For instance, all classes depend on java.lang.Class. java.lang.Class depends on (among others) java.io.InputStream, java.net.URL, sun.reflect.ConstantPool (!) and java.util.Map (and presumably an implementation of that interface). java.net.URL in turn depends on java.net.InetAddress, java.net.URLStreamHandler, java.net.URLStreamHandlerFactory, java.util.Hashtable (note: not a Map implementation, so all Java programs have to load at least two implementations of this basic function). Basic I/O features (System.in, System.out) are mixed in the same class as configuration file management (System.setProperties, which depends on java.util.Properties).

The biggest problem that Java has, and it's a problem it has always had, is that Java programs take too long to start. This is directly because of this dependency problem. I say: strip it down to layers. Define a core set of classes, no more than 20 or so of them, that must always be there. Add new functions on top of those in small increments. Basic classes must not depend on more advanced ones.

Yes, this will break backwards compatibility. The old library can be retained for applications that need it, but it's time for a clean break for new ones.

Re:Refactoring

[julesh]

Haven't you heard? Java 2.0 is out. It broke source but not binary compatability. It's called Scala.

It doesn't appeal to most of the people who want a better Java. It's a language that takes a totally different direction, which is a good thing, but it's not even approximately the same thing as Java with a cleaned-up class library.

Re:Refactoring

[squoozer]

Couldn't agree more. I've been developing in Java from the early days and it's certainly starting to become time to make a clean break. As long as sun announce that they will continue to support the 1.x language for say 10 years but stop adding new features 2 years from now I think the majority of people will switch. At the end of the day look at the move from the old days of dos to the newer windows stuff. DOS applications were often impossible to run in 2000 which was only about 10 years after dos applications started to disappear. Microsofts support for legacy applications was almost fanatical IMHO.

Re:Refactoring

[AKAImBatman]

To be perfectly honest, that looks like ECMAScript (commonly known as Javascript), except worse. The key to Java's success is that it got out of the syntactic sugar rat race and pushed all the functionality into the API. Need new features? Write them as APIs. While I'm sorry to say that Sun has started to give in to pressure in that area, the language is still nowhere near as poor as I see on that Scala page.

I hate to say it, but Scala would be a very poor language for large projects. The syntax makes the code difficult to read, with idiosyncrasies galore. It fails the KISS test and will not be taken seriously.

Re:Refactoring

[Tupper]

[Scala] doesn't appeal to most of the people who want a better Java. It's a language that takes a totally different direction, which is a good thing, but it's not even approximately the same thing as Java with a cleaned-up class library. Scala can be written much like Java. It does have cleaned up versions of some basic Java libraries such as collections. Also it makes using existing java libraries less ugly; for example jdbc like:

val insertPerson = conn prepareStatement "insert into person(type, name) values(?, ?)";
for (val name <- names) insertPerson<<rnd.nextInt(10)<<name<<!;

I can't speak for most people, but it's the better Java I was looking for.

Re:Refactoring

[VGR]

The biggest problem that Java has, and it's a problem it has always had, is that Java programs take too long to start. This is directly because of this dependency problem. I say: strip it down to layers. Define a core set of classes, no more than 20 or so of them, that must always be there. Add new functions on top of those in small increments. Basic classes must not depend on more advanced ones.

That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one second. Without any OS caching.

What on earth are your programs doing that makes them so slow to start? Are you still using Java 1.4 or something?

Re:Refactoring

[Tupper]

[Scala] looks like ECMAScript (commonly known as Javascript), except worse. If you mean Scala is concise like ECMAScript, well, yes. But where ECMAScript is very dynamically typed, Scala has a strong static typing system. Type inference makes Scala strong type system less of a burden on the programmer than the (weaker) type system of Java.

The key to Java's success is that it got out of the syntactic sugar rat race and pushed all the functionality into the API. Need new features? Write them as APIs. Java has some deficencies here: it is extremely difficult to extend somebody else's library in Java. So, as you say, everybody writes another. Wouldn't it be nicer if the existing libraries were extensible?

Scala would be a very poor language for large projects Stong typing + concise + existing libraries + extensibility = excellent language for large projects.

It fails the KISS test Programing isn't hamburgers; higher metalevels can be a good thing.

Re:Refactoring

[nuzak]

All this stuff has already been done. All you're suggesting is moving shit around. I'd much rather see some radical language changes come with the next language, and it should certainly run on the JVM, but there's simply no reason it has to be Java.

I would argue that Scala is already the worthy successor language. Others would point at Fortress. Either way, all I care about as far as Java goes is that it evolve to help make those languages better and interoperate more.

Re:Refactoring

[Abcd1234]

ROFL! You can't be serious! Consider:

Array.Length
List.Count

I'm sure there are a million other examples (date handling, for example, is totally fucked up in .NET).

I've said for some time now, C# is actually a pretty decent language hobbled by a horrible class library.

Re:Refactoring

[mino]

java.util.Hashtable (note: not a Map implementation, so all Java programs have to load at least two implementations of this basic function)

public class Hashtable<K,V> extends Dictionary<K,V> implements Map<K,V>, Cloneable, java.io.Serializable

Yes it is.

Not disagreeing with the sentiment, but Hashtable is a Map (and has been since 1.2, according to the Javadoc).

Re:Refactoring

[obi]

Maybe look at Vala then, though it's probably still at "toy-language" stage.

Re:Refactoring

[LarsWestergren]

JavaFX's grammar was taked from F3, which is a declarative GUI language for Java.

I thought that too, but it turns out JavaFX IS actually F3, just rebranded with an official name. I thought Form Follows Function was a pretty nice name, but then I don't work in marketing, do I...

Minor nitpick. :)

Re:Refactoring

[julesh]

That's strange. All my Java programs, nearly all of them large Swing programs, start up in less than one second. Without any OS caching.

One second is way too long for process startup, IMO. A process should be able to be running within a tenth of a second, to be useful in many circumstances.

Timings of a C-based hello-world program:

Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
$ time ./test
Hello, world

real 0m0.047s

Python-based equivalent:

Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
$ time python test.py
Hello, world

real 0m0.109s

Java-based equivalent:

Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
$ time java Test
Hello, world

real 0m0.266s ...

Jules@minerva ~/My Documents/projects/eclipse/jzx/bin
$ java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

Why is Java the slowest of all three of these? A quarter second startup time for a trivial CLI program on a modern computer with a multi-gigahertz processor, a surplus of RAM and Java already in the cache (because two existing Java programs were already running on the machine) is unacceptable. The job Java has to do is substantially simpler than Python's job, which included compiling the source to bytecode prior to running it. It makes Java implausible for writing high-performance CLI programs, which you often need to run hundreds of times to perform certain jobs.

Re:Refactoring

[Jynx77]

Really? As a matter of fact, that's about it. Why don't you come up with 10 more -- a small start on your million. As far as date handling goes, when I used Java 4-5 years ago, the date handling was truly pathetic requiring instantiaion of multiple classes to achieve very simple things (like adding one day to a date). DateTime in .NET is pretty much perfect IMO. Does almost everything I need it to right out of the box. With BS, half-assed, uninformed, biased posts like this, I sometimes wonder why I even bother to read /.

Re:Refactoring

[shutdown -p now]

In .NET, arrays and strings have lengths. Collections have element count. When array poses as a collection (i.e. when you cast it to ICollection - and you can), it also has property Count.

Meanwhile, in Java, we have public final field length for arrays (nevermind that every style guide explicitly forbids having public non-static fields in a class), length() for class String and size() for collections. Neither of which conform to naming conventions for JavaBean properties, so whenever a bean need to expose a similar property, it has to be getLength() or getSize().

The reason, of course, is that Java is several years older than .NET, and so has accumulated more legacy APIs and cruft. I'm sure .NET will be the same in a few years (it already has two different collection APIs by v2.0, and UI toolkits by v3.0).

Re:Refactoring

[mhall119]

I thought that too, but it turns out JavaFX IS actually F3 It's quite a bit more than _just_ F3 though.

Re:Refactoring

[ZeroConcept]

You provide one example of API inconsistency and no further evidence to support your judgment. Have you shipped applications built in both platforms? I get the impression you haven't worked too much with .NET to know where the weaknesses of it are (and I know there are many), Array.Lenth and List.Count are not near the top 10 pains. Besides there are comparable inconsistencies in the Java libraries.

Re:Refactoring

[Abcd1234]

You provide one example of API inconsistency and no further evidence to support your judgment. Have you shipped applications built in both platforms?

Yes, I have. Fairly large ones, too (not huge... the 100K+ range).

Array.Lenth and List.Count are not near the top 10 pains

Yes, because I selected that because it's at the top of the list, and not simply because it's a) patently stupid, and b) easy to illustrate.

Besides, are you trying to defend .NET or not? Your suggestion that you can easily think of 10 other design decisions more idiotic than the one I supplied suggests the answer is "no", which leaves me rather confused...

Besides there are comparable inconsistencies in the Java libraries.

Yeah. Umm... so? Again, I never said Java was better. I'm simply saying the idea that .NET is/will be successful because the class library is somehow superior is, frankly, rather stupid.

Re:Refactoring

[Abcd1234]

Why don't you come up with 10 more

Alright then:

1. Transactions (of all things) in ADO.NET are an absolute nightmare. I have to *manually* save and restore a DataSet if I do a rollback? Hell, that's ignoring the fact that I have to manually set up a command list for a transaction object in the first place (who came up with that, honestly?).

2. DBNull? WTF is DBNull? Just give me friggin' null, FFS.

3. DateTime isn't represented as UTC, internally, which makes dealing with, among other things, multiple time zones, an absolute pain in the ass.

4. The winforms checkbox control operates inconsistently from the rest of the system (it doesn't even trigger a focus event when it's clicked, IIRC).

5. The winforms validation framework is, frankly, idiotic. Why can't I move focus out of a textbox just because the value doesn't validate??

6. The installer framework, at least in VS2005, is *terrible*. It's really unbelievable anyone would release such a monstrosity (hard coded dialogs with 4 text fields? Passing data from the installer to custom install actions as *command-line arguments*??)

Pity, looks like that's all I've got off the top of my head. I'm sure others can contribute their own, though.

As far as date handling goes, when I used Java 4-5 years ago, the date handling was truly pathetic requiring instantiaion of multiple classes to achieve very simple things

The date handling in Java is complex because handling dates is a complex task. The .NET developers clearly didn't understand that, hence the half-assed implementation. It appears you don't, either.

Re:Refactoring

[Jynx77]

If I want to add one day to a date, why should it be more complex than d = d.AddDays(1)? I forget exactly what it was in Java but it was a pain in the ass -- there was no justification for the complexity of it. Why should I care what the internal representation of the DateTime object is? I've used the both the Java date routines and the .NET ones to develop complex power (as in electricity) scheduling applications that involved 5 minute intervals, multiple timezones, and daylight savings transition support. I actually had to do almost the exact same thing on both platforms and the .NET date support was head and shoulders better than the Java in every way. Simple things should be simple. There's no reason I should have instantiate another class to add one day to a date.

Re:Refactoring

[Abcd1234]

Why don't I just let this article do the talking for me, since you seem to persist in believing that DateTime in .NET is just perfect (here's a hint, they're planning to *write a replacement* because of the limitations in the current implementation, and why? Because the *underlying representation was insufficient*).

Re:Refactoring

[ZeroConcept]

To clarify, I like both platforms (J2EE, .NET) for different things, as far as the API is concerned my logic goes like this:
- .NET has less historic baggage
- .NET was designed from learned lessons from Java and other languages
From my experience, the .NET API feels cleaner than Java.

I understand your point is that the .NET API is inferior to J2EE, is this the case?

If so, would you explain which parts of J2EE do you consider superior and why? Pointing flaws in .NET alone doesn't provide a fair comparison.

Re:Refactoring

[Abcd1234]

I understand your point is that the .NET API is inferior to J2EE, is this the case?

Uhh, I don't recall making that point, nor would I, since I don't have a lot of experience with either stack (most of my .NET and Java experience is in building desktop and server applications). I have made disparaging comments about ADO.NET, but that's simply a database access layer, not a complete, soup-to-nuts application stack. And in the Java world, there really isn't an equivalent, as most people work with ORMs built on top of JDBC, rather than something like ADO.NET (which is really just a thin object model over the underlying database tables... and a crappy one, at that).

Re:Refactoring

[Anonymous Coward]

Well, here's the equivalent Java for adding 1 day to a date:

Calendar date = Calendar.getInstance();
date.add(Calendar.DAY_OF_MONTH, 1);

There...was that so hard? Complaining about Java's Date object was relevant when Java 1.0 didn't have something reasonable to use instead. Calendar can do everything you need it to do relatively simply once you get used to the way it works. The Date class is really only useful for its toString() method.

Of course there are many valid criticisms of Java's Calendar (nigh unusable toString(), the fact that transposing the arguments in my example still compiles and some truly obscure bugs that we've run into). But the simplicity of adding 1 day to a date isn't one of them.

Re:Refactoring

[the_olo]

While pruning deprecateds (sorry for funny grammar...) is a good idea and has to be executed some day, I'd disagree that this needs to be done with the first release that will be fully open source.

For those, who look forward to OpenJDK release, it would be a great disappointment that could set back the whole Java camp a couple of years because of mindshare/psychological reasons.
If the first release that's finally included with all the Linux distributions would make lots of older software stop working, lots of people simply would walk away from Java in frustration.

That's because right now almost all GNU/Linux/*BSD users are holding their breath in wait for the Open JDK. Those people expect that all the software for which they've installed binary JDK's to date (sometimes resorting to Linux emulation tricks etc) will finally be supported by their system of choice out of the box.
And when they finally get the new JDK, and visit e.g. their online banking site that uses some old AWT applet, and it doesn't work at all - you get the picture.
People would get crazy and move to Mono/.NET or swear they'll avoid Java and code only in Python/Ruby till the end of their life.

So IMHO full backward compatibility should be preserved at least in Java7 so the first OpenJDK release doesn't break anything.

Later you can clean up and prune anything, the worst that can happen will be that people will stick with OpenJDK 7 for a longer period until all the apps they need are updated to fresh APIs.

Re:Refactoring

[Anonymous Coward]

Look, when you want to run a CLI program in a single process which is initiated even tens or hundreds of times per second, odds are it simply isn't worth it to use Java for it anyway. You may as well complain that VMware starts up too slowly when you want to print hello-world.

You're trying to use a hammer to tighten a bolt and then complaining because it doesn't do the job well. I submit to you that any task that is of such a short lifetime that you'd run the CLI hundreds of times per second is probably simple enough that you'd be better off just using Python.

Re:Refactoring

[Jynx77]

Perhaps you should read what you reference as support for your case: "Andrew McCallum is right that Java had similar problems with their Date-Class. But worse they did it wrong the second time with the ugly Calendar class, I've never seen such an unintuitive Date-API."

Re:Refactoring

[Abcd1234]

Ugh, as I have said *repeatedly*, I'm not, nor have I ever said Java is better. I'm saying .NET *isn't*, and therefore the argument that .NET's "clean" API is the cause of it's success is pure bunk.

Re:Refactoring

[ZeroConcept]

I agree with you regarding ADO.NET, in the past we had good experiences with NHibernate as a replacement. It also has its share of issues but in my personal experience the benefits outweigh the pains, it can have a steep learning curve though.

Re:Refactoring

[Jynx77]

When it comes to the Date API, I will state emphatically that .NET's is better (at least compared to Java in 2001-3). I have personally coded with both and spoken to numerous experienced developers who have coded with both, and they uniformly prefer the .NET Date API. Note that API means application programming interface. I never said the .NET implementation was perfect or bug-free. Just that I much preferred the .NET API as much easier to do simple things like create, add to, subtract from, and display dates with. I challenge you to post equivalent date operations in Java and c# using only the built-in APIs. If you do that, you will see you have clearly lost this argument. Here's a quote from O'Reilly's OnJava:

Summary From the foregoing discussion it should be clear that Java's date-handling classes are not just complicated, but also poorly designed. Encapsulation is leaky, the APIs are baroque and not well-organized, and uncommon idioms are employed frequently for no good reason. The implementation holds additional surprises (I suggest a look at the actual type of the object returned from Calendar.getInstance( Locale ) for all available locales!) On the other hand, the classes manage to treat all of the difficulties inherent in internationalized date handling and, in any case, are here to stay. I hope that this article was a little contribution in helping to clarify their proper usage.

http://www.onjava.com/pub/a/onjava/2003/06/05/java _calendar.html?page=2/ Not sure who is modding you up, but until some of the /. folks take their anti-MS blinders off, they are going continue to accept garbage like the Java Date API as superior just because MS didn't write it. You aren't going to successfully challenging MS by ignoring the areas where they are superior and pretending otherwise.

Re:Refactoring

[Abcd1234]

like the Java Date API as superior just because MS didn't write it

Are you a fucking idiot, or just blind? I repeat, I never said Java was better. I said the .NET API is *broken*. Worse, if they'd just learn from Sun's mistakes, it wouldn't be... but, of course, NIH and all that. Christ, get MS's cock out of your fucking mouth, read, and try to *comprehend*.

Re:Refactoring

[Jynx77]

Christ, get MS's cock out of your fucking mouth, read, and try to *comprehend

Wow, I see the light now. I agree with you 100% and you are a genius.

Re:Refactoring

[Abcd1234]

The problem is, if you're building winforms-based database-backed applications, you're pretty much stuck with ADO and all of it's warts, unless you want to manually do all the heavy lifting to populate controls and propagate changes back to the DB (unless NHibernate addresses this issue? I must admit, I haven't looked.)

Re:Refactoring

[CryBaby]

Any mention of the old "date handling is pathetic" complaint about Java has to be answered by pointing out Joda-Time, which will become the standard date and time library starting with Java 7. And yes, it's better (cleaner API, more functionality, etc.) than the .NET equivalent.

I don't think Joda-Time was available 4+ years ago, so I feel your pain if you had to do a lot of date/time manipulation with Calendar and all that crap. Luckily, Joda-Time became more or less a de facto standard soon after it was released so -- unless you're in an environment that prohibits 3rd party libraries -- Java has had better date handling than just about any other language/platform for a number of years now.

Re:Refactoring

[CryBaby]

I really can't believe that someone actually tried to argue that Java's built-in date handling is better than .NET's. Unbelievable. On behalf of every Java programmer who's had the misfortune of actually using Calendar and the other horrid date-related classes in the JDK, I have to apologize for Abcd1234's silliness. If Calendar and the like were anything but pathetic mistakes, there would be some debate about entirely replacing them with Joda-Time. Instead, it's one of the few "no-brainer, better late than never" changes in Java 7 that nobody (to my knowledge) seriously argues against.

Imitation, Flattery, Yadda yadda yadda

[Anonymous Coward]

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.

Re:Imitation, Flattery, Yadda yadda yadda

[teknopurge]

IBM is a bad example for almost anything. I looked at your "JLINQ" thing - guess what: IBM already has this under another name. J2C. It's been out for 6 years.

c# is still in the doldrums for adoption. Unlike other posters that may claim something without data: Java is still the most widely used language with more than 7x the marketshare of C#.

Re:Imitation, Flattery, Yadda yadda yadda

[Anonymous Coward]

Except Java was first and is actually in use everywhere. Have you seen any C# apps or usage yet ?

Re:Imitation, Flattery, Yadda yadda yadda

[sh3l1]

...usenext... ummm........ nope, that's pretty much it.

Re:Imitation, Flattery, Yadda yadda yadda

[Anonymous Coward]

Blam, tomboy, and F-Spot to name a few.

Re:Imitation, Flattery, Yadda yadda yadda

[RAMMS EIN]

Your observations are absolutely correct, and a great illustration of why competition is good. Just like Microsoft had been resting on their laurels with MSIE until Firefox started getting too popular, Sun was resting on their Java laurels until .NET came along.

Bah.

[Anonymous Coward]

The only open source java project worth noting these days is GCJ.

Anything deriving from Sun's JVM is over. Done. Good riddance.

Re:Bah.

[julesh]

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.

Sun implicitly admits this is a problem, even.

[mattgreen]

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.

Re:Sun implicitly admits this is a problem, even.

[LWATCDR]

No worse that Windows which loads a crap load of stuff that my never get used. The JVM is an entire environment.
Now that Java is becoming FOSS I keep hoping we will have the option of compiling our Java programs and linking just what we need. It will mean that they will not have the option of dynamically loading classes but many applications can live with that.

Re:Sun implicitly admits this is a problem, even.

[mhall119]

Again, loading the JRE into system memory is very fast, it's finding the JRE on disk that is time consuming, which is why disk cache will give Java startup time a boost.

Re:Sun implicitly admits this is a problem, even.

[aled]

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.

Sun not only admitted it is a problem, but is actually fixing it in a near update.

yuo Fail it

[Anonymous Coward]

nearly two years cuntwipes Jordan your spare time are the 1mportant gains market share BSD has always consider that ri6ht Live and a job to Then Jordan Hubbard

Jesus, JDK7?!

[Lysol]

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.

Re:Jesus, JDK7?!

[ADRA]

Well, since Java is more or less 100% backwards compatible they could release a new major version every two weeks and nobody should care. That said, there are some gotcha's to watch out for when upgrading to new versions of the JDK. For the company I work for, the move from 1.4's Metal to 1.5's Metal meant going through every screen to make sure the layout was still consistent. That wasn't fun, but the added features of the release more than compensated for it.

Re:Jesus, JDK7?!

[HotBBQ]

how many people out there in the 'real' working world use 1.6? Prob no one.

Are you serious? We made the move from 1.5 to 1.6 the day it was released and not a single change was necessary. The switch to 1.6 gave us a %15~ performance increase thanks to improved double precision handling.

Re:Jesus, JDK7?!

[hansamurai]

And I'm currently working on a product that'll be released in January that's running off 1.4.2. I wish we could at least take advantage of the changes in 1.5 (and if we do that we might as well move to 1.6). Some companies like mine are just sloths when it comes to moving on. If I made the decisions we'd we at 6. I've worked with it at home and had no problems. Ah well.

Re:Jesus, JDK7?!

[Wdomburg]

Shit, how many people out there in the 'real' working world use 1.6?

*raises hand* Fifteen machines servicing about 700,000 users.

Re:Jesus, JDK7?!

[slartibart]

Well, since Java is more or less 100% backwards compatible they could release a new major version every two weeks and nobody should care. That said, there are some gotcha's to watch out for when upgrading to new versions of the JDK. For the company I work for, the move from 1.4's Metal to 1.5's Metal meant going through every screen to make sure the layout was still consistent. That wasn't fun, but the added features of the release more than compensated for it.
There was also the change from 1.4 to 1.5 would break your code if you had used any variable called "enum", because enum became a keyword. It could be a lot worse and generally I'm a rah-rah java guy, but it's only *theoretically* that no one should care about upgrading JDK. In reality stuff is going to break. However, my rah-rah java statement is that those problems are easy to fix, in my experience.

Re:Jesus, JDK7?!

[PitaBred]

Actually, we found 1.6 fixed a number of issues we were having with anything later than 1.5.03. So we're using it in a production environment. But, we are small and "agile", I think is the word ;)

Re:Jesus, JDK7?!

[Anonymous Coward]

You are just getting scared by the version numbers. The major changes were introduced from 1.4 to 1.5 version. From 1.5 and up the changes are not that big and the language is still fully backward compatible. ie. your 1.4.2 programs will still run in 1.6. Actually they will even run better and with better graphics (in case you used some java base gui api like swing). Also there are some improvements, bug fixes and new features (like system tray support).
The rest is only FUD... Just remeber that those who don't adapt die.

Re:Jesus, JDK7?!

[fgfgfgfgf]

Hey, isn't JDK7 just Java 1.7, the same way JDK6 is the same as Java 1.6? I don't think they are jumping the development versions that much, Java 1.5 gave huge performance differences over 1.4 and quite a few language changes, I think the language as a whole seems to be evolving quite quickly and without losing any stability.

Java CPU/DSP?

[Doc Ruby]

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?

Re:Java CPU/DSP?

[qualidafial]

Um.. used a cellphone lately?

Re:Java CPU/DSP?

[Doc Ruby]

Do those phone's CPUs execute bytecode in HW, or do they run a JVM? Got an example of one by name?

Re:Java CPU/DSP?

[qualidafial]

Most cellphones coming out now (with the notable exception of smartphones (except for Blackberry)) are Java enabled. If you've purchased a game on your cellphone is it likely written in Java.
Motorola was among the first to adopt Java in all their new phones: http://www.wirelessdevnet.com/columns/oct2000/mobd ev13.html

Since then most other cellphone manufacturers have jumped on the bandwagon: http://news.com.com/2100-1001-268154.html, http://archive.chipcenter.com/knowledge_centers/wi reless/news/showArticle.jhtml?articleID=10800173

As for hardware execution of bytecode, what's happening now is not the original approach that Sun attempted (i.e. integrating a bytecode interpreter right into the CPU). What is happening now is that several vendors are selling "accelerator" chips that sit between the CPU and the SRAM and execute the bytecodes for the CPU. This modular design has made it easier to integrate these accelerators into existing designs. The Nazomi JA108 is one of the more successful models from what I can gather.

You still have to run a virtual machine, however with the accelerator chip actually executing the bytecodes you get vastly improved performance and reduced battery drain.

Some of these accelerators are even finding their way into other technologies as well, not just cell phones: http://www.elecdesign.com/Articles/Index.cfm?AD=1& ArticleID=1916

I could polish up this list a little but Google is your friend too :)

Re:Java CPU/DSP?

[Doc Ruby]

Most of those articles/PR were published in late 2000 and early 2001, with the Nazomi introduced in 2003. I see no news of Java HW uPs since then. Only a tiny fraction of the Java-capable phones running today were built as long ago as 2003, or even 2004. Java itself is now in v6, not v3.

So it looks like "Java chips" had a brief resurgence in 2001-3, in the phone market, just like their initial hype for other devices in 1995-6. There's no evidence that I can find that any of that tech is in HW today, except perhaps in the rarest, most exotic apps. That's a total difference from "it's in every Java cellphone" as you claimed.

Re:Java CPU/DSP?

[qualidafial]

You may have won this battle, but we'll meet again!

Re:Java CPU/DSP?

[Doc Ruby]

Call me when your phone runs on a Java chip. In fact, just have your phone call my phone, and they can argue about it on our behalf.

One oddly missing feature...

[WWWWolf]

Currently, it appears that jEdit has to open a TCP port, because otherwise it can't communicate with instances of jEdit you have running. With the port closed, if you say "jedit foo.txt", it will open the file in a new instance of jEdit, not the one you have open right now.

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.

Re:One oddly missing feature...

[atrus]

Because there is no 100% portable method for naming UNIX sockets, named pipes, and whatever else is in use out there. Java sometimes picks the lowest common denominator for its utilities in an effort to not introduce headaches. Its really a design compromise. IP is mostly universal though, so IP sockets and addressing was chosen. If jEdit binds to the loopback device only, what difference does it make?

Re:One oddly missing feature...

[RAMMS EIN]

``Appears the reason for using TCP is that Java has no (cross-platform, at least) support for POSIX local sockets or even named pipes.''

Yes. And I think it's fair to blame Microsoft for that one. Every *nix I know has Unix sockets, and they're in POSIX (where they are called local sockets), so I imagine they are in lots of non-Unix systems as well. Of course, Microsoft decided to do everything their own way...and while I'm almost certain they have something equivalent, I'm absolutely positive it doesn't work the same way.

What Java really needs .....

[ajs318]

..... is a new string concatenation operator. One that doesn't look like any of the "numeric" operators.

Perl got this right. If you want to concatenate strings (using the string concatenation operator .), it coerces the operands to string. If you want to add numbers (using the numeric addition operator +), it coerces the operands to numeric.

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

s = sin theta;

than

s = sin(theta);

anyday.

Re:What Java really needs .....

[fuzz6y]

Also, ditch the requirement to have function arguments in brackets.

If you want to program in perl, nobody's stopping you.

Re:What Java really needs .....

[glwtta]

Automatic type coercion is, in general, a good thing -- it removes clutter (in the form of unnecessary function calls).

Eh? Java is statically typed (well, for primitives, anyway), I'm not sure how you envisage automatic coercion here. And not requiring parentheses for method calls would make most Java code unreadable (and probably unparseable).

Java is just not a concise language, you must be thinking of something else.

Re:What Java really needs .....

[Anonymous Coward]

If that was such a big concern for me or other Java developers we'd become Ruby or PHP developers. I don't need silly synthetic sugar that doesn't do anything but make the language more verbose and programs harder to maintain.

Re:What Java really needs .....

[DragonWriter]

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.

Sure, its easy when you talk about changing sin(theta) to sin theta, but when you have ln(sqrt(x))+y and ln(sqrt(x+y)) and ln(sqrt(x)+y) and they all map to ln sqrt x+y, you start needing parens anyway to enforce sequence, whether explicitly to specify function arguments or to denote expression precedence.

When you've got nested function calls each of which takes more than one argument, as well, the opportunities for ambiguity expand even further.

The Ruby way of making parens optional where unambiguous for function application might be doable for a revised Java, but it doesn't really offer any clear benefit, and is a kind of TMTOWTDI approach that make make it harder for people other than the original author to read code.

Re:What Java really needs .....

[ajs318]

It's never ambiguous as far as the computer is concerned, because there will always be operator precedence. sqrt binds more tightly than + and so does ln, but the sqrt, being nearer the argument, gets evaluated first; so ln sqrt x + y is ln(sqrt(x)) + y.

I'll admit, that's one case where brackets are actually more of a help than a distraction. But if you were taking baby-steps, it wouldn't be so bad. Also, for the benefit of baby-steppers, how about a forget statement which would free up memory that had once been used by variables which are no longer required? (I know, real programmers just reuse variable names ..... it has the same effect ..... but the whole idea of modern programming languages is to let the computer do the work for you. An optimising compiler would see the baby-steps followed by a bunch of forgets and decide that since the intermediates were obviously never going to be required again, they could all be stuck into one big long operation.)

Re:What Java really needs .....

[DragonWriter]

It's never ambiguous as far as the computer is concerned, because there will always be operator precedence.

Well, sure, if one views "function call" as an implicit, invisible operator. Still, with multiple argument functions (particularly with variable length argument lists) parsing becomes tricky, at least for humans. I mean, if you ditch parens in those cases, you can end up with things like

printf format_str, val1, val2, my_func val3, val4, val5, other_func val6, val7

If my_func and other_func take variable length argument lists (as printf does), how do you parse that? Sure, you can define rules for how a parser handles it through precedence between the (invisible) "function application operator" and the (",") "argument separation operator", but there's a reason that even Ruby stops short of that madness.

Re:What Java really needs .....

[bill_kress]

I keep hearing rumors that Ruby is going to start requiring parentheses for function arguments because, I assume, it's too confusing otherwise.

Clutter is just what you are used to--it's objective. Where Java can it uses a single, consistent methodology at the cost of a few extra characters.

It's clearer for many people to read and not harder for anyone I've ever met except perhaps for people trying to prove that their language of the day is "Better" somehow than some other language.

Re:What Java really needs .....

[nuzak]

> Also, ditch the requirement to have function arguments in brackets.

Will not ever happen. Fortress on the other hand might be up your alley. I believe you can even overload the concatenation operator in Fortress. It may be aimed at fortran, but I imagine you could write whatever you like in in.

And BTW, perl got nothing whatsoever right about concatenation. It has a different operator for strings because it is incapable (without diving deep into internals) of telling the difference between strings and numbers.

Re:What Java really needs .....

[ZeroConcept]

All your comments are great if you assume code writing speed is more important than readability, for quick & dirty disposable code that would be the case. For enterprise applications that require high-availability bugs introduced due to automatic stringnumber comparisons, non-explicit function parametrization etc. Can be very hard/expensive to identify and correct.

I was on a project in which we converted a VB.NET application to C# using automated tools, we found and fixed several bugs due to the (limited) type conversion that VB.NET offers while in C# it has to be explicit, Java is very similar to this.

Re:What Java really needs .....

[strcpy(NULL,...]

Never mind the GP, man. He doesn't have a clue.

If you consider a language such as C++, it's possible to write function/method parameters that can have default values. Those are problematic too.

foo bar 3 4

foo(bar(3,4)) or foo(bar(3),4) ??

Re:What Java really needs .....

[ultranova]

I know, real programmers just reuse variable names ..... it has the same effect ..... but the whole idea of modern programming languages is to let the computer do the work for you. An optimising compiler would see the baby-steps followed by a bunch of forgets and decide that since the intermediates were obviously never going to be required again, they could all be stuck into one big long operation.

Even better, you could have the compiler figure out the last position a particular variable is used in a function, and automatically reuse the space for other variables where possible, all without human intervention or forget statements. I wonder if I should patent this revolutionary idea...

Re:What Java really needs .....

[ajs318]

True; but an interpreter (or even a compiler which supports an eval function, or some other weirdy "calculated" construct such as treating variables as a property of the containing namespace) wouldn't be able to do that, because it wouldn't have any way to know for certain that the variable really was never going to be used again. It could conceivably crop up in an eval, or be accessed by some other indirect means.

Of course, gratuitous misuse of forget (especially inside an eval) could be even more entertaining than gratuitous misuse of goto .....

Re:What Java really needs .....

[ultranova]

True; but an interpreter (or even a compiler which supports an eval function, or some other weirdy "calculated" construct such as treating variables as a property of the containing namespace) wouldn't be able to do that, because it wouldn't have any way to know for certain that the variable really was never going to be used again.

Even most interprete languages (such as Python) are in fact compiled or at the very least parsed and tokenized when loaded, giving the interpreter a chance to evaluate variable scope. If they aren't, then you don't win anything with forget statements, and in fact are likely to lose some: the string forget takes more space than a single 32-bit variable it frees.

Besides, if you use a non-compiled, non-tokenized language, why worry about efficiency - you aren't going to get it no matter what you do ;).

Re:What Java really needs .....

[goose-incarnated]

Sure, its easy when you talk about changing sin(theta) to sin theta, but when you have ln(sqrt(x))+y and ln(sqrt(x+y)) and ln(sqrt(x)+y) and they all map to ln sqrt x+y, you start needing parens anyway to enforce sequence, whether explicitly to specify function arguments or to denote expression precedence.
Sure sure, brackets on the outside of the expression will still be needed but I'd rather see "(sin x) + y" than "sin (x) + y", or "(ln (sqrt x)) + y" than "ln (sqrt (x)) + y", or "ln (sqrt x + y)" than "ln (sqrt (x + y))".

Effectively, brackets are only used for disambiguation, and not, as currently, for everything even when the lack of brackets imply no ambiguation.
Of course, taking this to the logical conclusion, you would end up with lisp-ish syntax anyway, which has a damn sight more expressive power than java-ish syntax anyway :-)

Re:What Java really needs .....

[goose-incarnated]

Never mind the GP, man. He doesn't have a clue.

*sarcasm set to "stun"*
Yeah, I'm sure he doesn't; especially as the change suggested hasn't already been used in languages far superior in expressiveness for at least the last 30-odd years ...

Oh, wait ...

If you consider a language such as C++, it's possible to write function/method parameters that can have default values. Those are problematic too. foo bar 3 4 foo(bar(3,4)) or foo(bar(3),4) ??

I'd suggest learning a little haskell, lisp and smalltalk (in that order) so that you can see firsthand that the brackets to delimit the arguments to a function are not really needed, and that the comma used to separate arguments are also not needed.

Of course, brackets will still be used, but in the more accepted math-like manner i.e. used to delimit expressions, with the outermost expression not needing a delimiter.

With the current (non-math) way used in java, c++, etc, the brackets solve a problem that they introduce. Languages that do not use the brackets in this manner do not have this problem you seem to think must exist.

Re:What Java really needs .....

[strcpy(NULL,...]

Yeah, I'm sure he doesn't; especially as the change suggested hasn't already been used in languages far superior in expressiveness for at least the last 30-odd years ...

We were discussing how impossible it is to make the said change to the Java language, but thanks for chipping in with your irrelevant func-prog fanboism. Of course LISP is much more expressive because it doesn't have a syntax. Alas, we were not really discussing LISP here.

None of your precious little languages can ever solve the ambiguity problem. Observe:

I'd suggest learning a little haskell

map (dosomething [1 2 3]) [1 2 3] This wouldn't be the same thing as map dosomething [1 2 3] [1 2 3] would it?

lisp and smalltalk (in that order)

I'd really love to see you implement a LISP dialect without using brackets to group stuff together. Really. What are you gonna do? print "Hello World" ?

Whatever you put side by side in LISP is a separate argument since it doesn't use infix notation. So, your comma argument doesn't work either. The comma operator is relevant only to infix languages.

As for smalltalk, I'll look at it when I come across a real-world program written in it, but thanks for the advice.

Re:What Java really needs .....

[goose-incarnated]

None of your precious little languages can ever solve the ambiguity problem. Observe:

May I suggest that you at least look at the languages I suggested before going off the deep end? They've all solved at least one of the ambiguity problem, the default argument problem, the nested function call problem and the named argument problem. Go on, have a look at them.

I'd really love to see you implement a LISP dialect without using brackets to group stuff together. Really. What are you gonna do?

The argument was not to eliminate brackets, but thanks for knocking that strawman down. The argument I put forward was that brackets are only needed for inner expressions (not outermost ones). Currently, function calls use brackets even when there is no ambiguity.

Whatever you put side by side in LISP is a separate argument since it doesn't use infix notation. So, your comma argument doesn't work either. The comma operator is relevant only to infix languages.

Another nice strawman; what about haskell? That is infix. Look up the term curried functions.

Re:What Java really needs .....

[strcpy(NULL,...]

The argument I put forward was that brackets are only needed for inner expressions (not outermost ones).

If your argument is so shallow (pun intended) it's not worth discussing. I still don't see the advantage of making such a change other than self-satisfaction. As we all know there are already good languages for self-satisfiers. No point in making Java one.

Syntactic sugar looks like clutter until you consider error recovery. Sure, you can do away with it but humans need sugar.

G'day.

Re:What Java really needs .....

[DragonWriter]

I'd really love to see you implement a LISP dialect without using brackets to group stuff together.

Wouldn't Lisp without parens be REBOL?

Re:What Java really needs .....

[DragonWriter]

May I suggest that you at least look at the languages I suggested before going off the deep end? They've all solved at least one of the ambiguity problem, the default argument problem, the nested function call problem and the named argument problem.

So has Java: it solves them all by using parens around the argument list and commas between its elements.

If you really want to do things the Haskell, Lisp, or Smalltalk way on the JVM, there is no reason to change Java—there are implementations of all three languages for the JVM. What does eliminating parens for function calls (and/or commas between elements in the argument list) get Java except aesthetic appeal to a certain subset of the programming community that is offset by the aesthetic appeal it loses for a different subset of the programming community?

Re:What Java really needs .....

[trouser]

.... is a fat cock shoved up its hairy white ass.

Apple and Javax

[babazaroni]

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?

Great that Red Hat is funding a Free version

[Anonymous Coward]

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.

The profit margin on certification exams must be

[Southphillyman]

high like someone above said, much of the real world is perfectly fine with 1.4

Re:Jesus, JDK7?! (what's your real complaint?)

[HardWoodWorker]

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.

Java Fixes

[Anonymous Coward]

Dear Java Developers, can you consider fixing the following:

1. Poor non-standard IEEE floating point support. Thx! (Your C/C++ Friends)
2. Piss-Poor Performance of your virtual machine (Your Turing Friends)
3. Can you trim down the distribution to under 100+Mb? I shouldn't need 230Mb of cruft for 'hello world'
4. Can you at least consider standardization? Even Some Open-Source language standardization?
5. Fix backwards compat issues? I shouldn't need Java 1.5, 1.6, 1.7 for 3 differnent 'hello world' applications.

Thanks, you friends who still code in real lanugages.

Re:Java Fixes

[Anonymous Coward]

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

Re:Java Fixes

[eneville]

2- You must still be using JVM 1.0, nowadays JVM is faster than C++ most of the time
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...

Consistent, sane branding and versioning needed

[Fastball]

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.

Re:Consistent, sane branding and versioning needed

[Anonymous Coward]

Now we have OpenJDK, Blackdown, Sun, and so on...

It's worth noting that Blackdown is a) retired and b) grew out of Sun's refusal to support Linux. You might also remember that Sun's first Linux version was basically a hastily re-branded copy of the Blackdown project.

So I really wouldn't include Blackdown in your list of things that are confusing the subject. They were a well-run OS project that served a need that Sun wouldn't. Now that Sun does serve that need, they've shut down.

Re:Consistent, sane branding and versioning needed

[Anonymous Coward]

This opinion only shows, that you probably make programs, but don't sell them.

Re:Consistent, sane branding and versioning needed

[WWWWolf]

Well, Sun Java is one of the Giant Bytecode Virtual Machines, and everyone knows that the official versioning scheme of Giant Bytecode Virtual Machines is that of GNU Emacs. So they just decided to drop the first number, like the Emacs folks. Expect the language flame war between Java and C# really flare up into a giant massive global CARNAGE by the time of Java 19 or 20. =) (Though, just for the argument, I can't say C# has any of the redeeming qualities of vi, compared to Java. Both are equally massive. =)

But seriously, yeah, it's more than a bit confusing.

Re:Consistent, sane branding and versioning needed

[ultranova]

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.

The version of the JVM was 1.2, while the version of the Java language it ran was 2.0. It's a bit like GCC 3.0 (the program) supports C89 (the language).

Back to 1.4.3? IS SOLUTION to ALL the PROBLEMS!!!

[Anonymous Coward]

OpenJDK-1.4.3 is the SOLUTION to ALL the PROBLEMS!!!

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 .class files can be easyly decompiled.

Does this mean Sun will start using Java?

[Anonymous Coward]

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?

But...

[xtracto]

Please talk to another side... your mouth still smells funny