I've read through your proposal and I end up being -0. Here are some
pros and cons that came to my mind (disclaimer: no scientific research
behind those points):

+ Works around certain problems in an elegant fashion. We can provide
  the best code for each JDK-version.
+ Interested parties may be able to restore JDK 1.1 functionality more
  easily. It's easier to maintain JDK 1.2 support.
- Working with classloaders may increase the difficulty of embedding FOP
  especially in a web or EJB container where a bunch of special
  classloaders is already active. Increased difficulty means more
  support effort.
- Increased effort necessary to maintain the code over multiple
  platforms. All target platforms have to be tested prior to a release.
- Increased time for familiarizing oneself with the code.

The main point that leads to my -0 is my first negative point. The
classloaders won't hurt in standalone usage but could develop into a
PITA when used in a more complex environment. -0 means I won't stand in
the way but I would like the stuff be well tested. Not being a
classloader specialist I only state my concerns about something that has
caused problems in the past.

I appreciate your effort in following down this path and I hope I'm
proven wrong because if this works great this is a very powerful
addition to FOP (and possibly other projects like Batik). Sorry for not
being more positive.

On the other side I keep thinking if improving the build process to
produce JDK-specific jars wouldn't be a better (and less painful)
approach of handling this. Just a thought...

> I'm content being on my own.  I just don't want to end up building
> something that nobody wants or needs, which was really why I'd put up a
> proposal and asked for comments.  Honestly, the thumbs-up I was looking
> for was from someone like Keiron so that I'd know it was believed that I
> was correctly addressing an issue that needs addressing. The majority of
> the work on the classloader will be pretty easy stuff, and I can even
> take on the "splitting" system-dependant classes into their
> version-specific components and so forth.  And write documentation on
> how to do that.
> I was just hoping that I could get a word from a higher-up or two that
> there was an interest in this being pursued.  That you've suggested I
> go for it is definitely encouraging.  Anyone else want to throw in? 
> Any +1s, gang?

Jeremias Märki

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to