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

David Walluck david at zarb.org
Mon Jan 16 05:10:41 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anthony Green wrote:
> Just FYI...

I have been considering compatibility with proprietary jdks and the
current azureus rpm. After all, until FC4 users have gcc 4.1, this seems
like the best option. Also, free-jdk lockin is bad, IMO (not as bad as
proprietary lockin, of course).

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.

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.

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.

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? 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.

- --
Sincerely,

David Walluck
<david at zarb.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDyyrRarJDwJ6gwowRAn2cAJ9iv4ywJtnN9bOFX6V47VxOaYYy2gCfXAbM
dtSikixgsR1Vz9E/CgiC9q8=
=V0Jd
-----END PGP SIGNATURE-----




More information about the java-devel mailing list