Re: Running AppleCommander GUI?

[BLuRry <brendan.robert@gmail.com>]

On May 26, 11:35 am, schmidtd <schmi...@my-deja.com> wrote:
> On May 26, 10:52 am, Steven Hirsch <snhir...@gmail.com> wrote:
>
> > First, a disclaimer:  I do not like Java.
>
> Yes, yes.
>
> > Does anyone know the magic incantation for getting the GUI up on Linux?
>
> There's a reason Rob bundled AppleCommander into an executable on
> Windows and an app on Mac.  And there's a reason why I hide the Java
> command line of ADTPro behind a script for Unix-alikes.  It's
> complicated.
>
> First, give full qualification to the jars you need.  The classpath,
> or -cp command line switch will do that for you:
>
> -cp /usr/lib/java/swt-gtk-3.5.1.jar:/wherever/AppleCommander-1.3.5.jar
>
> But then you also need to pull the main class out of the manifest;
> that is: com.webcodepro.applecommander.ui.AppleCommander
>
> Then, there are some native libraries for SWT too, aren't there?
> There are on Windows and Mac.  For those, you need to give the -
> Djava.library.path= command line switch, and point to those, too.
>
> So I can get you as far as that - there's still the issue of 64-bit
> SWT native libraries, which I trust you know where are.  A full
> invocation might look like this:
>
> java -Djava.library.path=/path/to/SWT/jnilibs -cp /usr/lib/java/swt-
> gtk-3.5.1.jar:/wherever/AppleCommander-1.3.5.jar
> com.webcodepro.applecommander.ui.AppleCommander -swt
>
> (I'm unsure if the -swt switch is passed in - or if Java will consume
> it.)

I've been doing some experimentation with dynamic classloading to
improve on apple game server -- and on a similar note this is why I
try very hard to stick with the out of box JDK classes to avoid jar
file hell.  With the dynamic classloader, you have a main class that
is just a bootstrap, maybe displays a fancy splash logo (oh that's so
late 90's) and meanwhile search the current path as well as known
system paths (maybe a maven repository, or in *nix the /lib folder)
for jar files and, if using native libraries like RXTX, dynamic
libraries.  Once you locate everything, you programatically build the
classpath and fire off the main program in a new thread, passing it a
custom classloader with the list of paths added to it.

This has some nice advantages for the user, in that they don't have to
type a long commandline.  You can also print friendly messages when
you cannot locate a required dependency that make more sense than the
"class not found" exceptions.

A simpler but less elegant solution is to add manifest entires to your
main jar file that specify these dependencies outright.  It won't help
with native libraries (like rxtx) but could help if you're using, say,
apache commons or jaxb.

http://onjava.com/pub/a/onjava/2005/04/13/dependencies.html

-B

-B