[816] in java-interest
naming conventions
daemon@ATHENA.MIT.EDU (Ian S Eslick)
Thu Jul 20 19:35:54 1995
From: beethovn@ai.mit.edu (Ian S Eslick)
Date: Thu, 20 Jul 95 17:52:07 EDT
To: java-interest@java.sun.com
Cc: global-cc-dev@ai.mit.edu
Back to the package/class naming issue...
I've heard a couple of proposals/thoughts:
1) Sun's proposal, just have java packages be the global namespace
with a dot notation (like DNS) and enterprise specific domain.
2) A registry service by Sun or another organization to register top
level names NIC style. Especially as enterprise names don't cut it
for individuals...if Sun's vision for a world of portable apps takes
off this space will be hard to manage and DEMAND a registry
service...which could quickly fill up. What is Sun actually thinking
of doing, or are they putting off the issue?
3) George Detlefsen's proposal: piggyback the namespace on DNS and
have a 'javad' daemon at host sites serve .class files via TCP.
4) Jim Frost's objection to depending on remote sites to maintain
object coherency and consistency.
------------
So this has set me to thinking...
If I have my story straight, the model supported under Java for
program deployment is this:
Users on the net develop apps and then imbed references to them in
their HTML pages which get served to remote clients. The client
slurps over the page and gets the applets from the server too.
However, the way the classloader works is it looks in the classpath
for local versions of any referenced classes in the applet - so the
local configuration shadows remote clients. If it isn't local, you
grab it from the same server you got the applet (or top-level class)
from.
And in the grand view of the future, the world becomes a place full of
happy, portable applications forming a global computational framework
with "millions of Java applets" (Scott McNealy) providing services to
the Internet community.
Millions? Well first of all I have trouble believing that the current
package naming scheme is sufficient for a world with millions of
applets and tens of millions of classes. (Assuming Java is so wildly
successful:) Local sites might be doing development that conflicts
with applets coming across the Web, two people might develop the same
package and class name and then a third person imports one and the
applet based on the other fails. Long package names aren't all that
great because it's a pain to include long fully qualified names in
source code.
What happens when new feature versions of classes are released? What
if the interface needs to change at some point? How is re-propagation
of the updated code to be handled?
How about if I have two versions of the same code with different
performance features that perform differently on different datasets?
How can I gain the ability choose between one and another?
What if I have special hardware (Number cruncher or GigaOps style
board, etc) on my machine and I want to use a local native method
access to this hardware to do math instead of defaulting to the one
distributed with the dependant applets? How do I manage this except
by sticking classes by hand into a UNIX heirarchy? Ad hoc! Yuck!
I harp on this only because myself and some others have been working
on a framework for more automatic management of package/class
namespaces and a related version space.
What we'd really like to see is support in the class loader for a way
to be more specific about what exactly class of the referenced name an
author wants. Given a reference in a class file to a package.class
name, the import decision is made based on a unique tag which
specifies which version of this class the author really wanted to use.
I can then match this unique tag against my local environment to see
if I have a local version of that particular function I want to use.
What this does mean is we need some way of producing unique, ID's on
our package names. (It's still nice to keep package names separate
for purposes of development and reducing the cognitive burden of
keeping up with all the various different classes with the same name:)
So what I've tried to point out here is that we need:
1) A way of specifying a specific functional version of a class, even
beyond the package namespace.
2) A way of generating these identifiers so they satisfy many of the
requirements of URN's (location independant, longevity, etc)
3) A way of being smarter about deciding which version of a class to
use (local or remote) based on security and performance requirements.
Additionally, it would be nice to leverage the classes used to make
all these Applets. We're working on a database/library mechanism that
would provide this, plus automatic upgrades, distribution, unique
pointers and so on - with hooks for a Java style development
environment. I should have a nice white paper put together next week
sometime. If anyone is interested, drop me a line and I can put you
on our announce list.
Ian Eslick
Reinventing Computing
MIT Artificial Intelligence Laboratory
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
