On Mon, 2006-01-16 at 00:10 -0500, David Walluck wrote: > 1.) About java.beans.XMLEncoder: I thought this implementation had been > committed to classpath? See > <http://www.fsfe.org/en/fellows/robertschuster/weblog/gnu_classpath_everywhere> > > $ unzip -l /usr/share/classpath/glibj.zip | grep java\.beans\.XMLEncoder > 3227 01-14-06 01:19 java/beans/XMLEncoder.class > > $ unzip -l /usr/share/java/libgcj-4.1.0.jar | grep java\.beans\.XMLEncoder > > Looks like libgcj is not in sync with this change. It was only added very recently (after I wrote the patch, in fact). So, if we don't add it to 4.1, which doesn't seem to be happening, I was thinking of simply bundling it with the Azureus SRPM. > 2.) There's some scary stuff removed in azureus-sun.misc.Cleaner.patch > and azureus-sun.misc.Signal.patch. What are the chances that upstream > even cares about this? It is non-critical and can be removed even on > proprietary jdks I think. To be honest, I don't even know what those things do. Let's just put all our patches and comments together to feed to upstream. > 3.) It appears that azureus-remove-win32-osx-platforms.patch would not > be necessary if an exception wasn't thrown/logged if the platform was > not macos or windows. There seems to be no harm in actually checking the > platform. Maybe upstream would accept a patch. I don't compile these because there are some references to platform specific classes somewhere (like from a vendor's JRE) and it was easiest just to cut all that code out. Try removing that patch and doing the platform test, and you'll see what I mean. > 4.) Most importantly, the patches azureus-GKR.patch and > azureus-jessie.patch create lockin to gcj. With the classpath.security > file, is jessie.patch even necessary? Maybe not. I don't think we add Jessie to our security property file by default. I have it in mine, but it's possible I added it manually. I guess I'll know once I do the clean FC5test2 install. > It might also be possible to try > for both classes and just catch exceptions. About the GKR patch, maybe > the same thing applies: try for JKS also, and handle the error. Yes, we can definitely do that. At the time I wasn't interested in spending time to create upstream-friendly patches, since I wasn't sure any of this would work at all. Now I'm interested, and appreciate the help! Thanks, AG
