Re: Standard compilation JSR

[Kevin Riff <ke...@earthling.net>]

I like it. The last project I was involved in could have benefited by having a
standard Java interface for invoking a compiler. I even spent some time
day-dreaming about what features I wanted to have. Here's a quick list:

- The compiler should use callbacks to the invoker to locate source files. This
leaves all source-path issues up to the invoker, not the compiler. Source files
could come from directories, jar files, databases or strands of DNA but the
compiler needn't know about such things.

- Similarly, the compiler should invoke a callback to give the invoker the
completed class file(s). This lets the invoker store the class as a file, as a
database entry or whatever. Again, the compiler needn't know a thing.

- There should be a way to get back other info that compilers routinely create.
Things like symbol tables and inter-class dependency info.

- It should be easy to implement as a wrapper around just about any compiler.
The basic options (such as whether to include debugging info) should be
standardized. There also needs to be a standardized way of setting non-standard
options.

I'm sure there are plenty more good ideas out there...

I don't think this should be done as a JSR. There are plenty of projects (such
as the JavaC task) that need this now. I think the JSR process would be too
slow.



Robin Green wrote:

> Jose Alberto Fernandez <jo...@us.oracle.com> wrote:
>
> >All this talk about javac and what should be visible and what should
> >not, just points out the need for the Java Specs to define a standardize
> >way to access a Java Compiler. With JSPs and other technologies
> >that require compilation of generated code it should be obvious that
> >we cannot continue using javap to try to solve this problem.
> >
> >Perhaps we need something similar to JAXP (the standarizd API for
> >XML parsers) that all Java compiler providers should support to make
> >tools portable to different environments.
> >
> >Anyone willing to make an JSR out of this?
> >
>
> V. Good idea!
>
> It would be useful if this spec would support advanced options only supplied
> by some compilers - such as dependency checking in Jikes (FOOTNOTE: -depend
> is buggy in Sun's javac, and was disabled in JDK1.3's new compiler), and
> (looking to the future) incremental compilation support, for integration
> into IDEs in particular. Otherwise the spec would not be much of an advance.
> Perhaps the best way to do this, allowing for any number of new features,
> would be to have a queryable feature-set mechanism, with a public registry
> of features on a web site. So, the feature "dependency checking" (suitably
> precisely defined) would be given a key of, say, "DEPEND", and any other
> compiler using this feature would also use that same key in its feature set,
> rather than defining its own. Some features, like incremental compilation,
> would perhaps have to have new APIs defined for them, but this would all be
> done through a standards process.
>
> Kind of like the concept of BeanInfo objects, but with public standards as
> to what the keys meant.
>
> Is this clear, or do I need to explain it further?

Re: Standard compilation JSR

[James Duncan Davidson <ja...@eng.sun.com>]

> - The compiler should use callbacks to the invoker to locate source files.
This
> leaves all source-path issues up to the invoker, not the compiler. Source
files
> could come from directories, jar files, databases or strands of DNA but
the
> compiler needn't know about such things.

True. Streams in.

> - Similarly, the compiler should invoke a callback to give the invoker the
> completed class file(s). This lets the invoker store the class as a file,
as a
> database entry or whatever. Again, the compiler needn't know a thing.

... and streams out... Now, I don't necessarily agree that it needs to be
callbacks, but that's a detailed discussion.

> - There should be a way to get back other info that compilers routinely
create.
> Things like symbol tables and inter-class dependency info.

Yes. Especially if you are generating code to feed to the compiler.

> I don't think this should be done as a JSR. There are plenty of projects
(such
> as the JavaC task) that need this now. I think the JSR process would be
too
> slow.

Actually, if you don't do it as a JSR, the most important compiler
available, the one that ships with each and every JDK, won't be compliant.
JSRs don't have to be any slower than any other approach. We're looking at a
few months for the JAXP.next schedule from start to finish -- SAX2 took
longer than that and there wasn't any process to follow. And if you go too
fast, you'll probably (not necessarily, but probably) end up with a bad
design.

Whomever wants to pull together this JSR, I'll be happy to help however I
can.

.duncan