consider alternate URL constructor in DecoupledLoader

[GoogleCodeExporter]

In my environment I am loading google collections in a classloader that
uses a custom URLStreamHandler. Complicating the matter is that the
protocol/scheme portion of these URLs do not have handlers in the system
wide handlers table in java.net.URL. 

This particular setup causes the URL constructed in
DecoupledLoader.getBaseUrl() to throw MalformedURLException and the
fallback DirectLoader is used. 

I'll be the first to admit that I am the cause of this issue really, the
code in google collections is not doing anything non-standard or unexpected. 

That said, there is a very simple change that would fix things for me and
should operate exactly as the current code. Specifically if the constructor
URL(URL context, String spec) is used, then the handler from the context
URL will be used. I've verified this locally. Attached is the patch to trunk.

An example of this same type of URL construction is used when
URLClassLoader contructs URLs with a base of on the search paths
(sun.misc.URLClassPath actually)

Original issue reported on code.google.com by tim...@gmail.com on 14 Sep 2009 at 9:23

Attachments:

• patch.txt

[GoogleCodeExporter]

this seems to be filed to the wrong project.

Original comment by kevin...@gmail.com on 14 Sep 2009 at 10:59

• Changed state: Invalid

[GoogleCodeExporter]

This isn't the project for google collections? The patch in question is for
src/com/google/common/base/FinalizableReferenceQueue.java

Original comment by tim...@gmail.com on 14 Sep 2009 at 11:08

[GoogleCodeExporter]

Whoops!  I was totally unaware there was URL-related code in Bob's class.  Sorry
about that.  Ok Bob, what do you make of this?

Original comment by kevin...@gmail.com on 14 Sep 2009 at 11:34

• Changed state: Accepted

[GoogleCodeExporter]

Thanks. It would be great to get Bob's input. Unfortunately I had to pull this
library in out of the next Terracotta release and fall back to 
commons-collections
because of this issue

Original comment by tim...@gmail.com on 16 Sep 2009 at 8:40

[GoogleCodeExporter]

Patch looks good!

Original comment by crazybob...@gmail.com on 16 Sep 2009 at 9:26

[GoogleCodeExporter]

woo-hoo (and there was much rejoicing). thanks

Original comment by tim...@gmail.com on 17 Sep 2009 at 5:50

[GoogleCodeExporter]

I'll get it applied for rc3 which you should see next week.

Original comment by kevin...@gmail.com on 17 Sep 2009 at 6:15

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 4:51

• Added labels: 1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:45

• Added labels: Milestone-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:46

• Removed labels: 1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:58

• Added labels: Type-Defect

[GoogleCodeExporter]

Of course, by "get it applied", I mean, "glance at it so I know what you mean, 
then 
type in a fix myself".  Because it would be pretty silly to make you sign a 
contributor agreement over this. :) 

Original comment by kevin...@gmail.com on 18 Sep 2009 at 4:17

[GoogleCodeExporter]

fixed for next week's rc3.

Original comment by kevin...@gmail.com on 18 Sep 2009 at 5:12

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 18 Sep 2009 at 5:12

• Changed state: Fixed