Re: Running AppleCommander GUI?

["John B. Matthews" <nospam@nospam.invalid>]

In article 
<0b0fea8d-4af9-4359-acc2-26cf16cd2d56@h7g2000yqa.googlegroups.com>,
 BLuRry <brendan.robert@gmail.com> wrote:

> 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

SWT is little extra heavy: it requires both a runtime JAR and a 
platform-specific JNI library.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>