commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject [jci] JaninoJavaCompiler and other issues
Date Mon, 15 Aug 2005 17:17:53 GMT

today I came across an issue with the Janino version 2.3.3 in use in JCI. It
does not find static methods in classes. After an update to 2.3.8 (which
unfortunately needs adaptions in JaninoJavaCompiler the compilation of my
classes work again. Is there any interest in this update to JCI codebase?

Next issue is triggered by this update to 2.3.8. We also use Janino for XSP
compilation in Cocoon, which also did no longer work after the update to 2.3.8.
I made the changes and now please let me point out the issues mentioned in the
subject. The class is actually an implementation of Cocoon's LanguageCompiler
interface and a wrapper around JaninoJavaCompiler.

1. The LanguageCompiler interface has a method setEncoding(String).
Unfortunately I can not propagate the param to JaninoJavaCompiler, because the
value is not parameterizable there, but hard-coded.

2. The CompilationProblem class has nice field storing e.g. location
information. Unfortunately there is no access to these fields, just a toString()
method. But the class CompilerError in Cocoon would like to see these
informations. Would it be possible to add public getters to CompilationProblem?

3. The CompilationProblem is a nice abstraction, but isn't it somewhat limited?
Both Eclipse and Janino provide more information than CompilationProblem can
accept. Wouldn't it be better to convert CompilationProblem to an interface and
create class like EclipseCompilationProblem and JaninoCompilationProblem being
wrappers for the original problem/exception classes? So like in my case where I
know that the CompilationProblem should be an instance of a
JaninoCompilationProblem I can react more specifically (e.g. accessing the
column number of the problem).



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message