|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 23
Messages: 23
Messages: 23
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Shared Java Classes in the JVM
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.
SummaryJava 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
|
|
|
Message #126176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Not that much benefit....
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.
|
|
|
Message #126183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Classloading in Java has very-very-very bad implementation
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.
|
|
|
Message #126194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Classloading in Java has very-very-very bad implementation
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.
|
|
|
Message #126205
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Hell
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.
|
|
|
Message #126235
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Hell
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
|
|
|
Message #126239
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does this mean "Bye Bye RMI " ??
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 ???
|
|
|
Message #126291
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Shared Java Classes in the JVM
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.
|
|
|
Message #126292
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does this mean "Bye Bye RMI " ??
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.
|
|
|
Message #126304
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java Hell
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" ?
|
|
|
Message #126306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Shared Java Classes in the JVM
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.
|
|
|
Message #126355
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Classloading in Java has very-very-very bad implementation
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
|
|
|
Message #126379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Classloading in Java has very-very-very bad implementation
(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.
|
|
|
Message #126381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does this mean "Bye Bye RMI " ??
> No, it doesn't affect RMI.
Though it would be cool if jvms could implement
a distributed shared memory protocol on selected
regions.
|
|
|
Message #126411
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Shared JVM classes
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.
|
|
|
Message #126422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with classloaders
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.
|
|
|
Message #126546
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Classloading in Java has very-very-very bad implementation
> Consider classpath like this: /my/dir:http\://some.server.com:rmi\://server:etc.
Yes, so? If it hurts - dont do it...
> I never said it is a bug. It is poorly implemented feature that breaks language semantic.
Your alternative would be?
> I would probably agree, but I am not so sure that it is the right way to do it
Sure - each application in its own VM then?
> I suggest spending more time with application servers and I am sure you will know exactly what I am talking about.
I did. You should to.
|
|
|
Message #126589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with classloaders
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.
|
|
|
Message #126602
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with classloaders
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
|
|
|
Message #126643
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with classloaders
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...
|
|
|
Message #126667
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
what is wrong with classloaders
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.
|
|
|
Message #126678
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IBM and fast Java VM startup...
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.
|
|
|
Message #126718
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does this mean "Bye Bye RMI " ??
Though it would be cool if jvms could implementa distributed shared memory protocol on selectedregions. have a look at jini & especially javaspaces
--Calum
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
