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."
Apple had an appauling track record with Java until fairly recently...
.NET platform. So I said screw it and went NetBeans for a while.
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
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?
A programmer is a machine for converting coffee into code.
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.
A programmer is a machine for converting coffee into code.
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.
:a bleChild(IntegerInterleavedRaster.java:462)d (IntegerInterleavedRaster.java:516). getRaster(FastGradientPaintContext.java:53). access$100(FastGradientPaintContext.java:37)r (FastGradientPaintContext.java:142)v a:718)
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.createWrit
at sun.awt.image.IntegerInterleavedRaster.createChil
at com.incors.plaf.FastGradientPaintContext$Gradient
at com.incors.plaf.FastGradientPaintContext$Gradient
at com.incors.plaf.FastGradientPaintContext.getRaste
at apple.awt.CSurfaceData.setupPaint(CSurfaceData.ja
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".
It's all 0s and 1s. Or it's not.