Slashdot Mirror
Apple Updates to Java 1.4.1
A user writes, "Apple has caught up with the times and updated their Java to 1.4.1, bringing it completely up to date with the newest release from Sun. It now takes advantage of Aqua and Quartz Extreme, is usable via Universal Access, and can be controlled through AppleScript." It provides 1149 new classes over 1.3.1, a new native I/O API, updated XML tools (SAX 1.0/2.0, DOM 1.0/2.0, XSLT), I18N and L10N enhancements for Unicode 3.0, regexes, IPv6, faster loading of applets, improved caching, storing of certs in the Keychain, faster UI, more Aqua-like UI ... and native Java applet support for Safari.
Time to try IDEA
Guvf vf abg n EBG zrffntr
I do development work (well, or did, but that's another isue), and the Lnux systems use Tomcat with Java 1.4 - mainly because it has the Regular Expressions stuff built in.
I usually develop things on my Mac laptop, then transfer thing over to the official test system. But since I only had Java 1.3, it was harder to develop my stuff for them - I had to have a separate Linux box just for me to use as a mini-server.
Well, I no longer work there and am about to take another job, but at least I an update my system and work on my new web publishing system.
My only fear? That Java 1.5 will be released in a few weeks....
52 Weeks, 52 Religions with John Hummel
Full release notes from Sun Microsystems on release 1.4.1, includes overview of changes and detailed description on many updated packages, etc.
I've been waiting for this for months (from before java 1.4.1 even existed actually, when all I wanted was a small update to fix some bus with the previous JVM). It fixes alot of bugs in good ole fashioned AWT, from what I understand. Most were nothing I couldn't work arround, but it was still a pain.
Hopefully this will provide a serious speed boost too.
It's a good day to be a mac java developer.
"The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
Well ive installed 1.4.1 from software update and so far its fixed some bugs that were annoying me (some applets didnt work in safari) and performance is definately up. A friend noted an almost 4 fold increase in loading time for one of his projects. Go Apple! :)
It is a little rough around the edges and really needs some fine tunning but runs like a dream on my PowerBook running on JAVA 1.3 no less. With any luck they will upgrade it to use the 1.4 code base they are already using for Windows and Linux clients. It is quite resource intensive, however on the Powerbook I don't notice that at all (just on the Windows development machine at work ~sigh~).
Just installed it and now I can finally scroll a web page with an embedded Java applet without leaving behind artifacts in the broswer window from the applet. The difference is obvious in a page like news.bbc.co.uk were the news ticker no longer corrupts the whole page view when scrolling.
XNap works great. Always finds more files than Limewire. Get it at http://xnap.sf.net
Apple's 1.3 VM was DEFINATELY NOT CLI ONLY.
It had a perfectly reasonable AWT/Swing implementation which was derived from the old Mac OS 9 implementation and ran ontop of Carbon, which means it did have the Aqua look and feel and it did run ontop of Quartz.
You can just about make that out in this diagram: http://developer.apple.com/macosx/images/sysarch_s m.gif
Now, we can talk about reimplementing AWT/Swing ontop of Cocoa rather than the crufty 20 year old foundation that is Carbon - and probably we can agree its a great thing, but it sure did take a long time. Its definately not the case that this is the first release with an Aqua GUI though!
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
My point is that Java seems primarily used for client/server applications or XML based messaging. (Thus the large number of UML programs) The end user applications end up tied into that via support. Other than a few so-so chat or P2P clients, I just don't see many end user applications writen for Java.
Don't get me wrong. I'm not knocking Java. Some folks who work here swear by it. We're even going to start coming out with some nice Java libraries and toolkits ourselves. But it seems oriented towards custom programs and perhaps largely the enterprise. Sort of one step up above scripting languages like Perl or Python but not quite in the C++ territory.
Yet I just never see applications outside of that market. Not a slam. Just curious. It just seems odd that there are more Basic programs for OSX than Java. (At least judging by what gets downloaded at VersionTracker)
"Useful" is a relative term but I use Thinkfree as my main Office suite. It is built on Java architecture.
My personal best Java app for OSX is DVArchive. It requires Java 1.4.1, for which I installed the beta 10 version yesterday. Arrghh!
Anyway, I am hoping that this will make DVArchive run even better.
and my favorite, Arachnophilia, finally works on my mac! I am now happy again..
:)
Well, that and my dos xx is right here as well
For the price why don't you buy WebObjects 5.2 and use ProjectBuilder with InterfaceBuilder already?
Or better yet since you are discussing client-side apps you don't need to spend one penny and just download Apple's tools.
Of course if you are adamant and have lots of use with IntelliJ great but you'd be surprised how nice PB/IB work.
The "Java 1.4.1 Developer Tools Update" available via https://connect.apple.com/ -- after you log in, it's under "Java" under "Download Software". There used to be "Recent Updates" section where they put stuff like this, but it seems to have gone missing.
What I really want to know is why it's 48.6mb for the dev tools on top of the 26mb (I didn't write it down, so I could be wrong) for Java 1.4.1 itself.
I don't think the parent post meant that Java for OS X run only from the command line (obviously it didn't), or that it didn't support Swing (well, duh, of course it did), but that support for these things was weak -- which was certainly true.
Mr. Cornelius is right that Java has been something of a second-class citizen on OS X. Java is privileged to be a real citizen of an OS at all -- on Linux it is a sort of visiting dignitary, and on Windows it is a sort of persecuted immigrant. But OS X Java wasn't perfect: Swing apps, while they looked great, definitely didn't run as smoothly as Carbon and Cocoa apps. Applet support was mostly good, but still spotty. Apps were slow, especially UIs and graphics in general. And, of course, Java was waaaay out of date.
The new version of Java is a huge leap forward in all these problems. With this newest release, it looks much more like a "first-class" citizen than it ever did before.
It's nice to have OS X remind me of updates that actually IMPROVE performance. This is real nice coming from a Windows world where every week there's a new "Windows update," fixing some bug that was discovered 2 weeks before.
The difference? In Windows land an update meant, "Fuck, what 'security patch' is ready to be downloaded now? This is so annoying." In OS X, when software update pops up I'm generally wondering what new improvements there are to things overall, and happy about it.
"Come for the Java and stay for the Cocoa and the Java." Last year it was just "Come for the Java stay for the Cocoa".
Freeguide is pretty cool. It didn't run at all on OSX's old 1.31-based JVM (nor on some of the earlier 1.4 betas), but I'm running it right now on top of the new JVM.
Now, I didn't know Java when I started. I learned Pascal in college and I've made a few attempts to learn C++, but I've never really succeded.
I picked Java for this project because I intended it for educational purposes and I'm not delusional enough to think that anyone would adopt my program if it was MacOS X only.
Anyway, long story short, I've written a beta quality piece of software for statistical design of experiments using the Java/Swing API. I thought it was pretty easy to work with, and the speed is more than adequate, even on my iBook/500.
I think the reason you don't see more Java Apps is just that not many people have inscentive to write their programs for cross platform use. If I had been a Windows user, I probably wouldn't have cared about the people who don't use windows and just learned C++ and the Win32 api. There wouldn't be the inscentive to capture the other 5-10% that doesn't run Windows. Even most Mac or Linux programmers don't care. Even though Java really is "fast enough" for most things.
BTW: if anybody would like to beta test some Java software for Statistical DOE, email me. Let's see... Take my slashdot username and email me with that at mac.com.
--
The internet is the greatest source of biased information in the history of mankind.
Yeah But it broke my blender!!!!!!! www.blender.org ..and this is on topic, blender is a 3d rendering tool that apparently used java to do its work on OSX
Cheers
NO, it won't. The reason that Limewire sucks so bad is that way back when thier app didn't redraw things properly they added new code that messed with the window server in order to make Limewire draw properly. Every thing that touches any screen space with Limewire starts warping and can do wierd things. Everyone please email the Limewire people and tell them to stop doing this, it is the single reason i stopped using Limewire and have yet to ever install it again nor even bother with another release.
-"I'm one of those Mac people that will break a bottle on the bar and hold it to your throat for bad-mouthing my system"
i have a applet that creates cartograms and the difference is amazing (go to the 'map' menu item and create a cartogram with 10 or so iterations). previously, one would see each iteration rendering, while 1.4.1 in safari almost instantaneously creates it.
Well, I think that actually people *do* write lots for Java, but Java is better at different things than C or C++. It doesn't show up in consumer listing like Version Tracker Basic is good for nothing, and the only reason you see it on VT so much is the same reason you see VB for windows: tons of bad developers using drag-and-drop solutions.
Java is good at non-GUI things. I mean *great* at it. C is much better at rendering graphics. So, Java lives with developers and server apps mostly. I have never found a lack of Java libraries to support in me any given task.
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)
LimeWire(Acquisition)/0.8
LWMain A
SettingsManager: loadDefaults()
ConnectionManager initialize()
And so forth.
"Reality is just a convenient measure of complexity" -Alvy Ray Smith
This feature had been open to editors, so that they could catch mistakes.
And since it worked so astoundingly well for that, the powers that be decided to open it up for paying customers, too.
I write in my journal
Without a doubt, ReaderWare , a book, DVD & CD cataloging suite that has absolutely saved my life...
Ladies and gentlemen, I give you the scourge of the 20th century: hyperbole.
Unless you'd care to post some kind of fascinating tale of adventure and suspense in which your book database saved you from certain doom, curb your enthusiasm a little, okay?
I write in my journal
i'm not really too sure what you mean. limewire ues java's swing implementation to do the drawing. if java does funky redraws, then so will limewire. either way, you can download the code yourself -- just look at the 'gui' project from www.limewire.org .
and yes, improving java *will* improve acquisition, because acquisition literally runs limewire's java core and then provides a native interface for it. so if limewire's core is running faster (which it might, because it'll be using java 1.4), then the interface is updated faster and the program as a whole is faster.
i can assure you there's no code that "messed with the window server". the warping you're probably referring to is java being slow and not allowing time for the Swing Event Thread to completely process all the redrawing. but, the code tries to make sure that swing is given as much time as possible to keep things updated.
"Give me the book, or you're a dead man," sneered the thug behind the revolver.
"I can't," whimpered TedTodorov, "I lent it to my cousin Bruno."
Cocking the gun the thug replied, "Prove it!"
At which point TedTodorov slowly slid his laptop across the blotter on the desk, turning it to shine into the beady eyes of his foe.
"See? It says I checked it out to him last week..."
This sig intentionally left justified.
From the Apple website:
"On other platforms, each Java application consumes some system memory. So you might end up using more memory than you need to when running multiple Java applications. Other languages, such as C or C++, solve this problem using what?s called shared libraries. Apple developed an innovative new technology that allows Java code to be shared across multiple applications. This reduces the amount of memory that Java applications normally use. And it fits right into Sun?s Hot Spot VM, allowing Mac OS X to remain compatible with standard Java. In addition, Apple has given this implementation to Sun so the company can deploy it on other platforms. Just one example of how Apple supports standards and shares ideas to benefit all"
That's very nice of them.
1) is this supposed to happen?
Oh, I missed that. IIRC one of the improvements Apple were making was to have java preloaded. One of the big reasons java is perceived as 'slow' is that when you run any java binary the virtual machine has to be loaded. So 'java HelloWorld' takes a second to run - which looks bad.
2) if the answer is yes, why? is apple going to remove 1.3 at some point, or are both required, kind of like a 'classic' enviroment for older java apps? or is 1.4.1 backwards compatible?
1.4.1 is backwards compatible. However it isn't a bad idea having both around. Developers (like me) find it useful - for example Swing was very buggy in 1.3 and has been rewritten, so it's nice to be able to choose versions.
Also, Apple are playing it safe. For packaged apps I think 1.4 is 'opt-in' - i.e. the default is 1.3, and you have to edit the info.plist to change that. (At least this was true in the recent developer previews).
One situation I had recently was my (bad) code whose behaviour changed from 1.3 to 1.4 because I forgot that 1.4 can return ipv6 addresses (which I'd forgotten; doh). It's backwards compatible, but that doesn't mean crappy code won't make silly assumptions.
Anyway, hope that gives you some explanation.
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
Interestingly, I chose not to write my current app in Java because of portability. It would actually be a lot easier to write it in Java. But the product is a small downloadable app that I want anyone to be able to trivially install on any platform. Now, I know I can count on having a JVM on the Mac. But I can't on Windows or Linux. I can't tell your mom that installation is easy... just grab this little app and then download a 20 Meg virtual machine, installed separately, through your little 28k modem. Even if she were to find the motivation and patience to do this, there is a good chance the install would get screwed up and there would be other issues.
So I've chosen C instead. I know that I can write C in a portable way so that it will be trivial for the end user to install on any platform. I have the division between OS specific code and general code well defined. So I can call the C backend from, say, Objective-C in the Cocoa environment. Or I can link it into a GTK+ front-end. It's more work for me than a Java app would be and I don't get the many advantages that Java offers to developers. But I just don't see any other realistic solution. Java's portability is largely theoretical in this world.
Devon
I first thought of this but realised the following:
I don't think it is a bad price to pay considering the performance of JAVA applications on OSX ... but your right it was annoying, I hate losing my uptime on the powerbook :)
So if your 1.3.1 app uses any Mac-specific functions, you may need to rewrite them for 1.4.1 compatibility. However, if it is bundled as a Mac OS X app, it will (as stated above) get 1.3.1 by default, so end-users will have no problems with any existing applications (that's the Apple Way).
The rules for whether you get 1.3.1 or 1.4.1 are:
command line:
You get 1.4.1 by default. If you want 1.3, you need to execute:(javac is in the same directory if you need the compiler or other tools)
btw I have no idea why there is a space in "Versions" above: if you see it, it shouldn't be there
double-clicked jar files:
You always get 1.4.1.
Mac OS X bundles:
You get 1.3.1 by default. How to specify 1.4.1 depends on whether the app was made with MRJAppBuilder (from the 1.3.1 Dev Tools) or Jar Bundler (from 1.4.1 Dev Tools). For MRJAppBuilder apps, add this line to YourApp.app/Contents/Resources/MRJApp.properties: For Jar Builder apps, in the YourApp.app/Contents/Info.plist file, in the Java section add a key called JVMVersion with a value of 1.4* (you can use the Property List Editor or a text editor).
All this and more is documented in the Release Notes.
Ivan.
Limewire is NOT compatible with 1.4.x at the moment, so it will actually revert to the 1.3 java installation, which, incidentally, is kept on your machine. Once limewire releases a 1.4 version, THEN we'll see some great improvements.
I installed and ran a perfunctory test of the new Java Runtime last night. I then fired up Robocode. I have a Powerbook G4 550, and in the past, I would see around 12 fps during the battles. With the new Java, I was seeing 24 fps consistently!
This is a great leap forward, IMHO.
"Smart is sexy." -- D. Scully ("War of the Coprophages")
Threw this together just in case anyone needed a
/Developer/Applications/JBuilder/JBuilder.framewor k/bin ./startJBuilder.sh
../lib -name *.jar`
o ut .name=JBuilder'
y st em/Library/Java/Extensions/MRJToolkit.ja r'
quick way to get jbuilder working from the
command line. I've only tested it with jbuilder 6.
Paste it into a file called startJBuilder.sh
or whatever and put the file into the
directory and do a chmod +x startJBuilder.sh. Then you can run it from there with a
Should work with any version of jbuilder and will use the default jre you have installed.
------------- startJBuilder.sh -------------
#!/bin/bash
JARS=`find
CP=.
for X in $JARS; do
CP=$CP:$X
done
DEFS='-Dcom.apple.mrj.application.apple.menu.ab
DEFS=$DEFS' -Dapple.laf.useScreenMenuBar=true'
DEFS=$DEFS' -Dapple.awt.showGrowBox=true'
BOOTCLASS='-Xbootclasspath/p:../lib/lawt.jar:/S
java $BOOTCLASS $DEFS -cp $CP com.borland.jbuilder.JBuilder
I use an old TiBook 400 that doesn't support Quartz Extreme, and line graphics in applets lost that beautiful anti-aliasing they used to have with Java 1.3. Sure, applets are faster now with 1.4.1, but I'd rather have a slower, good looking applet than this...
-- Free speech is only free if your time is worth nothing.