harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven de Marothy <s...@physto.se>
Subject Re: ClassLib implementations WAS some ideas
Date Fri, 03 Jun 2005 15:50:43 GMT
Peter Edworthy wrote:

> How clean are the separations between packages/groups of packages in
> ClassPath?

As clean as possible.

Depending on non-public parts of other API packages is to be avoided as far 
as possible. And if there is Classpath-specific behaviour in the public API, 
then that is likely a bug. (or the absence of a Sun bug)

> i.e. how possible would it be to use say java.sql.* with another
> implementation of java.lang?

Why wouldn't it be possible? It'd be horrible coding if it were any other way.

So yes, it's completely possible. Simple even. There are no implementation-specific
interdependencies between packages that I know of. 
Not counting between packages and subpackages, of course. 
(And even those are somewhat rare.)

But it does of course stand to reason that just any arbitrary package can't be seperated
out. E.g. Our java.awt.image will never work happily with Sun's AWT, or vice-versa.

However, our java.awt.geom and java.awt.color will. Our Swing should be able to run on
Sun's AWT. (Although I'm not sure about Sun's Swing. I've heard it isn't 100% pure java,
after all, but does rely on some undocumented stuff)

> I ask this as I'm just wondering if having the ClassLoader select from
> multiple implementations based on user preference for that package would
> be a good idea or just an added complication.

There are several ways of doing this; Newer APIs like ImageIO, NIO, Sound, Crypto, 
etc. are designed around a Service Provider Interface. They're designed to have multiple
implementations, including user-provided ones. 
In these cases, choosing a certain implementation is just a matter of configuring
META-INF/services in your jar or setting a system property.

These SPI-plugins should work just as well with the JDK as with classpath too.

As for non-SPI packages, the simple way is to utilize your CLASSPATH
variable settings. If you have the same package twice in your CLASSPATH,
the first will be used. No changes to the classloader required.

Although in general, I think choosing the implementation you want is
more of a job for the VM vendor, since they know what platforms they
want to support and what their 'niche' is.

E.g. GCJ already requires iconv, so they'll want to use the iconv-based
charset service provider. JNode on the other hand wants to be pure java,
so they want that one. GNU Classpath has both.


View raw message