Commit Graph

5 Commits

Author SHA1 Message Date
T. Joseph Carter
d37ba47c8d macBundle: some cleanup, remove .app skeleton 2017-10-30 08:12:16 -07:00
T. Joseph Carter
2e2a34e77e mac: Use universalJavaApplicationStub
Here's a (very rough) implementation of a macBundle task using the
universalJavaApplicationStub and jarbundler.  Jarbundler's support files
(ant build system and docs) are suffering bitrot, and I don't grok maven
yet, so I'm really flying blind with it, so basically I'm committing it
in a "baseline" working (if ugly) state.

So ... _why_ use this?

The old way of bundling Java apps doesn't work anymore.  It tells you to
get Apple's (compromised/unsafe) Java 6 and when you do it throws an
error because your code compiled on Oracle JDK 8/9 won't run on it
anymore.

You're supposed to duplicate the JRE in each Java program you bundle as
you would a private/custom framework.  Yes, really.  This solves the
dependency issues at the cost of heavy resource waste.  Except every new
JDK generation changes HOW you do that, and the current method is
totally proprietary to Oracle's JDK.  For cross-platform development, it
is NOT fun.

So there's uJAS, which is literally a complex shell script to magically
do the equivalent of typing java -jar <your program> from the command
line—which does work BTW if all your dependencies are properly in your
default classpath, etc.  There used to be a couple of application
bundler options, but the one that still works (only with uJAS if you
have the most recent JDKs), is jarbundler.

TODO: Clean this up, restore original functionality (zipball), include
the commandline jar, etc.

committing it in this state is that jarbundler's repo is a bit of a
mess.  The current version (and the version we need) is 3.3.0, the
"latest" from 2015.  The docs, examples, and the ant build system are
all literally bitrotting from version 2.x, and do not work without some
fixes.

So in other words, I'm committing this in a state that I got to work so
that if I screw it up, since I'm flying blind, I'll have a messy but
working fallback.

Okay, so _why_ use any of this at all?

If you create an ACBuild.properties file and run ant, you can get
AppleCommander.app to build, but it won't run.  It tells you that you
need to download Apple's legacy Java 6 which is neither safe nor
supported anymore.  If you install this, it will still give you an
error because the generated code can't run under Java 6.

What you're supposed to do now is bundle your JRE with every Java
application bundle, which means multiple copies of libs on disk and in
memory.  Yes, really.  Except Oracle keeps changing how you do this with
each new JDK generation, and the current way is pretty much totally
proprietary so that you're locked in to Oracle's JDK and couldn't use
OpenJDK or something if that were an option.

That's what universalJavaApplicationStub resolves—it builds an app
bundle that uses whatever JDK/JRE you have installed from 6 onwards.
And it in turn needs jarbundler or something like it.  Except all of the
"something like it" solutions are dead or deprecated save the latest
release of jarbundler which was modified to support uJAS and then
promptly left more or less untouched since.  But it "works".
2017-10-30 06:14:13 -07:00
John B. Matthews
d88fc632bf Add new Mac jnilibs. 2008-06-08 15:15:04 +00:00
a3aa3ff871 Ignoring build artifacts 2008-06-06 19:50:01 +00:00
John B. Matthews
058608b124 Add Mac application bundle; cross-platform build. 2008-05-24 03:37:01 +00:00