-----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@xxxxxxxx> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyyrRarJDwJ6gwowRAn2cAJ9iv4ywJtnN9bOFX6V47VxOaYYy2gCfXAbM dtSikixgsR1Vz9E/CgiC9q8= =V0Jd -----END PGP SIGNATURE-----
