[2972] in java-interest
Dynamic libraries, security, and extensibility
daemon@ATHENA.MIT.EDU (ser@jersey.uoregon.edu)
Tue Oct 24 16:09:23 1995
From: ser@jersey.uoregon.edu
To: java-interest@java.Eng.Sun.COM
Date: Mon, 23 Oct 1995 23:49:53 -0700
In the throes of a sudden desire to have an attractive, predictable user
interface for HotJava applets, I sat down with a friend to write wrapper
classes for the Tk libraries. Surely, we thought, since the number of
platforms that Tk exists on is a superset of the number of platforms that
Java exists on, this would be a useful excercise. Having ignored all of
the discussion in this mailing list about dynamically loaded libraries we
began to peruse throught the FAQs, list archives, and documentation for
information. Well, after discovering what we frankly considered to be a
rather backwards way of accessing dynamically loaded libraries (write the
application first, and *that* defines what your library functions will be
called), we ran into a more serious problem: Java applets do not have access
to external C code, and with very good reason. There is a nasty can of
security risk worms that gets opened when you allow access within
distributable code to what Java calls "native" code. This has the rather
unfortunate and potentially seriously hindering side-effect of crippling the
functionality of Java.
Do we expect everyone to port their libraries to Java code so that we
can have access to the wealth of already implemented software that saturates
the world of computer science? Are we living in a pipe-dream? Tk is the
smallest of losses. Even if Tk, or some other well-defined user interface
toolkit gets co-opted by Java, it will only grow and improve so fast as
the Java Development Team works on it, and they certainly have too much
to do as it is. This problem is compounded by the shear number of libraries
that are, by the same token, lost to us. How about SQL, or compression, or
graphics libraries? One of the key places where Java was hoped to prove
useful is now being exposed as inefficiently handled: for every library on
your system, you have to have it twice if you want to use it with Java
applets. Its the lost law of code reusability.
This is A Real Bummer.
For the life of me, I can't see an answer. We can't simply allow access
to external libraries from within applets; what's to keep people from
using well-known and generally globally extant library function calls to
implement the very viruses that the nature of Java so cleverly denies?
But how can we live with a language which doesn't, in its primary
capacity as that of distributable software, support DLLs?
---
Sean Russell \ It's OK to judge a book by its cover,
ser@cs.uoregon.edu \ as long as you understand that most of
http://zebu.uoregon.edu/~ser ) the cover artists
Finger Me for PGP Key / have never read the book.
NeXTMail Welcome!!! /
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
