[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Java and arch

From: Mark A. Flacy
Subject: [Gnu-arch-users] Java and arch
Date: Mon, 20 Oct 2003 00:32:34 -0500

>>>>> "Charles" == Charles Duffy <address@hidden> writes:
Charles> I'm not sure that "run anywhere" is *nearly* as interesting as a
Charles> sufficiently solid implementation of "compile anywhere"... heck,
Charles> any Java-based arch implemenation I happened to be using would
Charles> almost certainly be native-compiled via gcj to avoid JVM startup
Charles> time, so why not have a bit more of native code in there too?

Well, in my job I'm part of project whose Java code runs on Solaris, MS
Windows NT/2K, and Linux without change[1].  In fact, I compile our entire
code base on my Linux desktop and other designers use the resulting .jar
files to run the code base on their desktops and the Solaris based lab

So "compile here, run everywhere" is an exceedingly desirable
characteristic in my worldview. 

Charles> Heck, if gcj is the target compiler, that means the native code
Charles> can be using CNI -- so it'd be short, readable native code rather
Charles> than the opaque trash that is JNI... and of course by the nature
Charles> of not being Java, it's all kept in one place and nicely separated
Charles> from the platform-independant code. I'd hazard that it'd weigh in
Charles> under 80 lines per platform if done right.

Umm hmm.  Of course, don't forget to add in the meta data in the source
tree for those platforms that don't support user ids, group ids, permission
bits, and symlinks on those platforms that don't support those things.  As
well as tla commands to manipulate such things.

Charles> So no, I'm not sure that a Java version of arch is an inherently
Charles> Bad Idea, or at least not for the reason above.

I don't think that a Java version of arch is a Bad Idea, but I *do* think
that your vision of such a thing is hammering a square peg into a round

If you are going to write something that requires glue code, then you might
as well pick a language that supports what you are attempting to do.
Python would be a good choice, IMO.  Even Perl would work, even though the
very thought of such a thing makes my skin crawl.  (We all have our
foibles; I happen to hate Perl.)

[1]  There is client code that was written using dll's for multimedia
     support.  Since I run Linux on my desktop rather than Win 2K, that
     means that I can't run the client.  That still leaves me with over
     10K java files that compile and run without modification on those 3

 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 are, ummm, facts.
"Maybe at a Seven-Eleven, maybe at a quick carjack.
 You'll verify there ain't a heaven if you don't keep the hammer back."
   - Blue Oyster Cult

reply via email to

[Prev in Thread] Current Thread [Next in Thread]