United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6297388 JSR 199: compile against a class loader
JDK-6297388 : JSR 199: compile against a class loader

Details
Type:
Enhancement
Submit Date:
2005-07-15
Status:
Open
Updated Date:
2013-07-18
Project Name:
JDK
Resolved Date:
Component:
tools
OS:
generic
Sub-Component:
javac
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
javadb_10.0,6
Targeted Versions:

Related Reports
Blocks:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
a problem JSP Containers face is to compile generated JSP Page Servlets
against the classpath that makes up a web application. There is no way
to find out the locations of the classes that make up the classpath.
While it is possible for WEB-INF/classes and WEB-INF/lib, the JSP
container needs intimate knowledge of the servlet container's class
loading mechanism to add the rest (for example, the location of the
servlet-api jar).

This dependency on the servlet container has hindered the community to
develop a portable, drop-in JSP container. While you can argue that JSP
and Servlet containers are intimately coupled, any web framework that
wants to compile code would face the same problem.

An alternative, pioneered by the Cocoon community, and which I believe
is being pursued by Jasper in Tomcat 5.5, is to use a compiler that
resolves its classpath against a _classloader_ instead of a
_filesystem_, using ClassLoader#getResource instead of java.io.File.
Eclipse's Compiler has successfully been used to do this.

While the JavaFileManager in principle looks like it could be adapted to
a ClassLoader, it requires the "list" operation, an operation a
ClassLoader cannot fulfill. Is listing all classes in a package
necessary for this compiler to work? If so, a "Compile in current
classloader", or more specific, "Compile in this webapp" will not be
possible with JSR 199 which would be a shame. I remember that I once
tried to make javac do this and I stumbled over this exact requirement
before; eclipse's jdt did not need it.

References:

http://mail-archives.apache.org/mod_mbox/jakarta-tomcat-dev/200307.mbox/%###@###.###%3e

http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html

###@###.### 2005-07-15 14:41:52 GMT

                                    

Comments
SUGGESTED FIX

JavaFileManager should have a method for resolving
binary class names directly.

###@###.### 2005-07-15 14:51:12 GMT
                                     
2005-07-15
WORK AROUND

While the abstract ClassLoader API may not easily support the current JavaFileManager, it is likely that an implementation of ClassLoader would be able to. Making a ClassLoader that loads from a jar file, for example, is not a big deal, and such an implementation of ClassLoader could support the JavaFileManager interface as well.
                                     
2005-07-28
EVALUATION

Currently, the infrastructure of javac is not geared towards
this RFE.  However, it is reasonable to expect JSR 199 to
include this possibilty for at least two reasons:

* other compilers might have different infrastructure
* JSR 199 should be able to accomodate future growth
                                     
2005-07-28
EVALUATION

The problem here is that the JavaFileManager API provides a "list" operation, which is used internally by the impl class JavacFileManager to determine the contents of a package when processing import-on-demand. (e.g. "import java.util.*;")    But, the ClassLoader API does not support a list operation in any form.

There is a partial workaround, and that's as good as it will get.

We can change javac internals to not use the list operation. This means rewriting the Scope system so that scopes are built more lazily -- especially the scopes for "import on demand". That will allow most compilations to be feasible when using a class loader.

The problem is that the list operation is exposed through the public API for jsr199 (compiler API) and jsr269 (annotation processing). Wth these API, a client can provide "plugin" code that may want to list the contents of a package.  If a Location is provided that uses a ClassLoader, that operation will fail (as in get something like UnsupportedOperationException.) 

We will have to change the spec of list to allow that possibility, and/or provide additional methods to determine if a Location supports the list method.
                                     
2010-11-22
Removing fix version,  the blocking issue doesn't have a fix version yet,  and might not be implemented in 8, therefore this enhancements will probably not be implemented in 8.
                                     
2013-06-14
As much as we want to do this, we are blocked by the lack of the necessary underlying API from ClassLoader.
                                     
2013-05-15



Hardware and Software, Engineered to Work Together