Feature Requests item #595750, was opened at 2002-08-15 16:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=595750&group_id=44253
Category: Compiler integration
Group: Small (< 1 pair-week)
Status: Open
Priority: 5
Submitted By: Eric E. Allen (eallen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow "compiler" to be any class file
Initial Comment:
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
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=595750&group_id=44253
|
