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_everyw...
$ 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