commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [jci] JaninoJavaCompiler and other issues
Date Mon, 15 Aug 2005 18:11:11 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?

Of course! ...what a question ;)

> Next issue is triggered by this update to 2.3.8. We also use Janino  
> for XSP
> compilation in Cocoon,

..as well as the eclipse compiler - I know ;)

> 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.

Why not create a JciCompiler implementation of
the LanguageCompiler interface? It could act as
a factory. The implementation could be passed in
through the component configuration.

> 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.

Ok ...already came across this too

> 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?

Make sense

> 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).

Sounds like a good idea!

Will look into it tonight

cheers
--
Torsten

Mime
View raw message