#102 Allow "compiler" to be any class file
Why not allow the user to select an arbitrary class as a compiler?
We could call the main method of the specified class, passing in the
source file to compile. We would then display the output to
System.err. And if those errors conform to the expected grammar
(which we'd have to provide in the documentation) we could even
pop to the source locations!
At first glance, this doesn't seem like it'd be hard to implement,
but the payoff would be immense. It would make integration of all
sorts of source-transforming tools (e.g., AspectJ, iContract, the
Java Syntactic Extender, Daikon, ESCJava, etc.) trivial. In fact, it
would also allow for easy integration of Java compilers such as
Jikes that are written in other languages (just write a class to call
exec). As long as errors are piped to System.err, we can display
them,
If we did this, we may also want to rethink how we integrate JSR-
14. We could put all of the functionality for reflective invocation,
etc., into one of these classes. Also, we could immediately support
JSR-14 1.2 integration simply by execing (at least until we had a
faster solution in place). Incidentally, we could also exec on OS X
to immediately fix the JSR-14v1.0 integration problem on that
platform. Oh, and users could invoke the old GJ compiler if they
chose simply by specifying gjc.v6.Main as their compiler.
Alternatively we could provide a special interface that included a
"compile" method to invoke. Then any compiler class specified
would have to implement that interface. This compile method would
take a source file and return some higher-level representation of
the errors. That way, we'd pass the burden of parsing to each class
(of course, new tools could just generate the error objects
directly). The disadvantage of this approach is that tools which
already generate errors to System.err with the expected syntax
would be harder to integrate. Well, I suppose we could make our
interface an abstract class and provide a parsing method for the
expected syntax...
-- Eric
Logged In: YES
user_id=429660
BTW, we could also use this same functionality to provide hooks to
ArgoUML, and possibly ant (the main problem with ant would be providing
a way to invoke multiple targets).
In fact, what we'd effectively be providing is one (limited) form of plug-
in interface. Also, by integrating tools like ArgoUML via plug-ins, we can
distance ourselves from any bugs in those tools. If a tool interfaced via a
plug-in breaks, more users will know to submit the bug report to the tool,
not us. We just need to continue catching Throwable when invoking
compilers.
-- Eric
Logged In: YES
user_id=343403
Is not allowing any ol' compiler to provide a
CompilerInterface implementation good enough? Well, DrJava
would need one more piece: A way for the user to configure a
set of additional compiler interfaces to load.
Incidentally, my idea of how to compile using ant was going
to be to write an overall Ant framework that would, among
other things, include an implementation of CompilerInterface
for Ant.
BTW #2: If we supported compiling via Ant, we might get some
of this other value free, since that would let us compile
using any mechanism supported by ant!
Logged In: YES
user_id=429660
>Is not allowing any ol' compiler to provide a
>CompilerInterface implementation good enough? Well, DrJava
>would need one more piece: A way for the user to configure a
>set of additional compiler interfaces to load.
That would be good enough for me; it's pretty similar to the
second option I mention.
>Incidentally, my idea of how to compile using ant was going
>to be to write an overall Ant framework that would, among
>other things, include an implementation of CompilerInterface
>for Ant.
>
>BTW #2: If we supported compiling via Ant, we might get some
>of this other value free, since that would let us compile
>using any mechanism supported by ant!
Yes; I am all for this, at least long term (i.e., this Spring).
However, I think we could provide make-shift integration
of selected ant targets via the compiler interface with
relatively little effort. Doing so would be consistent
with our incrementalist design philosophy.
Having said that, full Ant integration should be given
a pretty high priority. The latest Ant plug-ins provide
a lot of super-cool functionality. Plus, Ant is already
integrated with most of the popular IDEs. We'll need
to do the same if we want to survive.
-- Eric
Logged In: YES
user_id=182514
I don't know if it was comitted to CVS, but csreis made a
special build that supports this (see feature request 'Jikes
support' at http://sourceforge.net/tracker/index.php?
func=detail&aid=578132&group_id=44253&atid=438938).
The original varient he (or she?) made is still available at
http://drjava.sf.net/drjava-customcompiler.jar, but it only
allows one custom compiler.
Logged In: YES
user_id=557360
There has been a support request submitted (#784188), which
is related to this feature request, so we're raising the
priority.
Neal and I worked yesterday on adding a configuration option
for classnames of valid CompilerInterfaces and getting our
CompilerRegistry to load those classes, adding them to the
list of available compilers.
One of the things holding us up is deciding the best way to
display errors if any given classname is invalid, since we
try to check compiler availability multiple times and don't
want multiple error messages. The other problem is that as
of now, we can't allow the user to specify a jar containing
the custom compiler on the extra classpath, since we use the
system classloader to load the classes.
We'll keep you posted on our progress.
Logged In: YES
user_id=557360
After talking to Dr. Cartwright about this issue, we've
decided that this feature is a lower priority than language
levels and lightweight projects and is not an easy one to
quickly and smoothly knock out. We'll revisit it in the future.
James