Java2 SDK v. 1.4 Released

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

Comments

It's a big step up, but there is still distance

[btempleton]

I've been working on a server that takes a lot of connections in Java, and you can finally do it with the support of "select" in Java 1.4. But no support for SSL. I undertand why it happens, but this "we'll get around to doing the security later" is why we don't have a lot of security.

Java will always present a dilemma. With the push for portability, you often have to wait for the platform itself to support things like this (select) or kludge it in very non portable ways. But that portability leaves the system behind which hurts it in competition with other systems more tolerant of innovation and the fracturing it brings.

A good philosophy would be to rule that every time a system library or feature needs to do something that an ordinary user can't do, they don't just build it in, they make a way that an ordinary user could write it. That paves the way for more innovation.

Re:It's a big step up, but there is still distance

[blamanj]

It's worth noting that the Berkeley NBIO package was part of the research that led to the 1.4 java.nio package.

Also, using their package, and a very interesting partitioned, event-based coding style, they wrote, in Java, a web server that out performs Apache (written in C).

Re:It's a big step up, but there is still distance

[Anonymous Coward]

Outperforming apache isn't much of a feat. If your JVM segfaults, your whole webserver is dead. If an apache process segfaults, only one connection is affected.

Apache was designed for reliability over speed. Try benchmarking against Zeus, NES, or phttpd if you want a reasonable comparsion (single-process server vs single process server).

Re:It's a big step up, but there is still distance

[ggruschow]

You should probably hold up for a while. The Selector still has a few serious bugs, some of which they've acknowledged for >10 months now without fixing.

Don't get me wrong, I'm using the NIO libraries anyway because my company's system needs them, but I was running into a new bug a week for a while. I was hoping they'd have fixed at least the major ones by the time it became official. The workarounds for some of them are just awful.

My major sore points:

• The Selector only supports 63 channels on Win32 (that'll help your scalability :)
• The Selector doesn't work the same across platforms. On Win32 works like WSAAsyncSelect() (only reports channels when something was blocked before), it acts like select() (reports channels whenever they match the requested ops). (Damnit. Write-Once-Run-Just-On-UNIX?)
• Selector.wakeup() breaks after 4096 calls on Linux (Guess I just won't make any new connections :)

J2EE openness

[prockcore]

Well that kind of gives an answer to every javahead that says "Why bother with Mono, when you have J2EE? What a waste of time."

Mono is at least opensource... can you say the same for J2EE? Will you ever be able to say the same?

J2SDK on Win98 and Linux

[Larkfellow]

I have a dual boot machine at home, one partition Windows 98, the other Slackware 8.0. Today I downloaded and installed the new Java SDK 1.4.0-rc on both systems. And while I think that some iscolated windows difficulties causes my oppinion to be rather biased, I found the install much easier going on Linux.

However I will note that, while the Java Web Start was installed on Windows, I didn't find any version of it for linux. And the downside to the Web Start I found is that it constantly wanted to download and install a new version of Java Runtime Environment 1.3.x everytime I lauched an application. And then after the download, and installed, I'm prompted to reboot the computer. After rebooting and trying to launch again, it again starts to download JRE 1.3.x and through the whole cycle all over again.

As well, with my windows install I found I was constantly having difficulties getting it to use the default classpath (ie, no environment variable set for CLASSPATH). I ended up having to resort to specifying the classpath at the command line. And no matter how much I tried, I could no manage to get Swing to work properly.

However on the other hand, the Linux install was rather straight forward, with a few simple steps: Change download to executable; Run it; move the extracted directory to a shared path (as su); add the java/bin directory to the search path; and finally add the java/man directory to the search paths for man.

The windows installer was straight forward, though the above problems still hampered me.

Re:J2SDK on Win98 and Linux

[Westley]

No, all is unlikely to be hunky-dory if you set the classpath environment variable. This seems to cause more problems than anything else to newcomers. It's much easier to avoid using a classpath environment variable in the first place - the default is fine for most things, and the extensions mechanism really helps. I've got short essays about both on the Java bit of my site.

Jon

I've been using this for a while

[autopr0n]

Autopr0n.com actualy runs using the first beta of JDK1.4. I needed the new ImageIO libraries for the, um, 'site previewer :P' (and the regexs made some of the parsing I'm doing a lot easier :). I tried 1.4b3 but it was far more unstable, and my regexs broke.

Definetly cool that the stable version is out, I'll have to upgrade at some point, when I have time.

Hopefully they'll implement this at Topcoder.com too, so I don't have to keep using the old docs in the compos :P

At least Sun is brutally honest.

[Marsh Jedi]

Jesus, Sun's PR corps must have flipped their collective shit when they read Karen Tegan's remark. While in general I find that kind of bluntness refreshing, a director of Platform Compatibility spouting off and essentially saying, "Well, that sucks for you, but we make money off of compatibility testing. We give everything else away for free, so cut us a break." is really a testament to the Sun Micro (brutally) plain-talking attitude.

Deeper, though, I think, is the need to rein in Java a bit....It has achieved ubiquitousness, and I think Sun knows it. Watch. If .NET takes off, they will loosen up to benefit from a little more old-fashioned agrarian innovation and buzz.

My take on JDK 1.4

[burtonator]

OK.. I am a Java fan... (recently this has been changing though.)

I have mixed feelings with JDK 1.4.

The JPDA (debugging) support in 1.4 is vastly improved. You can now redefine classes in a running virtual machine. This is really cool and I have written an Ant 'Redefine task to take advantage of this.

The assert facility is OK.... i don't like the fact that they added an Assert keyword but I don't get to make the decisions.

There is also some controversy.

The JSPA agreement that one has to sign to participate in the JCP is WAY too restrictive for Open Source developers. The Apache Software Foundation has a good document where they drawn the line in the sand on their participation.

The Log4J people are upset because there is now a 'stanard' Java package for logging. IMO the 'standard' package is inferior to Log4J in many situations.

The regexp package is not all it is cracked up to be either. I would recommend Jakarta ORO or Jakarta Regexp.

As far as that... it runs GREAT on Linux. Probably the most SOLID VM I have ever run.

They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

As far as C# vs .Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.

Also.. check out my Reptile project. It is Java based, only requires JDK 1.2 and incorporates some really cool Java/XML stuff. :)

Re:My take on JDK 1.4

[damm0]

As far as C# vs .Java. I am really impressed with the CLR/CLI stuff. Right now, as it stands, Java is a proprietary language. Unless we see SUN Open Source Java (or push it through a standards committee), we *may* see a JDK 1.5... but no one will use it.

I'm not sure how much C# coding you've done. In recent months I've written quite a bit of C# and .NET code. Let me enlighten you with regards to the implication that C# is either not proprietary or cross platform.

It may be true that C# - the language - is cross platform and may acheive recognition as a standard of some sort. However, the .NET framework (which almost every C# program written uses) is not cross platform nor will it be a standard.

Why? Because of small details in the API. Let me give an example. Let's say you want to find out what operating system your program is running on. In Java, you do this:

System.out.println( System.getProperty( "os.name" ) +
" " + System.getProperty( "os.version" ) );

Looks pretty straight forward. In C#:

using System;
...
Console.Writeline( System.Environment.OSVersion.Platform );

Now this all looks very nice. The problem is that the Java version gives you a string, and the C# version gives you a... enum. That's right folks, to find out what operating system you are running, the .NET platform gives you an enumerated integral constant. This means that you have three choices for which operating systems you can discover you are running on, and which operating system the operating system can tell you it is.

Those three choices are:

1. Win32NT
2. Win32S
3. Win32Windows.

(If you want to verify this yourself, check out the System.PlatformID enumeration.)

Now, how do you make this cross platform?

Good articles

[mattscape]

Are there some good articles out there (besides the sun ones) on how to use the new features?
thx
matt

Kodak invented OLE?

[blair1q]

I just took a look at the three patents Kodak is suing Sun over, and, huh?

Sure looks like Kodak claims it invented OLE.

Which, hey, they may have, and Microsoft either licensed or stole it.

What's the real story?

--Blair

Re:Not meaning to troll but....

[mccalli]

What good is this platform really?...It seems to me that Java is nothing but slower than other languages

The platform is not the language.

Java is good partly because of its pragmatic syntax (C++ish with some sugar added, some sugar taken away), but mostly it's good because of its excellent class library.

Though I haven't written anything serious for a year or so due to a job switch, I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.

Cheers,
Ian

Re:Genericity?

[Westley]

The proposed generics proposal are all compiled into the bytecode anyway, I believe. There's a prototype compiler (which generates bytecode which can be used with the normal JRE) available here.

Jon

Re:Asserts

[Anonymous Coward]

Yes. Asserts are easy to use and have a huge payoff. They are especially good at catching nasty subtle bugs.

They are easy; they catch bugs that might not otherwise ever be noticed (or noticed only as some pervasive flakiness); they save you a lot of time that would otherwise be spent debuging; they are good documentation; they don't cost anything in non-debug builds; they save you from a lot of pain. Despite all this, I haven't yet successfully convinced a single person who is unfamiliar with them of their value. Christ I get dismayed sometimes.

This interview with FreeBSD kernel hacker Matt Dillon has some interesting things to say about assertions ("it greatly contributed to our famed stability in 4.0 and later releases [of the FreeBSD kernel]").

Java finally has them? Cool. What year is it again? 2002? Jeez ...

Re:Genericity?

[gatesh8r]

From the article:

Bracha pointed out that one problem with C++ templates is code bloat. For every List<T> of type T, C++ generates a separate class.

I'm glad someone posted this link. This is EXACTLY the problem with C++. It isn't in the class structures (they are almost exact to C's structs) but the fact that the templates have to generate seperate class structures to make sure that each one doesn't conflict.

This I have seen working with C++: A matter of a template has done almost a 25% - 80% reduction in my executable size. I'm not kidding -- from 1 MB to 200 kB! This was the case because I made two instances of the same class (cut 'n paste) because I really didn't need all the generics involved in the program. While typing all that stuff then doing a cut-n-paste was slow to do, the executable size was worth it.

Anyway, if you code in C++, the STL is decent FWIW. I wouldn't lean on it though if you're going to do major embedded coding... but get the String class; it's great.

skeptical for the desktop

[Anonymous Coward]

Sun are putting the desktop on the back burner. I know they mention JFC/Swing in performance improvements but that's not the only place where the effort needs to go. If you search their bug database for open reports on most any GUI component you'll at least a half dozen bugs open, many of them years old (check out JTable and how well done that is). I haven't seen the soure code yet, but I'd also assume they didn't suddenly go "Hey, why did we write StringTokenizer to be such a slow, memory-hogging piece of shit?" or similarly? Sun is like Microsoft - they make as many features as possible, worry about the bugs later and let hardware catch up to overcome their crippling defects caused by overzealous and misinformed OOD. The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations. I would rant on more but I've said this too many times already. Don't worry, I'll stop once I can get enough money to work for myself and dump Java.

Re:skeptical for the desktop

[E-prospero]

Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java

I find the example set by WorldBook 2002/MacOSX to be a stunning demonstration of Java's potential if Sun would just wake up and smell the coffee (pun intended).

I like Java a lot - both as a language, and as a bytecode platform. I use it daily at work, and at home for my own projects (after many years of flipping between C, C++, and a dozen other niche languages)

My only major bugbear with the JDK is not with Java itself, but with Swing: It's godawful slow (The Hello world app should not take 30 seconds to display on a P400), it's API is occasionally appalling (JTree anyone?), and it has a habit of being occasionally buggy.

Above all, it reinvents the wheel with widgets. The Look and Feel implementation very occasionally looks and feels like a platform native application (Win2k LnF anyone?). However, it usually looks and feels like someone has tried to reimplement a system native toolkit using only a blunt light blue crayon.

For many a year I have whined to all that would listen "Why the *@*)(!&*@ doesn't the Java widgeting toolkit defer to system native widgets for window display? Surely this would look better and run faster than pixel blitting a widget look-a-like!"

MacOSX provides just such an API. Although Objective-C is the `preferred' language of Cocoa, there are Java bindings. Note - this API is NOT Swing - it is a MacOSX extension API. Consequently, a MacOSX application built in Java should be almost indistinguishable from a native compiled app in terms of look and feel. And according to your comments, performance is also indistinguishable.

I have played with Java bindings for Gnome; they provide blindingly fast gui performance, using the same java runtime as is used by Swing. However, there are several java binding projects for Gnome (all partially complete), and none of them really address the general problem of widgeting across platforms.

I have also played with Eclipse, the IBM Java . Their widget toolkit is cross platform in API but system native in widget; however, I have found the performance of the Eclipse widget set to be almost as bad as Swing. However, it is beta code - we may have to wait and see if anything improves with age.

Java/Gnome demonstrates that it can be done under X. Eclipse demonstrates that it can be done cross platform. MacOSX demonstrates that it can be done well enough as to be indistinguishable from system native widgets.

So can anyone tell me: WHY hasn't it been done? (And don't say its because they don't want to break backward compatibility - Look at 1.4's NIO framework and VolatileImage).

Russ Magee %-)

Re:skeptical for the desktop

[Anonymous Coward]

Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications.

Java *can* be made to run as fast as C/C++ apps but it's rare and only for certain applications of Java. Different compiling and runtime techniques technique such as JIT compiling and using HotSpot can get "primitive functions" - those on arrays of int, floats, etcetera to near comparable C/C++ code. However, the Java built-in libraries have enough built-in bloat to make further promises of speed indistinguishability just plain misleading ("it works fine, just avoid this list of 50 poorly implemented classes"). No, Java the language isn't slow, but Java the set of Sun library implementations has many, many deficiencies.

Also, I wasn't saying that all of Java is one big bug but you can't argue that there are a tremendous amount of bugs in Java's standard APIs. Things like horizontal scrolling not working for JTables. I mean c'mon, really - that's just a standard bounds checking and listener notification algorithm and the bug has been around since 1998. I know JTree has major problems (e.g., node rendering of icons works differently for nodes being edited than those not) and the DefaultTreeNodes in the Java API are overwritten to no end other than inefficiency. Drag and drop doesn't work with multiple items, thus almost no one ever uses DnD in the apps I work on - hell, even I don't because at least I can rely on copy and paste. Well, within the same application, actually, outside of the same VM trouble starts.

It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code).

Well yes, it runs, but it is far from guaranteed that it runs _well_. I took some of my company's Java apps that ran well under Windows and tried them under OS X and they were dog slow. At one point I managed to get ProcessViewer to report CPU usage over 100%! Highlight some text in your browser - that's what it does. Two simple math coordinate checks, a couple calls to drawRect and drawChars, written about as efficiently as Java allows but with every set of mouse movements I saw the CPU usage shoot through the roof. [The reason I made a custom class for this was because JTextArea and JEditPane were horrendous due to my need for special formatting - I have literally 50 times better performance now than with JEditPane and about 10 times better performance than with JTextArea on my wintel machine.] I know JBuilder runs fine on my machine (I suspect some Mac-specific code or vm settings) but Java isn't at all guaranteed to run well across platforms. Of course, my machine is 3 years old - so is Java 1.2 SE but as I was saying, Sun relies on hardware to catch up. I'm sure it would run fine on a 1 GHz dual processor G4. [Actually I think graphics cards have a large part in Java's performance.]

they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java

Believe me, when something crashes that means to me that it wasn't written in Java. I have never dealt with another language so stable. Even when internal exceptions are thrown I've seen apps soldier on through their own bad states and actually still work, though they do of course become flaky. LnF hasn't really been much of an issue either - Windows and Linux have always looked like crap (haven't tried XP yet) so I've never expected Java apps on either of them to look good and really wouldn't care if widgets on them weren't completely "native-looking". On Mac, it looks sweet except for text rendering. It really is the performance problems and the bugs in Sun's libraries that are the worst thing about Java. The bugs are actually probably more annoying because they are the let-downs "Oh, look it has this great gui widget" and then ten days later "Oh crap that widget has a horrible bug and I'm completely reliant on Sun to fix it or else I have to either write my own version of that widget or steal their source, fix it, recompile it and then only be able to use it internal to the company." It's not a great working method - if they allowed for people to make fixes to Sun code instead of all of us having to either live with the bugs or rewrite entirely new classes, Java would have a much better set of library implementations. Instead people like me have to decide whether we can spare the time to write whole new versions of objects with the same functionality but, well, functional, or tell our boss and have our PR tell our customers "Yes, we know that doesn't work right. It's a problem with Java and there's nothing we can do to fix it." Believe me, as a professional programmer I can tell you that happens over and over again and it is a situation that benefits no one (well, except if you have direct competition that isn't reliant on sun's java libraries, then they benefit).

Re:hope swing is faster now / I prefer Ruby over J

[raistlinthegreat]

I have read the articles. There have also been a lot of these articles when jsdk 1.3 came out and Swing was not much faster. Swing is a cool idea. If it could match the performance of VB on windows or Qt in Linux there would be much more cross platform apps and this would also help linux onto the desktop.

Re:Genericity?

[khuber]

1.5 [javaworld.com]

The 1.5 Java generics are merely syntactic sugar. Since the casts still occur, there is no performance benefit, only cleaner source code. There is no way to parameterize primitive types like int.

I do not consider the proposed generics to be adequate. You are still better off, performance wise, generating your own custom collections for specific types. This is what GNU trove does.

-Kevin

You agree to all future licence agreements.

[andaru]

"the Software may automatically ... install... ("Software Updates"), which may require you to accept updated terms and conditions for installation."

This means that they are claiming that if you agree to this licence, you are also agreeing to the licence of any application which installs itself (and you have agreed to let it install itself).

I'm sure that that is not legal, and could invalidate the whole agreement. On the other hand, I don't see how a licence agreement that you haven't signed is worth the pixels its printed on.

To say that Sun's online license agreements are binding would be to say that you are not allowed to click on a button with two words on it which is displayed on the web without agreeing to this contract.

As someone pointed out in response to another article, not agreeing to the licence agreement preserves your right to click on the "I Agree" button without agreeing to the licence agreement. It is in the agreement that it says that you agree that clicking the button means that you agree.

Is that convoluted enough?

Wording was bad

[SuperKendall]

The story should have read "no LICENSED open source J2EE implementations". There are OS J2EE app servers (JBoss), and in fact they are quite good... the problem (as stated in the article) is that it's hella expensive to get the official seal of J2EE. That doesn't mean it doesn't work!

Now if you think .NET is better, you have to ask how good an open .NET server you're going to be able to build without ASP.NET or Windows Forms. Neither of those are part of the current ECMA submissions, though as stated in the .NET article yesterday they are expected to be submitted at some point...

At the moment J2EE has gone through a lot of refinement, and I think makes a pretty good platform for server side development. I think desktop code is still up for grabs by either Jvaa or .NET (at least under windows). It will be interesting to see if .NET app development is nearly as annoying as MFC was (I doubt it will be).

Re:My pet peeve.

[Captn Pepe]

You shouldn't dump too much on patent owners who aren't fully utilizing their patents -- most small inventors (whether they patent their invention or not) see large corporations swoop in and seize their work before they could possibily have capitalized on it. If they're lucky, they have a patent and a good understanding of patent law, and can thus make something off of the corporation in question. Usually not, though.

You probably don't want to strengthen patents any more than they already are, because we're already seeing all kinds of problems with software patents being used to lock open source solutions out of various areas. Many industries also have the problem that start-ups are impossible because the established players already own the necessary patents, and have no interest in licensing them to a new competitor.

Personally, I suspect that the answer is probably a compulsory license regime for patents. In this case, a sensible solution might be to set default payments which are somewhat high, but that scale with number of units sold and price charged. Thus, large corporations still have an incentive to negotiate with patent holders for lower license fees, but start-ups needn't pay anything until they start shipping units, and would be free to use the patents at that rate whether or not their competitors want to let them into the market. Finally, free software would be protected, since in this scheme the developers would be implicitly accepting the default terms, which wouldn't require payment for copies not being charged for (but RH et al would have to fork out for distros that they sell).

Unsurprisingly, a number of powerful lobbies have ensured that this cannot happen without major changes to our IP system; for one thing, it would require breaking the WIPO treaty, which the megacorps paid really good money for.

Re:Still no GUI fixes?

[Knight2K]

Actually, the release notes claim that it has fair amount of performance enhancements to the Java2D API including support for 2D hardware acceleration. On UNIX X-Windows calls are used to implement the Swing GUI classes to improve speed. Sounds like we will see some significant performance gains on all platforms, if you believe the documentation. I haven't seen a Swing app run under 1.4, so I'll reserver judgement.

Re:Headless at last - bye bye XVfb

[Fjord]

You've always been able to use java.awt.image.BufferedImage to create dynamic images. The application I'm working on does that. But you are right that now you don't have to use xvfb (which I never thought was that big of a pain, but I like the -D solution better).

I'm kind of interested in java.awt.image.VolitileImage. It makes an image using the video card's memory, with the trade off that the image may be destroyed at any moment. I've done some tests and on my machine it didn't improve performance at all, but on a system with a good video card, it may be an awesome class.

Re:Yah, will this be stable on Linux?

[RMSIsAnIdiot]

So... to counter that, an NT BSOD is almost _always_ due to a shotty 3rd party driver or strange hardware issue. So we can't really blame windows... only the buggy drivers we have running! So you should only complain about Windows being unstable when it is running a vanilla install.