Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 81890 invoked from network); 23 Mar 2000 02:24:55 -0000 Received: from unknown (HELO envision.asiaconnect.com.my) (root@202.190.60.154) by locus.apache.org with SMTP; 23 Mar 2000 02:24:55 -0000 Received: from localbar.com (IDENT:niclas@localhost [127.0.0.1]) by envision.asiaconnect.com.my (8.9.3/8.8.7) with ESMTP id KAA18527 for ; Thu, 23 Mar 2000 10:29:48 +0800 Sender: niclas@envision.asiaconnect.com.my Message-ID: <38D9819C.BC2305A4@localbar.com> Date: Thu, 23 Mar 2000 10:29:48 +0800 From: Niclas Hedhman Organization: Bali Automation Sdn Bhd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: JDK 1.2 vs 1.1: the never-ending story. References: <38D40F57.51BB0631@apache.org> <38D54F2A.C01E4C21@apache.org> <009101bf9273$f91bb460$2a01a8c0@eddie> <38D90FDD.B7479F4E@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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 java.net.URLClassloader?? 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. Niclas