-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
7
-
x86
-
linux
A DESCRIPTION OF THE REQUEST :
Even though the Java Compiler API with its FileObject interface IN PRINCIPLE allows implementing access to large code using proper InputStream or Reader (via openInputStream() or openReader() methods) objects, the JavaCompiler always uses the inflexible getCharContent() method which forces the user not only to have the whole content of the source file in memory, but AS A CONTINUOUS char array, as the toArray() or toString() methods are called by the Scanner on the resulting CharSequence object. This, of course, causes lots of very unnecessary inefficiencies and memory problems where none need to exist.
JUSTIFICATION :
In our framework, we generate Java source code from very large input sources, so the source code can be of indeterminate length (current examples are over a million lines of generated Java source code in one file). This works fine using the javac command line tool, but is slow because of all the file access, especially writing thousands of very small .class files to disk (and then again reading them from disk to bundle them into jar files). Therefore, we would like to use the Java Compiler API to compile the classes directly into memory. Unfortunately, this leads to the abovementioned problem for the source code side. As a workaround, a different process with more memory would have to be started which necessitates inter-process communication and all that entails - creating other performance issues.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The envisioned soluttion would be an alternative Scanner implementation based on the Reader interface instead of a char-buffer which would be invoked on the result of openReader() when the getCharContent() method throws an UnsupportedOperationException. This way, the JavaFileManager can decide the proper access method for the source file in question.
ACTUAL -
At the moment, the complete content of the java source file is always read into a char-array (one way or another), often causing OutOfMemoryError for .
Even though the Java Compiler API with its FileObject interface IN PRINCIPLE allows implementing access to large code using proper InputStream or Reader (via openInputStream() or openReader() methods) objects, the JavaCompiler always uses the inflexible getCharContent() method which forces the user not only to have the whole content of the source file in memory, but AS A CONTINUOUS char array, as the toArray() or toString() methods are called by the Scanner on the resulting CharSequence object. This, of course, causes lots of very unnecessary inefficiencies and memory problems where none need to exist.
JUSTIFICATION :
In our framework, we generate Java source code from very large input sources, so the source code can be of indeterminate length (current examples are over a million lines of generated Java source code in one file). This works fine using the javac command line tool, but is slow because of all the file access, especially writing thousands of very small .class files to disk (and then again reading them from disk to bundle them into jar files). Therefore, we would like to use the Java Compiler API to compile the classes directly into memory. Unfortunately, this leads to the abovementioned problem for the source code side. As a workaround, a different process with more memory would have to be started which necessitates inter-process communication and all that entails - creating other performance issues.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The envisioned soluttion would be an alternative Scanner implementation based on the Reader interface instead of a char-buffer which would be invoked on the result of openReader() when the getCharContent() method throws an UnsupportedOperationException. This way, the JavaFileManager can decide the proper access method for the source file in question.
ACTUAL -
At the moment, the complete content of the java source file is always read into a char-array (one way or another), often causing OutOfMemoryError for .