[ Index ] [ Individual Project ] [ Placement Presentation ] [ Timetable ]

Week 5 - Status Report

Last Updated: 18th December 2001

Log

Meeting held with Susan on 04/12/2001
Conducted research on loading packages with the same name in Java
Contacted Shak about the troubles I'm having with JVCS
Attempted to contact Jonathan Cook regarding his 'Hercules' framework
Group meeting held on 06/12/2001
Meeting held with Susan on 07/12/2001

Meeting Notes - 04/12/2001

Discussed how my project was going and potential directions it could take. Went over what researched I covered, initial software design and how I wanted to do a frame work similar to the discussed in Jonathan Cook's paper as a possible extension. Also mentioned the trouble I had with getting Shak's project running.

Susan suggested I contact Shak about his project and Jonathan Cook to see if his research as progressed any further. She also wanted me to test to see how the Java classloader handles packages with the same name. Other possible directions for the project to take were a chain of developers adding to the library at each level and how a tool would help with it or multiple developers working with the library and contributed changes all back to the same place.

Chaining the tool at each level shouldn't be too hard a problem, but is it the best solution? I'm not sure about the second case since you probably only want one maintainer would deals with sources rather than binaries. Probably should talk to some people from aD about what they would want from such a tool.

Group Meeting Notes - 06/12/2001

Spent the entire meeting this week going over my project. Began with an outline of what I was planning to achieve and the way I was to go about it.

First part of the project would be having a JMX enabled system of upgrading binary compatible libraries. This was straight forward and I mentioned that I believed that by itself it wouldn't be enough for a good project.

Began discussing Jonathan Cook's Hercules framework and how I wanted to implement it on the client side to enable the client side developers to test for logic compatibility as well. In his paper he described how he implemented a basic version of the framework in Tcl and had plans to extend this to Java. I also made the assumption that if it could be done in Tcl then Java shouldn't pose too much of a problem. Others in the group pointed out a few holes in my plan.

The idea was to allow both new and old versions of the libraries to run in parallel, each call being sent to both via an arbiter system. The reason it worked with Tcl was that Tcl is an imperative language (or at least no OO functions were examined in the paper) hence each function call contains all the state information that is required. A method call on an object is quite different since it typically requires some sort of information held within the object. The obvious solution to this problem is to run two completely separate versions of the program, each relying on one of the libraries, this is flawed for a number of reasons:

Having the arbiter decide which library is correct can allow the program to continue execution even if one of them is wrong. The proposed solution would break after encountering a bug.
The objects might require an exclusive lock on some resource, e.g. it needs to use port 80. Therefore it would not be possible to run both versions.
Efficiency considerations must be taken into account. Running two versions of the program will be slow.
Any state information that exists in the running program will be lost since the program will have to be restarted.

A different approach would be to have the arbiter containing a dummy version of each classes in the library, so the state would be kept in one place, then maintains a reference to each version. The problem here is that the arbiter would have to be quite complex to be able to construct this framework automatically from any given library.

Another problem exists due to inheritance. What happens if a class in the running program inherits from a class in the library, how would the arbiter handle dispatching the method call?

Any possible solution, at the moment, appears to be quite complex and maybe requires some alteration of the JVM. My initial thoughts are that the scope is getting out of hand if I intend to have a working version early next year but, I don't know how I should proceed from here. I have contacted Jonathan Cook to see if he has made any headway on a Java version to see how he has dealt with the above mentioned problems, I'm still awaiting a reply. The other options are:

Reduce the scope of the logic compatibility end greatly, e.g. restrict it to static method calls (although this still might cause problems if they depend on some static reference to an exclusive resource).
Choose a different extension part (e.g. things discussed with Susan in the meeting on the 4th).

In the meantime I will finish reviewing the JMX specification so I can determine what I can do with it. I also need to hold another meeting with Susan to flesh out her ideas regarding having several levels of library developers and how binary compatibility problems can be solved there.

Meeting Notes - 07/12/2001

The main purpose of this meeting was to gain a tighter focus of what my project is about. The group meeting didn't go as well as it could, mainly due to the fact that I rambled about a possible extension rather than focusing on the core part of the project.

I talked to Susan about this and she pointed me to the various papers from the SLURP group regarding binary compatibility and dynamic loading, which are the key technology points in my project. For the time being I would scale back my rather ambition plans using a Hercules-like framework and consider them at a later date. A more sensible extension might be to attempt to dynamically upgrade the software while the program is still running, this has some of the problems mentioned before, but it might be possible.

Left this meeting having the better part of my confidence restored and a bulk of new research to look into.

Documentation Snapshot

Code Snapshot

None

Miles Barr <miles@milesbarr.com>