Possible changes to import ... from: ...

[Raphael Mudge]

Hi everyone,

I'm thinking of changing how Sleep handles import from.  Right now Sleep creates a new URLClassLoader for each jar file and keeps track of what packages you associate with it.

There are some limitations to this.  For example, if an API is dependent on multiple jars, this mechanism can't handle that.  You have to resort to the classpath.  Also, if a library decides to go to its own jar for a resource, and they do it in a ghetto way, then the resource will not be found.  

Ralph Becker wrote a classloader bridge to extend the Java system classpath at runtime.  It uses reflection and assumptions about the system class loader that could (but probably won't) change in future versions of Java.   http://www.ululatus.org/sleep_jircii/classloader/

I've created a patch using his tekneekz and I'm currently testing them out.  I'd like to get your feedback if you foresee any pitfalls of going this route.   Feel free to comment on the actual RFE report.

http://sleep.dashnine.org/suckit/view.html?id=1216936019235

AFAIK this will not affect backwards compatibility.  If you think it might let me know!  

-- Raphael

[Poarman]

Hi Raph,

Sounds cool to me. I started trying to use classLoader but didn't get
it working in the 10 minutes I put toward it. I was going to keep
going because I like the idea, but haven't had the chance yet. Having
it built in would be cool.

Have a GREAT day!
poarman

[Raphael Mudge]

Here is a build of the jar. A pattern I keep trying is:

import * from: whatever.jar;

So if you have, for example, JDBC drivers... I'd just do import *
from: oracleIsSuchACrappyDatabaseWhyDoProfessionalsUseIt.jar;