Calling other code in Java applications and applets
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."
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
participants (2)
-
Andrew Purshottam -
tcmay@got.net