[
https://issues.apache.org/jira/browse/SLING-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739996#action_12739996
]
Michael Dürig commented on SLING-945:
-------------------------------------
Not entirely. I think there should also be a method for browsing classes in
packages. Something along the lines of JavaFileManager.list() [1].
This will be requires for languages/features which have compile time dependency
injection. Scala is just one case here. Java EE 6 will most probably come with
JSR 330: Dependency Injection for Java [2]. For the injection mechanism to
work, the script engine needs a compile time mechanism to determine the
available classes so it can inject a suitable one.
[1]
http://java.sun.com/javase/6/docs/api/javax/tools/JavaFileManager.html#list%28javax.tools.JavaFileManager.Location,%20java.lang.String,%20java.util.Set,%20boolean%29
[2] http://jcp.org/en/jsr/detail?id=330
> Introduce a ClassReader for scripts which need to do symbol resolution at
> compile time
> --------------------------------------------------------------------------------------
>
> Key: SLING-945
> URL: https://issues.apache.org/jira/browse/SLING-945
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Michael Dürig
>
> As mentioned in [1] scripts (which compile to byte code) should not use the
> class loader for loading class files to resolve external symbols. Class
> loaders are designed to load binary representations of classes into the JVM
> at runtime. Using them for scripting languages which need to resolve symbols
> at compile time is a hack. In fact all languages which I looked at and which
> do symbol resolution at compile time use the same
> 'classloader.getResource("foo.class")' hack to get access to a class file.
> Languages which require to browse the classes available to them at compile
> time need to resort to even more esoteric hacks.
> I faced this issue when I implemented support for Scala. To work around it I
> implemented a (Scala specific) file system abstraction on top of Felix's
> bundles. While this works ATM, the approach might not be too stable since it
> partially relies on implementation details of the underlying classloaders.
> Since other scripting languages have the same problem (i.e. JSP AFAIK) I
> suggest to factor the hacks into a separate ClassReader service. Scripts can
> then use this at compile time to resolve external symbols.
> [1] http://sling.markmail.org/message/ly3yhlmqufpugjly
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
