Re: [javax_compiler] Re: Welcome to the discussion group for JSR199 (standard API for Java compilers)
- I was only mentionning alternate APIs for the long term story when we want
to address this JSR. There is no existing documentation reflecting the
Eclipse compiler API as of today, but something could be done on this
FYI, I am not interested in invoking com.sun.tools.javac.Main.compile, but
rather defining an API we can all agree on and then have the Eclipse java
compiler implement it (or did I miss something obvious wrt the purpose of
the javac Main?). So the proposed simple story is already a good
improvement in the sense I could feed the Eclipse compiler with its own
specific command line arguments, without breaking the API. With the Ant
javac task, extra arguments are not tolerated.
<lefevre@...> To: firstname.lastname@example.org
07/25/2003 10:47 Subject: Re: [javax_compiler] Re: Welcome to the discussion group for JSR199
PM (standard API for Java compilers)
Please respond to
> Please, folks: when you reply to an email to this list, edit theOops, sorry. You may have said this earlier and I may have noted it
> recipient field.
but there is so little traffic on this list that I forgot ;-)
>> How does our chair feel about taking the time to study existing compilerYou misunderstood me. I wasn't suggesting that you kill yourself at work:
>> APIs before we go beyond the "minimal" program?
> I expect to be working 60+ hours per week until Tiger code freeze, as I
> have been since late last year. I simply cannot take on any additional
we need our chairman! Rather, I meant that if we take the time to study
existing APIs, then for sure the odds of getting anything beyond the
"minimal program" into Tiger drop to zero.
In addition, there's a policy issue there. The Generics JSR spec had these
infamous and very controversial "non-goals". So, we must first decide
what trying to accomodate existing compiler APIs shall be to us: a goal,
a non-goal or an anti-goal? Now I, too, am feeling like a theologist ;-)
In other words, is that something we wish to care about and how much?
> How would you feel about doing this study, proposing something else, andI don't think I can do that by August 15 either but otherwise I am
> prototyping it in javac?
willing to try, yes.
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> I was only mentionning alternate APIs for the long term story when weThat would be nice. If there is no document outlining its design
> want to address this JSR. There is no existing documentation reflecting
> the Eclipse compiler API as of today, but something could be done on
> this front.
philosophy, that is not very conducive to taking it into account
when researching existing APIs...
> FYI, I am not interested in invoking com.sun.tools.javac.Main.compileWhy not? The command-line arguments to compile are an API of sorts
already. Assuming it were brought out in the open, so to speak, a priori
I would have thought that it provides the kind of functionality required
by IDE and Ant people. So, what do you dislike about it and what do you
want from the new API?
- Philippe P Mulet wrote:
> AFAIK *.javac.Main is only the front end to Sun javac. The proposed simpleThat is exactly right: the proposed simple tool API is little more than an
> tool API is a simple abstraction of it, I don't see much more into it. FYI,
> Eclipse JDT implements its own Java compiler which provide core technology
> for other compilation aware tools (like codeassist, search, etc...).
abstraction of the entry point to the compiler. The "little more" is that
you don't have to worry about tools.jar when compiling your application or
when running it. Perhaps Eclipse's compiler APIs are more in line with
what we intend for JSR199.
> The simple tool approach however doesn't surface dependency information,Also correct. However, I haven't yet seen a clear specification for
> which is quite essential to buld an incremental compiler on top of it.
"dependency" that would be applicable to the API.
> Talking about the Eclipse compiler API, it is fairly stable, and has beenI don't think we have a primary candidate yet. If what I found at
> in use for several years already. Its javadoc are fairly detailed, though
> we should definitely invest more time for producing a design document. BTW,
> where is the matching documentation for the primary candidate API ?
is the documentation you're talking about, I wouldn't call a single
sentence for the documentaiton of the main package "fairly detailed."
For the class ICompilationUnit (it seemed like a reasonable place to
start) I found two sentences. Is there some other more detailed