[very much RFC][icedtea-web] fix for [Bug 564] NetX depends on sun.misc.BASE64Encoder

[Deepak Bhole]

* Jiri Vanek <jvanek at redhat.com> [2011-10-10 11:31]:
> On 10/07/2011 07:01 PM, Omair Majid wrote:
> >On 10/07/2011 12:09 PM, Jiri Vanek wrote:
> >>Only drawback of copypasting this explicit code is that we lost possible
> >>updates from third party (where is it much more used then in icedtea-web)
> >
> >Actually, I am against copying code into icedtea-web. Not only do we lose the benefit from updates, if any security issues are discovered in the code (not that sun.misc.BASE64Encoder is likely to have many), we will have to update the code in icedtea-web as well. To be safe, that would mean that we look every security update for openjdk and double check that the code we copied into icedtea-web is not affected by the fix.
> >
> >I think https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Why_no_Bundled_Libraries gives many more reasons why copying code ("bundling") into icedtea-web may be a bad idea.
> >
> >Still, if others think it is fine to copy a small (and rather safe) piece of code into icedtea-web, then please don't let me stop you.
> >
> >Cheers,
> >Omair
> 
> 
> Well, according to this issue I'm still hesitating :(
> I agree that replacement of base64  encoder is quite safe and minor issue. Also I admit, that my fix is really huge for just a simple thing.
> 
> Are there any plans to fix another similar compiler-infos[1] issues? If yes, will they be probably fixed by calling 3rd party libraries  or will be written by us? (or copied from openjdk??!!)
> 
> Based on this i would like to decide this base64 patch.
> 

Some of them (like sun.applet.*) would be a lot harder to remove (if at
all possible) than the rest. Furthermore, there are also some
(sun.net.www.protocol.jar.URLJarFileCallBack,
sun.net.www.protocol.jar.URLJarFile) that should _not_ be removed.

The fact of the matter is, we need to use some private apis to hook into
the jre cleanly because the plug-in is not just a "standard
application". It needs to do things that sometimes go beyond -- so I
don't think that the metabug (562) will ever be resolved.

Then the question is, if we are already using 5-10 hooks via private API,
do a couple of more (that may be removable) really matter?

Cheers,
Deepak

> Best regards
> 	J.
> 
> 
> [1]
> 564 	nor 	P2 	All 	unassigned at icedtea.classpat... 	ASSI 		NetX depends on sun.misc.BASE64Encoder
> 571 	nor 	P2 	Linu 	unassigned at icedtea.classpat... 	NEW 		NetX depends on com.sun.net.ssl.internal.ssl.X509ExtendedTrustManager.java
> 575 	nor 	P2 	Linu 	dbhole at redhat.com 	NEW 		Plugin depends on com.sun/jndi.toolkit.url.UrlUtil
> 605 	nor 	P2 	Linu 	omajid at redhat.com 	NEW 		NetX depends on sun.misc.HexDumpEncoder
> 562 	nor 	P2 	Linu 	dbhole at redhat.com 	NEW 		[METABUG] NetX code contains reference to non-standard sun.* classes
> 576 	nor 	P2 	Linu 	dbhole at redhat.com 	NEW 		Plugin depends on sun.applet.AppletImageRef
> 563 	nor 	P2 	All 	dbhole at redhat.com 	NEW 		NetX uses sun.security code
> 570 	nor 	P2 	Linu 	unassigned at icedtea.classpat... 	NEW 		NetX depends on sun.applet.AppletViewPanel
> 574 	nor 	P2 	Linu 	dbhole at redhat.com 	NEW 		Plugin depends on sun.misc.Ref
> 762 	nor 	P5 	Linu 	omajid at redhat.com 	NEW 		Netx depends on sun.net.www.protocol.jar.URLJarFileCallBack
> 657 	nor 	P5 	Linu 	dbhole at redhat.com 	NEW 		IcedTea-Web depends on sun.misc.JarIndex
> 761 	nor 	P5 	Linu 	omajid at redhat.com 	NEW 		Netx depends on sun.net.www.protocol.jar.URLJarFile