Re: Revisiting "lost codebases"

Hi Gili,

>         Can you please clarify which exact drawbacks you are referring to in
> section 6.2?

Not one in particular, I think you iterate them quite well. I was asking
for your motivation for solving type conflicts, is it that you run into
them that often that can't be solved in a suitable way that you want to
go into new (non established) directions of which the Warres paper
doesn't give me the impression in its conclusion it represents the
ultimate way forward.

Class loading issues are that mind boggling and overseeing all
consequences is so hard I'm rather hesitant to start thinking about
the consequences, but that shouldn't stop you to pursue it, the
contrary. I'm just a coward in a way I wouldn't undertake something
completely new when not initiated by the experts.

Personally I think the current mechanism with preferred class loading
works quite well, even in rather complex situations and I think there is
some room for small improvements for type compatibility introduced due
to preferred class loading semantics as explained in 5.4 of the Warres
paper.

>         Here is what I understood from reading section 6.2:
>
> 1) The "big happy class loader" solves type conflicts but has the
> following drawbacks:

As an aside I'm rather curious who came up with the name "big happy
class loader" as to me it doesn't represent one big happy class loader.
I actually wonder whether that name was meant to be sarcastic ...

For me the ability to have multiple versions of the 'same' class which
is possible due to preferred class loading has been rather essential and
sometimes even the ability to use static constructs. In a pub I would
have probably called it the "the communistic class loader" ;-)

>         Okay so here is where I stand:
>
> - I am trying to solve type conflicts mentioned in #1 automatically. I
> don't like the PreferredClassLoader approach because it requires manual
> intervention (specification of loading rules). It doesn't guarantee that
> it will work under all conditions and sounds a bit "trial and error"ish
> to me.

Here we differ of opinion. I like preferred classes, I think the
semantics are not that difficult when properly taught and while creating
a preferred list might seem daunting, I think there is proper tooling
for creating preferred lists as part of creating download JAR files [1].

Class evolution, specifying interfaces, the usage of classes versus
interfaces or abstract classes in your public API are all quite
important when designing distributed interface. That is manual labor but
doing it properly really pays off.

[1] not meant as an advertisement but with the Cheiron Ant download JAR
utility preferred lists are generated as a function of specifying the
classes part of your download JAR file. One can argue that having to
specify classes part of your download JAR file is already one step too
much. But in the end doing the (manual) step of specifying the roots of
your dependency check and inspection of the result (download JAR file)
gives you a good overview of the dependencies of your mobile code. Often
it resulted in cut-copy pasting some code instead of using one utility
method from a third party library dragging in 2 MBytes of other JAR
files.

> - #4: Under my approach a class is uniquely identified by its name and
> its version (sha1 of the bytecode) so the limitations mentioned only
> apply within the scope of each session. That is, within each session you
> can have at most one class definition per name, one set of security
> permissions for it. But you can have multiple Sessions per machine so
> you're still able to insulate "from the actions of competing versions".
> I think it makes perfect sense that the security permissions of a class
> definition are dependent on who you got those definitions.
>
> - With respect to #5 and #6 I retain the efficiency of "on-demand
> loading of class definitions" but avoid the problem of type
> incompatibility in the following way: When a node invokes a method he
> sends the class version (sha1 of bytecode) he sees on his side. I then
> verify that his version agrees with the version already loaded into the
> SessionClassLoader. If so then you have no type-conflicts because you
> share a single ClassLoader across uses of the same class regardless of
> which node it comes from (so long as they are within the same session).
> On the other hand if he has a different version of the class than other
> nodes in the Session then we "fail fast" telling him he cannot
> participate in the Session because his type conflicts with the Session view.

I haven't given it much though but I doubt whether a digest calculated
based on the bytecode is a proper mechanism for specifying a version of
a class. I'm no bytecode expert but I think you can have a 100%
compatible class definitions for which the bytecode can differ due to
different compilers, etc.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]