Rhett, 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? Cheers, Jeremias Märki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
