New technology in the latest JVMs allow you to share classes between JVM processes. As a result, the shared classes need only be loaded into memory the first time they are to be used, thus eliminating the fixed cost of having to load them in each subsequent JVM invocation, as well as reducing the memory footprint cost in each of the JVMs.

Summary

Java applications face a problem today: The only containment vessel available to them is the Java virtual machine (JVM) process itself. Multiple JVMs are required to isolate Java applications from each other, and this has two major negative impacts. The first is the start up time involved for each JVM invocation; the second is the memory footprint required by each JVM. Given these costs, and the inability to isolate applications within the JVM, it is clear that something fundamental needs to be done to resolve these issues. The answer? Shared classes. In this article, IBM Java Technology Center Development Team members Lakshmi Shankar, Simon Burns, and Roshan Nichani discuss the concepts behind shared classes in JVMs, how they work, and how this technology could potentially be exploited by users. They also discuss some of the current implementations of this technology and how it may be further exploited in the future.

Read Java shared classes: Learn how to start your Java applications faster and with a smaller memory footprint

Effectively this approach is limited to what we currently call "the system class path". Using a sharable class loader as discussed in the article is not very likely to be a good idea, if various application are using different versions of the same library, which is quite a common feature.

In the server space it is currently only important if various instances of a j2ee server are run on the same box. Also, normal j2ee apps take a lot of resources for the actual application, deployment etc, rather than for there system classes.

It could be a nice technology for client applications that can keep all basic libraries in memory though.

as u can call a class from another VM ..?? no more messy stub skel hell ?
or does it have to be a VM instance on same ???

No, it doesn't affect RMI. The technology described herein
is pretty much invisible to the semantics of Java. It's
purely an optimization technique, designed to make Java
run with less memory and/or faster (the two are related,
of course) when you are running more than one JVM under
the same operating system. Other than performance,
everything else is the same.

Though it would be cool if jvms could implementa distributed shared memory protocol on selectedregions.

have a look at jini & especially javaspaces

--Calum

IMO: Classloading in Java has very-very-very bad implementation because:
1st - Classpath variable does not make much sense because Classloaders are free to load classes from where they are pleased.
2nd – Classloader _instance_ being part of class name breaks Java language semantic: instanceof returns false even debugger shows that instances belong to the same class. It is kind of unnamed namespaces.
3rd – There is no way to know what classloader to use to get a resource: current thread classloader, class’s classloader or what;

On the topic: experimenting with classloading might be a step in a right direction.

4 two or more different versions of the same class can not be used by the same application. Probably nobody uses classloading hacks and reflection to solve this problem and I think nobody is happy to rename classes or to maintain backward capatability manualy for this reason.

IMO: Classloading in Java has very-very-very bad implementation because:1st - Classpath variable does not make much sense because Classloaders are free to load classes from where they are pleased.2nd – Classloader _instance_ being part of class name breaks Java language semantic: instanceof returns false even debugger shows that instances belong to the same class. It is kind of unnamed namespaces.3rd – There is no way to know what classloader to use to get a resource: current thread classloader, class’s classloader or what;On the topic: experimenting with classloading might be a step in a right direction.

(1) Classpath variable makes sense because it provides one, convenient but limited, way of specifying where classes should be loaded from.

(2) A class must be qualified by the loader that loaded it because it would otherwise be impossible to load two versions of the same class definition twice in the same JVM. It is a feature - not a bug. It is one of the key features needed for application servers to work as a concept.

(3) Dont see your point. If you dont understand from where to load the class, then you should probably refrain from using dynamic classloading altogether.

> experimenting with classloading might be a step in a right direction.

Yes - go a head and experiment.

Br - J

(1) Classpath variable makes sense because it provides one, convenient but limited, way of specifying where classes should be loaded from.

Consider classpath like this: /my/dir:http\://some.server.com:rmi\://server:etc.

(2) A class must be qualified by the loader that loaded it because it would otherwise be impossible to load two versions of the same class definition twice in the same JVM. It is a feature - not a bug.

I never said it is a bug. It is poorly implemented feature that breaks language semantic.

It is one of the key features needed for application servers to work as a concept.

I would probably agree, but I am not so sure that it is the right way to do it. IMO: application server concept is somehow wrong one because it attempts to build yet another OS atop of JVM (which is OS) that runs atop of ‘native’ OS which in turn might be a virtual one too.

(3) Dont see your point.

I suggest spending more time with application servers and I am sure you will know exactly what I am talking about.

Before introducing this kind of features I think that Sun and others should introduce versions in java. It will help us to avoid Java Hell : (http://www.ssw.com.au/SSW/Database/DLLHell.aspx).

Versions are already implemented in .Net.

Before introducing this kind of features I think that Sun and others should introduce versions in java. It will help us to avoid Java Hell : (http://www.ssw.com.au/SSW/Database/DLLHell.aspx).Versions are already implemented in .Net.

It was implemented in COM decade ago too, DLL hell is produced by programmers not by Windows design.

It was implemented in COM decade ago too, DLL hell is produced by programmers not by Windows design.

In COM someone can run regsvr32 on a dll file and that will break your application. I was never aware of any versioning feature whereby you could notify COM subsystem to only load your version of class name.

Tim

In COM someone can run regsvr32 on a dll file and that will break your application.

You need to do something very tricky yourself to break application with regsvr32,
COM is desined for any language and it can not solve all problems, but it is very trivial to solve versioning for JAVA. Doe's JAVA architects think versioning conflicts with "JAVA philosofy" like evil "procedure pointers" ?

I was surprised to hear that people are using Java under CICS, in a way
that requires a new JVM to be started up for each CICS transaction! No
wonder IBM is particularly concerned with making JVM startup time fast!

However, I don't mean to rag on IBM here: there are plenty of other
benefits to be had by making JVM starup fast. For example, if
you want to implement something that looks like a Unix or Windows
command, and you are thinking about writing it in some given language,
if that language has a long fixed startup time, you'll think twice
(greater values of "twice" for greater values of "long", so to speak).
This issue has, at various times, been faced by Perl and Python and
other languages as well as Java.

It would have been interesting if the article had gone into more
detail about exactly what operating system functionality they were
utilizing in order to make this work. The feature works only
on the "z/OS" operating system. I am not quite clear about what
that is, and what hardware it runs on. I think maybe it only
runs on computers whose architecture is what IBM used to refer
to as "System/370"; perhaps someone knowledgable about IBM
operating systems and hardware could clarify this. In any
case, what I'm really curious about is how easy or hard it
would be to make these Java implementation techniques work on
other operating systems, such as Linux or Windows.

BEA's JRockit has a shared class feature. I don't know much about it.
I think maybe it's more or less like the Apple one described in the
article, but I could be wrong.

At the risk of exposing myself as some sort of dinosaur

z/OS is basically the sucessor to MVS.

Basically we had MVS running on S/370 hardware, os/390 running on S/390, and now z/OS running on zSeries hardware. As you say all just the modern equivalents of s/370.

From what I understand it is only IBM's JVM implementation that is running on z/OS. Sun are producing a class sharing JVM for multiple platforms (Solaris, Windows, Linux) but at the moment this will only allow for sharing os standard system classes.

IBM has been working extensively to create something called a reusable JVM. This JVM is capable of isolating read only data, for example, and not throwing it away... in case it is needed again, aka shared classes.

This JVM is called the Shiraz JVM and has been available for CICS for some time. It was only a matter of time that this technology bled into the main Sun JVM efforts.

In the IBM Shiraz JVM there are 2 levels of entities that can potentially dirty the JVM and cause those entities to be reloaded on a subsequent JVM startup.

This is based on knowledge 18 months old so who knows hwo far they have come now.

The CLASSPATH is simply a mechanism for the stock, generic system classloader.

THere isn't a problem with CLASSPATH per se, the detail is that there can be custom classloaders that have absolutely no regard for the CLASSPATH (e.g. a Webapp classloader).

The CLASSPATH (or related issue) is THE hurdle most Java programmers face. We have a saying here when something goes wrong on our system: Consult The Java Problem Guide. It's 2 pages. First page is "Check you CLASSPATH". Second page "See page 1".

People have a real difficult time understanding it, but once grokked, it's not big deal.

The other benefit of shared classes is with Client apps. Pre-loaded Swing is quite a benefit.

Server-side is will benefit less from this, I think.

THere isn't a problem with CLASSPATH per se, the detail is that there can be custom classloaders that have absolutely no regard for the CLASSPATH (e.g. a Webapp classloader).

Lets consider the scenario:
- a class that is loaded by ‘system’ classloader is trying to load resource by calling Some.class.getResource( “aName.res” ).
- I want to use a different resource content (presumably I do not have source code for that class).

With using CLASSPATH in a standalone application I would make a directory for my version of resource aName.res and make this directory to be a first entry in CLASSPATH – works fine.

Now, the class is used in a webapplication and we put for my version of resource aName.res in WEB-INF/classes.
Some.class cannot use it because its classloader has no idea about WEB-INF/classes.
However if Some.class has used Thread.currentThread().getContextClassLoader() it might get my version of the resource ( at mercy of app server vendor )

This does not seem and feel right.

THere isn't a problem with CLASSPATH per se, the detail is that there can be custom classloaders that have absolutely no regard for the CLASSPATH (e.g. a Webapp classloader).

Lets consider the scenario: - a class that is loaded by ?system? classloader is trying to load resource by calling Some.class.getResource( ?aName.res? ). - I want to use a different resource content (presumably I do not have source code for that class).With using CLASSPATH in a standalone application I would make a directory for my version of resource aName.res and make this directory to be a first entry in CLASSPATH ? works fine.Now, the class is used in a webapplication and we put for my version of resource aName.res in WEB-INF/classes.Some.class cannot use it because its classloader has no idea about WEB-INF/classes. However if Some.class has used Thread.currentThread().getContextClassLoader() it might get my version of the resource ( at mercy of app server vendor )This does not seem and feel right.

If the class is really loaded by 'system' classloader do the same as you would do for a standalone application -- include path-to-resource into server startup classpath. But I do not thing it is generally a good idea to override a resource which was intentionally put together with class into it's jar. If it was it was intended that no-one would override it.

If it was it was intended that no-one would override it.

Quite contrary, very often resource is meant to be overriden, an example will be a struts config files or various mapping resources.
Look at the Struts code as an example of struggle with classloaders:
            ClassLoader classLoader =
                Thread.currentThread().getContextClassLoader();
            if (classLoader == null) {
                classLoader = this.getClass().getClassLoader();
            }
It actually may get worse as Classloader for classes and for resources might not be the same. This my battle:
 URL repoURL = ChannelReportMediator.class.getResource( reportRepositoryResourceName );
        if( repoURL == null ){
          throw new SysConfigurationException( "Resource " + reportRepositoryResourceName + " was not found");
        }
        try{
          //NOTE!!!! Do not use repoURL.openStream() !!!!
          // even it looks like logical solution, troubles begin when jar file is
          // redeployed on the fly
          InputStream input = ChannelReportMediator.class.getResourceAsStream( reportRepositoryResourceName );
          initRepository( input );
          input.close();
          log.info( "Queries have been loaded from repository:" + reportRepositoryResourceName );
        }catch

If it was it was intended that no-one would override it.

Quite contrary, very often resource is meant to be overriden, an example will be a struts config files or various mapping resources.Look at the Struts code as an example of struggle with classloaders:            ClassLoader classLoader =                Thread.currentThread().getContextClassLoader();            if (classLoader == null) {                classLoader = this.getClass().getClassLoader();            }It actually may get worse as Classloader for classes and for resources might not be the same. This my battle: URL repoURL = ChannelReportMediator.class.getResource( reportRepositoryResourceName );        if( repoURL == null ){          throw new SysConfigurationException( "Resource " + reportRepositoryResourceName + " was not found");        }        try{          //NOTE!!!! Do not use repoURL.openStream() !!!!          // even it looks like logical solution, troubles begin when jar file is          // redeployed on the fly          InputStream input = ChannelReportMediator.class.getResourceAsStream( reportRepositoryResourceName );          initRepository( input );          input.close();          log.info( "Queries have been loaded from repository:" + reportRepositoryResourceName );        }catch

Relate the (supposedly) complicated code in your example to what it actually does for you. Dynamicly loading (and re-loading) classes (possibly several different versions) in the same vm is a powerfull feature. Platform independent reading of resource files - where the location can be flexibly decided at deployment time is as well. Contemplate doing the same thing in C...

Relate the (supposedly) complicated code in your example to what it actually does for you. Dynamicly loading (and re-loading) classes (possibly several different versions) in the same vm is a powerfull feature. Platform independent reading of resource files - where the location can be flexibly decided at deployment time is as well. Contemplate doing the same thing in C...

Even the code works it does not mean that it works well and that it is OK to work this way. It should be more straightforward: for example
- Java might standardize that classloader only available via Classloader.currentClassloader();
- Since ClassLoader is used to load other stuff it should be renamed to ResouceLoader;
etc.