Max,
In the JOSCore project work I've been doing, I've done some thinking in this
area.
As part of the installation process, each 'Program' would get a series of
entries in the JOS Registry. Among these entries would be packages and
versions of those packages that the program relies on. If none were there,
JOS would assume to use the latest versions. Do to the multiple-primitive
ClassLoaders and other ideas we will one day implement in decaf, each
process can have a different version of class libraries, even if two or more
processes are using different versions of the same class.
In order to make this all work, a lot of things need to be very well
integrated. The ClassLoading process will rely on the Registry, and since
Security will rely on the ClassLoading process, the Registry will need to be
quite secure. (The Registry willl likely be the weakest security link in
JOS.) All of this also means that there is a need for some kind of a
ClassRepository, which keeps track of package versions. That begs the
question: can we allow classes to be placed anywhere they want on the
filesystem? Or do they need to be a central place? How we answer that
question is going to have a huge effect on the installation process.
It is a lot of code to write, and all I have so far is really a skeleton of
some of the core interfaces. I'm starting to get back to work on it,
though. Anyone want to volunteer to write a ClassRepository? :)
Regards,
Avery J. Regier
> -----Original Message-----
> From: Max Gilead [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, November 12, 1999 6:16 PM
> To: JOS General group
> Subject: [JOS] JDK incompatibility solutions
>
> Hi, all!
>
> I have read JOS mailing lists archives. On UI group there were a thread
> some time ago about this. Although I think that making different JDK
> releases fully compatible (even if only backward compatible) would be a
> very useful thing but I doubt this will happen soon. The bad thing is
> that JDK is so monolithic piece of software. It would be much better
> IMHO if instead of one JDK we would have separate libraries - eg.
> Utility library, AWT library etc. It's just an example and I'm not sure
> but security issues of JDK1.2 rather don't affect AWT ;-), am I right?
> So why release it in one piece? If it won't happen the whole system
> would be more flexible. But these are just my wishes :-(. Even libraries
> for languages that are on market for much longer than Java, for example
> C++ are undergoing changes, sometimes breaking any compatibility
> (libc<->glibc change in GNU libraries, recent change in C++ specs which
> causes many problems with compilers).
>
> These are my thoughts about possible solutions to problem with
> incompatible JDK releases:
>
> 1. Static linking.
> Let's take a look at C++ applications (I'm talking about such basic
> things to make me clear). They can be dynamically or statically linked.
> Dynamically means that they use some external libraries, in fact a
> specific version of these libraries. They are smaller than statically
> linked versions but suffer from possible incompatibility problems.
> Statically linked applications does not use external libraries - they
> have all of them compiled into executable file.
> In Java, all applications are 'dynamically linked'. Possible solution is
> to package classes it uses with program. But this is not possible for
> native classes and doesn't solve VM incompatibility problems.
>
> 2. JDK for JOS (much better solution)
> Some people think that JOS should mimic JDK. I think it should not (at
> least not its core). I think that JOS core should provide VM to run
> bytecode and its own hardwired system classes (jos.org.* and below?) -
> that's all. This way it would be possible to run applications compiled
> for different JDKs (even ancient ones) without any problems. Which JDK
> to run under could be choosen from some property panel or detected at
> runtime(?).
>
> Incompatibility problem can be breaked into two smaller problems:
> - VM incompatibility.
> As VM functionality is provided by system, system should have
> possibility to run applications in different VM versions. It would not
> be a problem since VM changes should be very rare (I hope :-)
> - Core classes incompatibility.
> As JDKs are mostly backward compatible, providing older class library
> would require substituting incompatible classes only. Say, application
> was compiled for JDK 1.1 and current standard JOS classpath is 1.2. So
> an imaginary classpath would look like:
> ./application.jar:/classpath/ver1.1.jar:/classpath/ver1.2.jar
> As JOS is a _Java_ OS I think that native classes problem would go away,
> too, as they could be implemented as JOS system calls in Java.
> Easy enough, I think. And very flexible. If user doesn't want to run any
> older applications, he does not install compatibility libraries. But he
> may do so at any time.
>
> These are just my thoughts, so let people criticise (or express awe ;-)
>
> Bye,
> Max
>
>
> -------
> -- Max Gilead ([EMAIL PROTECTED]) ----------
> | http://3d.linart.krakow.pl/OfficinaArtificialis |
> ---------------------------------------------------
> {EOF}
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> General maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/general
_______________________________________________
General maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/general
