cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: JDK 1.2 vs 1.1: the never-ending story.
Date Thu, 23 Mar 2000 02:29:48 GMT
Pierpaolo Fumagalli wrote:

> Ross Burton wrote:
> > * Swing (not relevant)
> Very relevant since Cocoon can produce images out of XMLs (like SVG
> rendering). It's true, it's not "core" but it's one of the features we
> cannot avoid to have.

But rendering of images should be over java.awt.image.BufferedImage, which is
JDK 1.0 (according to API docs.)
Because Sun has promised that "somewhere in the future" BufferedImage will not
require X Windows to be running, which is now the case on Linux.  This is rather
important, since Cocoon will very often sit on servers, which typically doesn't
have X started.

> > * Classloader extensions?  I've heard this but are they useful?  It seems
> > that the current problem with classloaders stems from bugs in JServ/Tomcat.
> They'll be useful when thinking about XML page compilation (XSP)... This
> is _CORE_ :)

Are we talking loading classes in and out of memory??  That is handled in JServ,
so 1.2 is not necessary.
Are we talking about the Extension classloader?? That is mostly for convinience.

Or are we really talking  Which is cute, but not
entirely necessary for our needs.

> I believe that, since our first non-beta release is scheduled for
> october, we should try to focus on those environments that in october
> will have a reliable JDK-1.2 implementation...
> And IMVHO Linux will be one of those...

Although your arguments are weak, I strongly agree with you.

Collections are nice, but not mandatory to get the job done.

I would say that Weak References is THE strongest argument. Which will enable
far better caching algorithms among other things.
Perhaps some security classes will be worth mentioning as well, but it seems
that Cocoon wish to leave that outside its scope.


View raw message