(cherry-picked to fixAppleCommander/AppleCommander#13 since I've
discovered that I was wrong and it does fix the problem after all!)
cwa.storage.Disk.FileFilter was written for SWT, returning multiple
extensions as a single string with ; separators. For JavaFX, we
actually want individual strings separately or in a list.
The only place these are initialized in cwa.storage.Disk anyway, so what
I've done is change the class to instatiate with separate strings and
join them on demand for SWT. A new getExtensionList() method will
return them as-is for JavaFX.
My fix for the unchecked warning in AppleImage.java was completely dumb
and I had no idea what I was doing. My understanding of how this works
is now greatly improved and the bug I introduced in 292afd2 is fixed.
If you don't request a specific GUI, we try SWT and then Swing. Okay.
But if you do, we don't even try to see if it works—we just assume SWT
works. If the user requested Swing, we just unconditionally spit out an
error message and try to start the GUI anyway. Let's make the errors
conditional on the GUIs being unavailable.
Note, a Swing GUI is available. It is just incomplete and doesn't work
very well. :)
In order to actually start the SWT-based GUI on macOS and have anything
start, you need -XstartOnMainThread. This is a Cocoa limitation. If
you have that (and we do now), you can pass the -swt argument and it
runs. (More than I can say for Linux using the non-integrated SWT
provided by Debian at the moment…)
What doesn't work is the open dialog. No files are selectable unless
you tell it to allow all files, and then .dsk files which the cmdline
jar file can handle fine are somehow an unsupported format. Uh huh.
That much at least should not be too hard to fix. Whether it works
after that is fixed, I cannot say. What I can say is that the problem
does not exist if you don't pass -swt, however the lack of a proper
Swing GUI means it doesn't really matter because you can't do anything
with the files once you've opened them.
The macOS zip file already was automated (though it should really be a
separate target in build.xml), and I have added a note about the
possibility of using Sean Riley's appbundler fork as an alternative to
jarbundler and the universalJavaApplicationStub shell script.
I went with the stub and jarbundler because Oracle has had a bad habit
of regularly changing and deprecating Mac bundling practices, but the
bundling of a JRE should make that a one-click (well, one-doubleclick)
solution for the end user. If the GUI app *worked* that would be a
strong consideration. It's not even a waste of diskspace on a system
using APFS if multiple copies of the JRE are on the system, if they're
the same JRE.
Also noted that CF card access as a raw disk is possible on Windows as
well.
Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's
no need for droppings all over the build tree. Also cleaned up building
${maczip} a bit to avoid extra file copying, to put the uncompressed
.app in ${dist}, etc. Removed some cruft from .gitignore while I was at
it.
The conditional nature of building macBundle kind of bothers me a little
since if you have the correct swt.jar (which we could provide and have
in some versions of the build system), you could build self-contained
packages for macOS and for Windows. A self-contained package for Linux
is also possible, but doesn't make much sense as Linux software
installation routinely involves installing dependencies, either manually
or automatically.
Rather than trying to use the Eclipse plugin version (which may never
actually work without building using Eclipse), I've changed the default
properties to prefer the all-in-one swt.jar packaged for separate
distribution. That isn't going to make SWT magically start working (of
course not!), but it's got the best chance of us being able to MAKE it
work in the future.
I've elected to put it in /Users/Shared/Java which seems to be the
correct place to put such a thing, but elected to use an unversioned swt
symlink, set up like so:
/Users/Shared/Java/swt@ -> swt-4.7.1a-cocoa-macosx-x86_64
I'm using the current stable release version, as you see here.
Fixed all instances of warnings OpenJDK finds with -Xlint:unchecked.
Merging this will at least result in a dependency on JDK 1.5 or later
that I'm pretty sure of. But since the only JDKs that are really safe
to use these days are versions 1.8 and 9, that's probably okay.
No promises that this will make modern SWT work or anything, but it's
probably at least a beginnig toward that as well.
These presently don't work if you are using reasonably current versions
of JDK and SWT. Made this optional if you just run ant, but left it
enabled by default since it ought to be fixed. Linux build scripts may
just provide an ACBuild.properties that turns it off so that e.g., the
ant build helper doesn't need any custom configuration.
According to https://stackoverflow.com/questions/5103384, ant 1.8
introduced a "misfeature" of providing the ant runtime by default in the
java classpath. This causes some problems with reproducible builds,
which is why later versions have a warning not to do it.
The solution is to make the inclusion of ant.jar in the classpath
explicit. That's been done now.
This isn't significantly shorter than the first pass, but it's easier to
read and maintain. To add a new platform to this (if anyone wants to do
that), just add sane default paths to ACBuild-default.properties, add a
conditional to detect your platform, and add an init-platform target
that does the configuration.
There's a bit cleaner solution in ant-contrib using the if task, but
that means adding to the dependencies and therefore the complexity of
building this thing. I'm disinclined to do that.
Previously AC built onm Windows or not Windows (assumed to be Mac).
It appears there was a means to build using gcj, but this is not
necessary, does not work anymore as configured, and isn't what we want
anyway.
Here's a first pass at improving that situation. It's a bit ugly at
present because it requires a lot of markup to do something that should
be simple. Still, I'd rather do this in steps.
Okay, the Mac build at this point finishes and has all the pieces
correctly where they ought to be. However there is something wrong with
swt. I can't get any version of it I've tried to work. I can get the
app to start but the GUI doesn't work once you load a file. And the
only way it starts like that from the app bundle is if the line adding
SWT to the classpath of the bundle is removed.
However it's not SWT's jar itself since if you run the jarfile by hand
and add the same SWT to the classpath, it doesn't immediately crash. It
runs with the same GUI problem as if yu didn't specify it in the
classpath at all.
Something fishy is going on here. But it builds, so perhaps others can
assist in figuring out the nature of the problem. That's enough for me
to move on to the Linux build.
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".
