Re: [jos-general] [JOS Debugger Interface] Namespace

[Gilbert C. H. II <gc...@mi...>]

At 10:01 AM 5/29/01 -0500, Iain Shigeoka <iai...@ya...> wrote:
>I believe that if it is important enough, many of the versioning problems 
>cited by Gilbert could be handled via custom ClassLoaders.

How? Explicit versioning does not require a custom class loader. Implicit
versioning requires either the lastest version or a custom class loader for
each version. Every version of an API can be made available as a system
class, and should be. For our virtual machines which do not yet support
class loaders, class loaders are not an option. For off-the-shelf virtual
machines which do support class loaders, there are additional complexities
of making global references to classes defined by a custom class loader.

A well-known interface, in almost every case, must be a system class.
Different versions of the interface should be available simultaneously for
an implementation of an interface. If that were not enough, it is nearly
impossible to compile these classes with a class loader approach because a
custom class loader cannot be integrated into a javac tool. Which version
do you compile against? If you only compile against the latest version, you
can accidentally upgrade your application.

>However, its
>been my experience that most developers (myself included) would prefer to 
>not version by name to gain the potential benefit of "automatic upgrades" 
>with the known cost that you could break code in the process.

An "automatic" upgrade that breaks code in the process is hardly automatic.
It requires a technician to rework and retest all code that depends on the
new version of an API.

>This problem can be further mitigated by careful control of your classpath 
>which is a vastly superior solution because it moves the choice of what 
>version of a class to use to deployment and runtime time rather than 
>compile time.  If you lock yourself into a version in code by using a 
>particular class-version-by-name you are removing this flexibility from the 
>end user.

It is not possible for me to "control" the CLASSPATH of all my customers.
You're suggesting that it's a Good Thing for an application to work
perfectly with one CLASSPATH and not another. I don't believe that's a Good
Thing.

You might be thinking of implementation details. You might be thinking of
an application library. There are well developed techniques for providing
the latest implementation of a well-known interface. Of course, an
implementation is selected at runtime, not compile-time.

An API is always selected at compile time. You tightly couple your custom
package to an API, and should. Changing the API itself is hazardous. An API
defines well-known interfaces and base classes. An interface cannot be
selected at runtime. Neither can a base class.

>Finally, "experimental" code should be treated as such and I don't think it 
>is a developer's job to label themselves as experimental using 
>namespaces.  Version numbering schemes such as the Linux conventions or 
>external documentation (website or readme's) seem sufficient.  I think most 
>people that use experimental or code under heavy development are aware of, 
>and are willing to deal with changing code, deprecated API's, etc.  If they 
>are not, they shouldn't be using it.

Version of an API is meta-data. It should be available to both you and your
program. A program can't read external documentation. It simply breaks,
stops working. In the worst case scenario, it works for you but doesn't
work for your customer.

High quality software doesn't stop working--even when a new version of an
API is introduced. It is both rugged and robust. To borrow from Timex, it
takes a licking and keeps on ticking. I'm saying that, if API developers
did a good job, application programmers wouldn't have to deal with things
such as deprecation and serial ID. And, they wouldn't have to deal with all
the corresponding problems.

To be successful, a Java-based operating system must achieve the highest
quality possible. An operating system must be the most rugged and the most
robust. It is not possible to rework and retest every application that runs
on top of an operating system with every change in an API. An operating
system is not your typical application and its not your typical
API/framework. Your typical techniques won't work here. I have identified
some techniques which make a Java-based operating system feasible.

So you haven't tried it yet, have you?