From: tcmay@got.net (Timothy C. May)
Date: Tue, 30 Apr 1996 17:03:49 +0800
To: cypherpunks@toad.com
Subject: Calling other code in Java applications and applets
Message-ID: <adaadb06040210042638@[205.199.118.202]>
MIME-Version: 1.0
Content-Type: text/plain


At 11:22 PM 4/29/96, sameer@c2.org wrote:
>>
>> Java applications can't save files to disk or use data files on
>> disk.
>
>        Uh, yes they can. It's the applets that can't.

And I believe that even applets can read and write data files on disk IF
THE APPLET ENVIRONMENT PERMITS this. Netscape and similar environments at
this time of course _don't_ let this happen, but this is a choice (as I
understand it) made at this time and perhaps for this version of the
respective pieces of software. (As I understand it, an explicit decision
not to allow file i/o, for some obvious though not necessarily permanent
reasons.)

Certainly the InputStream and OutputStream classes handle file i/o for Java
applications--if not applets in general, and presumably not with Netscape
2.0. I can imagine future developments which will allow browsers or similar
environments to have full file i/o capability. (Sure, there are dangers.
There are always dangers in running code gotten from others. These are
recurring problems. I expect lots of flavors of solutions, from signed
classes to "playpen" holding tanks (which allow file i/o, but only within
some constrained environment), and so on.)

By the way, I had a discussion at a party with several Sun folks and other
Java programmers, and they agreed that external code (C, for example) could
be called, even by an _applet_, if arranged. For example, various
underlying graphics routines in the AWT (Alternative Window Toolkit)
package are of course using underlying code written in various other
languages, code that has been reasonably optimized for speed.

"import java.awt.*" makes this code available to applications, and (I
believe) to applets within Netscape-type environments.

(I suspect there's a simple chart someplace showing what will run under
what constraints.)

The interesting thing here is that a crypto package, perhaps with
speed-optimized underlying routines in C or even hand-coded machine
language, could be released. It might be that patent holders (not that I am
endorsing this) could license such packages to users.

Thus,

import java.bignum.*
import.java.entropy.*
import java.rsa.*
import java.digicash.*
...

(Such packages may need approval by Sun, etc., and formal integration, a la
AWT. But certainly there is talk of replacing AWT with something else, so
changes and additions are clearly possible.)

Lastly, I don't believe that discussing the implications of Java justifies
the claim that "males are posturing." To me, discussing Java, virtual
machines, security issues, and advantages/disadvantages is what the list is
about, at least as much as the other topics we so often discuss.

--Tim May

Boycott "Big Brother Inside" software!
We got computers, we're tapping phone lines, we know that that ain't allowed.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Licensed Ontologist         | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."