Why on earth doesnt Sun...

WORA was marketing hype. The reality is considerably more fiddly. It would have been helpful if Sun shipped other tools in the JDK for shipping Java based products (other than Webstart, for example). It’s a bit of a pain having to fire up VC++ to create a .exe and NSIS to create the installer for Windows, and there’s actually a similar amount of hackery for OSX if you want to create a .app file. I should probably suggest an RFE to include tools that do this stuff in some future JDK release, or at least, as a separate tool download or plugin for the various IDEs.

Cas :slight_smile:

Eclispe is a bad example, they have written thier own gui library to replace swing that interface to C++ code if I recall. Thats not java’s fault, that was a developer decision within the eclipse community.

Having said that, if you want opengl 3D graphics, or OpenAL sound, or joystick support, you also need native libraries.

Endolf

You need a JRE to run your Java application. Webstart is included as part of the JRE. So anyone who wants to run a Java app will already have it. Unfortunately, there are problems with webstart too.

Azereus seems to do the same, just go to the download page, and you’ll be able to select from like 10 different versions of Azereus.
I also checked out Poseidon (uml editor) and it also does the same, different installer for each OS.

Have to disagree that the Mac solution is “similar” in any way. There is no compiling of anything, no making of any installer. It comes down to creating a specific directory structure and providing an XML file… much like a JNLP file.

“Java” “Application Bundles” are really not significantly different than any other Mac Application Bundle. The whole concept of the Application Bundle is the critical bit the the other OS’s lack.

The user experience on the Mac for launching or installing a native app or a Java app is the same on the Mac. i.e. Drag the app to where I want it. Double click it to start.

Though all the whining about windows seems a bit dumb to me too… MOST Windows applications have an installer. Making one for a Java application is no different. What people are really complaining about is lazy developer practices where platform-specific installers are not created to match the expected user experience for a particular OS.

Web Start is a cross-platform generalization, and will ALWAYS feel like it, because you simply don’t install software that way for “native” applications. The only real things to improve are how the question is asked about the shortcuts. It should probably just say “Do you want to install this application, or run it from the Web?” If the user choose to “install” then they should get the same sort of choices that they do with other installers for the platform they are running on, i.e. choose a folder to put the app in, default for Windows being “Program Files/blah” (where the details of “blah” come from the JNLP), Web Start will then simply put a REFERENCE in it’s cache to the local install folder for that app, and not HIDE all of the installed applications like it currently does, unless the user chooses “run from web” in which case the application is put into the private cache (so the next “run from the web” can go faster, or the app can be launched from the cache viewer (which no normal user will EVER see), and no shortcuts are created.

probably simply, because users are used to download a different version for each OS. Else they think it’s wrong or something.
But actually it is not difficult to create all those different launchers. If you write a simple shell-script for example, you’ll only have to change the “:” in a linux-shell script to a “;” to make it run under windows.
And if you want to attach an image, hide the shell-script somewhere and create a link :wink:

If all you want to do is make your java app look like a windows application, why not simply use one of the existing exe wrapper tools (like launch4j). That way you get a nice icon, an exe, etc etc.
If you’re application consists of more than a single exe, then the ‘correct’ way on windows is to make an installer, which is no different than if you were writing a native appication. There are already plenty of free and commercial tools available to do this, so I personally don’t see why Sun should invest time and money in this.

So what are all those little magic gubbins in the .app structure that I have no idea how to generate myself? The xml bit I can get my head round but it’d be nice if the JDK had some tools to make all that stuff for me. Modern world and all that.

Cas :slight_smile:

[quote=“princec,post:28,topic:25756”]
As far as I know all that is needed is the correct directory structure, an Info.plist file and the executable of course.
Cfr. Anatomy of a Modern Bundle
One possible ‘magic’ file is PkgInfo, but that one is not required and also documented

Right… and that “executable” is not something you compile… it is the JavaLauncherStub that is provided with the standard Mac dev tools. Essentially it is like javaw.exe.

The other thing that might be hard to get without a Mac is the .icns file that contains the icon for the application bundle. If I knew the format of that file I would write a tool to build these app bundles in pure java…of course you are basically saying that Sun should do that. If they had a tool that would make an “OS integrated” application so that the user experience was more along what the user expected it would help. Instead Sun is doing the more general,but MUCH harder thing of introducing a new application format (Web Start) and hoping that users will get used to that. (Good Luck!)

Someone beat you to it :wink:

IIRC Azureus uses SWT as well.

Seems that goes in the other direction. Takes Mac Icon files and gets the imgae from them. It’s also all about resource forks, which aren’t used much anymore on the Mac. I don’t think the icon in a Application Bundle is contained exclusively in the resource fork an icon file- not at the Mac now to check.

Anyway, thanks for pointing it out. It could be a good starting point for making a pure Java version of the apple “Jar Bundler”

I’ve been digging through Apple’s documentation and it seems that the contents of a icns file is identical to the contents of a icns resource fork. In other words icns file == icns resource in data fork.
I pointed to that program because it already contains decoders for icns and the other mac icon types. The only problem might be the license on the source code (QPL).
The best approach of course would be to find the spec for the icns format. Supposedly it’s hidden in one of the old ‘Inside Macintosh’ documents, but so far I haven’t been able to locate it.
From this article it seems that Rez (the resource compiler) should come with a bunch of headers that define the structure of these resources. I don’t have my mac with me here, so I’ll check once I get home.

Not any more.

You can ship pre-loaded webstart cache.