[1564] in java-interest
Java and namespace management
daemon@ATHENA.MIT.EDU (Ian S Eslick)
Fri Sep 8 01:06:28 1995
From: beethovn@ai.mit.edu (Ian S Eslick)
Date: Thu, 7 Sep 95 21:34:39 EDT
To: java-interest@java.sun.com
I haven't written about the namespace issue in awhile - been in and
out of town. However, here's a strawman proposal that I recently
mailed to a friend.
I articulated my primary gripes in a previous message to this list
which I'll repeat here to provide some context:
------------------------------------------------
> 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
--------------------------------------
So these are my current thoughts on an alternative methods for Java
namespace resolution. Some of this discussion assumes basic knowledge
of the GlobalCC framework and computational model.
Current GlobalCC proposal information can be found at:
http://www.ai.mit.edu/projects/transit/gcc-www95/GlobalCC_White_Paper.html
and
http://www.ai.mit.edu/projects/transit/tn111/tn111.html
Argument 1)
Path lookup resolution in Java by local then server is dangerous. The
correct execution of an Applet or application depends on the path
being right and there being no name conflicts. Even with packages,
namespace conflicts are likely since organizations aren't good
structures for individual authors who may potentially create category
classes rather than organization classes - assuming no one steps in
and manages the namespace directly. This is mostly a sociological
issue, but an unmanaged namespace is guaranteed to have problems.
Argument 2)
Specifying code is difficult. Names don't mean much since you might
want several pieces of code to reside under the same name. Variants
in performance and functionality occur frequently and often one wants
to use an old name to describe the same functionality with slight
revision.
This is also an issue in incremental code development (encouraged by
Java's dynamic binding, etc) that code will sometimes be modified, but
what happens when you want to use an older version?
------
Proposal:
Attach an ID to each Java class file to provide specificity - that is
to differentiate versions and varients of classes that use the same
class name.
Why do this? An ID serves to:
A) Allow programmers to specify exact expected semantics by referring
to a specific implementation of a particular name. This is useful
both for allowing evolution of code through successive versions as
well as keeping name conflicts from being unresolvable.
B) Can also imply a lookup scheme for finding(*) the class
* - No object can be guaranteed to always exist in a global and
distributed environment. Local caching is the only way to provide a
true guarantee. However, no one can really guarantee that the root
DNS servers stay up - redundancy and reliable servers are necessary.
These types of services should be obtainable from corporations and
universities.
The class binding mechanism is changed to use the following scheme:
1 - If it's not a native package (java.lang, java.io, etc)
a - Look up the class _identifier_ locally (see if you have a cached copy)
b - Look up the class _identifier_ on the remote server
c - Use a global resolution scheme (URN style, GlobalCC style)
2 - look up the class _name_ locally via path
3 - look up the class _name_ on the remote server
The lookup method is determined by a java class that is named in the
root of the identifier. The class name of the resolution class is
looked up in the traditional manner - a server using a different
scheme must provide the resolution class or depend on no conflicts
between the client path namespace and the server namespace. (unsure if
this is right - first pass strawman at bootstrapping the scheme and
retaining flexibility)
A strawman resolution scheme uses the Global Cooperative Computing
model of unique ID's. That is currently a hack which uses structured
URL's and depends on a local or global code server to be accessible
in order to contain a copy.
ID looks something like this: <resolution_class_name>:<UID>
or in the case of the GlobalCC model
globalcc1.0://www-codemaster.ai.mit.edu/db/java/java/lang/String/source/1.0
something along those lines...
2 - Generating ID's
A resolution scheme will have it's own method of creating unique ID's.
Using a GlobalCC server makes this easy as it uses local URL's to form
the uniquness for now. Portability is a problem but I don't want to
solve all the URN/URI issues right now. We can overload globalcc1.0
so it uses the old Java name lookup scheme first and upon failure goes
to a URN service which encapsulates the old namespace and/or uses an
index to find the current URN.
Now if I compile a class locally and want to assign a specific ID to
it so resolution happens to my local copy or to my servers copy, then
I (the compiler) can pretend to be the local globalcc server and use
my DNS address and the name to form the ID. Yes, it's a hack, but it
works in most cases and you aren't going to get the versioning and
control you want unless you buy into a globalcc style system and I
don't want to demand that up front. (Tradeoff's are a pain!)
----------------
Here's a rough stab at an alternative proposal. If you have comments
on this or the GlobalCC paper, I would appreciate mail - especially
from folks working on URN/URI proposals as I'd like to see how this
fits in. Eventually I'd like to replace our ad-hoc scheme (which can
be as reliable as DNS) with a W3 accepted URN resolution scheme.
Ian
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
