Java 1.4.1 Update 1 for Mac OS X

hrbrmstr writes "Regular updaters will already know, but Apple issued an update to Java today. It adds the following enhancements: improved Java applet support for Safari and other web browsers that support the Java Internet Plug-In; improved drawing correctness and performance; changes to Java 1.3.1 that provide support for Oracle11i client applications on Mac OS X; improved stability, memory usage, and correctness."

Comments

Robocode?

[Hanji]

Does anyone know if robocode works right with this new version? It's the one program I've found that seems to run *much* better on windows Java distros than on OS X (it's basically unusable). I'd really like to see that working, because it's a great game, and a fun way to learn Java.

Re:Robocode?

[TheAJofOZ]

It runs just fine.

For the record, a great deal of performance problems (but not all) are caused by poor code in the program - particularly to do with selecting graphics types. Check the java-dev list archives for details. Having said that, drawLine() in previous versions of 1.4.1 on OS X gets slower each time you call it and that seems to be fixed in this version which will make a significant difference.

Re:Robocode?

[BortQ]

For what it's worth, robocode was used to demonstrate java improvements/speedups in multiple presentations at this years WWDC.

Re:Java + OSX == happy

[kwerle]

It's fairly obvious that Sun has made an effort to assure that Solaris + Java == happy

And here I thought that SUN's whole purpose was to make sure that Solaris + anything = miserable. That was always my experience - but I've not touched Solaris for 4 or 5 years...

Do these updates let Hushmail work on OSX yet?

[ratkins]

I think Hushmail is using some wierdo sun.* encryption library that hasn't so far been included with Apple's Java libraries. Have they fixed this? It sucks having to check my Hushmail account at work...

Makes Batik work better

[David Eppstein]

I've been using Batik to view and convert SVG image files, and had some problems with incorrect rendering (e.g. dashed strokes getting inconsistent dash lengths). Seems to be all fixed with this new version.

Re:1.4.1?

[The Herbaliser]

Because they're not Sun.

Re:correctness?

[notfancy]

You surely must be joking... or is it the late hour that impairs my sense of the ironic? Nevertheless, I'd like to advance a disclaim: I religiously perform my hygienic duties on every morn, so I resent your mention of the odorous populace.

What can I say to persuade you that "improved correctness" is Newspeak for "we fixed some bugs", which is more transparent but less palatable for a release note - become - press release?

Re:Java + OSX == happy

[inertia187]

Apple had an appauling track record with Java until fairly recently...

It's still pretty bad, according to Borland. Yes, the deltas are quick, but the adherence to the actual Java Language Specification is still pretty appalling.

Apple still has the balls to show JBuilder on the main page all this time, even though they broke JB7 when 1.4.1 first came out. Because of these adherence problems and the native loader breakage (even though Apple supplied a workaround for them), Borland hasn't felt that OS X has been "prime time" so JBuilder versions 8, 9, and likely 10 will be without an OS X version - even though there are Linux and Solaris versions. I'm talking about official support, you can still force JBuilder 8, 9, and 10 to run on OS X, but Borland doesn't officially recognize it.

Thankfully, JBuilder 7 has been fixed in this Java Update from Apple. Hopefully, this will bring OS X back into the Borland fold.

Yes, Java + OS X makes me happy too. I personally have not had the issues Borland points out with the MRJ. I think Borland is crying sour grapes because of political pressure from Microsoft's .NET platform. So I said screw it and went NetBeans for a while.

I've been pretty happy with NetBeans, and have had great success at mixing platforms. I can work on the same CVS tree using JBuilder on OS X and Windows, as well as NetBeans on OS X and Windows. Just takes an Ant script to allow NetBeans to use the same project tree as JBuilder.

Check out my personal web site, coded entirely in NetBeans on Mac OS X. Umkay?

Installing JBuilder on OSX

[WatertonMan]

OSX Hints has the following on how to install JBuilder.

BTW - where did you hear Borland dropped Mac support because of language adherence? I've never heard that. I heard more that people were simply picking Eclipse or Project Builder over JBuilder. I'm not sure why. What little I've played with it JBuilder seemed pretty nice, although my Java friends all seem to dislike its auto-code generation.

Admittedly Borland has been pushing their .NET plans a lot. I'm not sure if that will end up working for them though. As nice as their product is, it doesn't offer that much more compelling than Visual Studio other than their UML integration. (Which admittedly is pretty damn cool - but I wonder how many in practice use UML)

Re:Installing JBuilder on OSX

[inertia187]

Keep in mind, the Mac OS X Hint about installing JBuilder is for versions beyond 7. In fact, that hint is for JB9. If you go to the macintosh forum on Borland's news group, this is all they talk about now. No real support there anymore. Yet, JBuilder 8 and 9 are able to create OS X native loaders. They just never worked until this MRJ Update. ;-)

where did you hear Borland dropped Mac support because of language adherence?

Actually, I cannot reveal my source on that. Officially, Borland claims that the SDK just came too late for OS X which is a valid reason in and of itself. JBuilder has to not only have 1.4.1 for source development, JB8 and greater had to be able to run under 1.4.1. But that doesn't explain the lack of JBuilder 9 support, so it has to be something else. And that fact was confirmed to me personally. I wish I had more details, sorry. If that fact is wrong, I'd love to be corrected by someone who knows otherwise.

Also, look at what SDK OS X exposes - J2SE. It's up to the third parties like Macromedia to expose the J2EE layers on OS X. Borland wants to push J2EE as much as possible, but doesn't want to get into the J2EE design on OS X business like Macromedia has. To this day, OS X cannot support the Borland Application Server because of this. Who's fault is it? Well, if Apple could sell more XServe boxes, then maybe more third parties would take notice.

Anyway, I can't use JB7 anymore. Not sure who to blame for that. I have a TiBook 667 MHz w/1024 Megs of memory. JB7 is so slow, it's unusable. I just thought I was to blame because I didn't want to pony up the dough and upgrade to a newer TiBook. But when I opened the same project in NetBeans, I could actually get to work - even in debug mode.

Furthermore, even JBuilder 9 on Windows doesn't support the Tomcat Manager out of the box, where NetBeans does. It's a big advangage for me to be able to modify a servlet or non-JSP Java class and not have to restart Tomcat. In NetBeans, I just access the manager context and inform it that I need to restart it. Yes, I loose the sessions, but I have a way of reloading their states as well.

I don't expect even JBuilder 10 to support this functionality. It's a small but powerful feature that isn't even exposed by the IDE. Borland has a very good signal to noise ratio on features, but this is one "must have" that has never made it.

Not Swingin' quite yet (f/ Java shareware dev'r)

[mactari]

The first version of 1.4.1 for OS X was obviously shooting for enterprise users. Headless apps worked well, and there was even a new way of opening apps that wouldn't create icons on the dock to support headless apps in a seamless, usre friendly fashion.

As a shareware client app developer who targets the Mac, I've been watching Apple's JVM from a different angle. 1.3.1 was a nice VM, and with the Aqua look and feel I've had some comments that assumed my Java application was native.

Now as a client app maker, I was looking forward to Java 1.4.1 on OS X for, of all things, mousewheel support. I got that, but I also got a number of issues with any look and feel *other* than Aqua. Menus didn't paint correctly at times, text sometimes didn't paint the way I expected in JTextAreas, and after a few checks I decided it was better to continue to shoot for the 1.3.1 VM rather than rip my code apart to get around OS X-specific quirks. Headless apps might have worked great, but Swing, Java's "de facto GUI toolset of choice" didn't. Comments about JBuilder (it seems the most popular client apps in Java other than Limewire are Java IDEs for all those headless app makers) in this thread help support that.

If you didn't catch that, I said I targetted 1.3.1 even after the 1.4.1 release. That's right, Apple had enough problems in 1.4.1 (my spin) that they left two nearly mutually exclusive JVMs on each OS X system after upgrade. New Macs wouldn't ship with just 1.4.1. Developer tools allowed and allow developers to force applications to run under just 1.3.1 if they'd prefer. Apple wasn't (isn't?) quite ready to put all the eggs in one basket. Aside -- I wonder if Panther will ship with just 1.4.1?

From what I've seen of this VM after a few minutes of testing suggest that I might be able to release a new version of my app that uses the latest VM installed, which would be great. That said, the Kunststoff Look & Feel, a relatively trivial extension of the standard Swing Metal (or "Java") Look & Feel still ain't happy out of the box. A few lines from its song when running my app under 1.4.1, new update, below:

apple.awt.EventQueueExceptionHandler Caught Throwable :
java.awt.image.RasterFormatException: y lies outside raster
at sun.awt.image.IntegerInterleavedRaster.createWrita bleChild(IntegerInterleavedRaster.java:462)
at sun.awt.image.IntegerInterleavedRaster.createChild (IntegerInterleavedRaster.java:516)
at com.incors.plaf.FastGradientPaintContext$Gradient. getRaster(FastGradientPaintContext.java:53)
at com.incors.plaf.FastGradientPaintContext$Gradient. access$100(FastGradientPaintContext.java:37)
at com.incors.plaf.FastGradientPaintContext.getRaster (FastGradientPaintContext.java:142)
at apple.awt.CSurfaceData.setupPaint(CSurfaceData.jav a:718)

Fwiw, here are the versions of the old 1.4.1 and the new:
prompt% java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39)
Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode)

prompt% java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-69.1)
Java HotSpot(TM) Client VM (build 1.4.1_01-24, mixed mode)

Interesting to note that Apple is still behind. 1.4.1_02 and 1.4.1_05 have been released by Sun for some time now. Not a big deal, but a little evidence that, though OS X's "built-in" Java support is the best you'll find in an OS, it's hardly "latest and greatest".

Yahoo Games?

[davebo]

Is anyone else experiencing all sorts of oddities with Yahoo Games after this install?

In Safari, all text is replaced by X'd out squares.

Camino won't load.

I've check with Hearts & Pool - am I the only one this is happening to?

Show me a perfectly unambiguous specification

[lordpixel]

... and I'll show you a perfectly correct implementation.

The JVM has a reasonable specification. The 1000s of classes that ship with it do not have a good specification. The closest you'll get is deciding whether it should work like version X.X_0X of Sun's JDK on Solaris. Or should you do what the Windows implementation does? or perhaps the Linux version? or maybe you want to do something different again to be in line with Apple's UI specs for OS X?

Correctness in these large systems is a myth, so I don't see a major problem with something being "more correct".