[fedora-java] [Fwd: Re: Azureus (Was: bittorrent in core? what frontend?)]

[Anthony Green]

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