Missed this thread when it happened...
At 10:33 AM 5/16/99 -0400, Stephen Martin wrote:
[...]
>So my question is this, given a fairly simple java app (ie no native
>methods, no rmi, no jdbc...). What is the best way for an end user
>to run it without having it hog all the resources on their system.
Depends on who your end user is... some of the code I write is "shipped"
as a handfull of classes (possibly in a zip/jar) with directions that
basically say "put this in your classpath and run 'java foo.bar.app'".
Those tend to be aimed at people like yourself who would know a classpath
from a capacitor.
Others are wrappered in a combination of shell scripts for the *n*x world,
bat files for win9* lusers, cmd files for the WinNT crowd and various
other forms for the more esoteric platforms (i.e. CL programs) they
all do one basic thing... reduce the command line:
`jre -cp tweedle.jar;neato.jar -ms2M -mx8M -Dchesire=smilling
com.corp.dept.applic arg1 arg2`
into
`applic arg1 arg2`
oh yeah, they also hide the fact that the user is running java
from all but the uber-geeks that go reading those scripts. :)
Which brings up another point, unless your application is targeted
to your fellow developers, use jre over java... not only are
you gaurenteed that if they have even a minimal runtime it'll work,
but (and someone please back me up or shut me up on this) I think
there is less overhead on the JRE runner than on the JAVA runner....
At 12:12 PM 5/16/99 -0600, Godmar Back wrote:
[...]
>100% pure Java. Those parts of Sun's libraries that are not 100% pure
>Java --- namely those relying on classes in sun.* --- don't usually
>work if they require native methods. They sometimes don't even work if they
>do not require native methods, but use other backdoor interfaces.
>For instance, sun.io.CharToByteConverter is a classical example for an
>undocumented interface implemented outside the Java API. Sun does not
>give you a way to implement your own converters.
The CharToByteConverter(s) are an implmentation detail of the sun.io
package, which is itself merely _one_implmentation_ of the java.io API.
I can tell you there ain't no rocket science going on in there....
It is fairly obvious that some developer within Sun whilst putting together
their sun.io package decided "ya know, it sure would be a good OO design
point to put all this here code page conversion crap into a set of objects."
and whipped up the CharToByte and ByteToChar class hierarchy to abstract
all that out of the rest of thier code. If in the process of creating your
implmentation of the java.io API you feel you the same need then by all
means toss one together, odds are you would spend less time creating one
tuned to your impl than you would addapting your impl to the way thier
conversions are coded. (not to say there is anything wrong with Sun's,
just that no designers would come up with the same non-trivial interface.)
On the other hand, if you want to use them yourself for whatever you're
writting . . . well I guess I'd have to ask why anyone out side of the io
implmenters would care what codepage they were in. Long live UNICODE! -=Chris
!NEW!-=> <*> cabbey at home dot net http://members.home.net/cabbey/ <*>
"What can Microsoft do? They certainly can't program around us." - Linus
-----BEGIN GEEK CODE BLOCK----- Version:3.12 http://www.geekcode.com
GCS$/IT/PA$ d(-) s++:+ a-- C+++$ UL++++ UA++$ P++ L++ E- W++ N+ o? K? !P
w---(+)$ O- M-- V-- Y+ PGP+ t--- 5++ X+ R tv b+ DI+++ D G e++ h(+) r@ y?
------END GEEK CODE BLOCK------
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
