gmane.comp.lang.scala

Re: Re: Scala interpreter: classpath vs. class loader

Actually, mostly everything you need to link against a class is
visible in the java.lang.Class object. It has to be, otherwise
bytecode verification wouldn't work so well. So what's the problem?

On Wed, Oct 8, 2008 at 4:51 PM, Michael Dürig <michid <at> gmail.com> wrote:
>
>> So you create a new SymbolLoader that wraps a classloader and
>> determinse demand determines whether or not a class exists. I don't
>> think this is so hard if you are willing to define and install your
>> own symbol loader.
>
> The classloader might not expose the functionality required by the symbol
> loader. So this might not work. Again, see my earlier post on why I think
> so.
>
> Michael
>
>

headers

Michael | 8 Oct 14:12

Re: Scala interpreter: classpath vs. class loader


> Actually, mostly everything you need to link against a class is
> visible in the java.lang.Class object. It has to be, otherwise
> bytecode verification wouldn't work so well. So what's the problem?

The problem is getting the class in the first place. See my earlier posts.

headers

Sean McDirmid | 8 Oct 14:31

Re: Re: Scala interpreter: classpath vs. class loader

Yes, I think I get it now. The problem would be Scala-specific
information, I thought maybe you were compiling against just Java.

If you can get physical access to the class files, you could still
hack a symbol loader to serve them, even if you didn't know what class
files existed until a request was made.

Sean

On Wed, Oct 8, 2008 at 8:12 PM, Michael <michid <at> gmail.com> wrote:
>
>> Actually, mostly everything you need to link against a class is
>> visible in the java.lang.Class object. It has to be, otherwise
>> bytecode verification wouldn't work so well. So what's the problem?
>
> The problem is getting the class in the first place. See my earlier posts.
>
>
>