Calling other code in Java applications and applets

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."

> 
> 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.)
This is correct. A class called the SecurityManager enforces this,
and it can be changed or shut off if one builds a custom version of the
classes zip file that has the appropriate changes to the security manager.
There was a posting to a java news group or mailing list about how to do
this a few months ago, I can find it if anyone cares.

Andy