The javac compiler in J2SE 1.4.1 will be
reentrant. That was a prerequisite to
implementing an API. Earlier versions
of the compiler were "synchronized" to
prevent concurrent use. Now the compiler
has no static data except constants.
The feature set for J2SE 1.5 is being defined
right now. If an API for javac makes the cut
I will be starting a JSR for its definition.
> The javac compiler in J2SE 1.4.1 will be
> reentrant. That was a prerequisite to
> implementing an API. Earlier versions
> of the compiler were "synchronized" to
> prevent concurrent use. Now the compiler
> has no static data except constants.
Excellent - that's good to hear.
> The feature set for J2SE 1.5 is being defined
> right now. If an API for javac makes the cut
> I will be starting a JSR for its definition.
Nice. I'm looking forward to seeing the Tiger specs/proposals - it's nice to
dream :)
Jon
Cool stuff. This is very similar to some lines that I've been thinking
along lately.
( Disclaimer: I've not (yet) done graph theory,
so what is new for me might well
be old-hat to you folks
I am also aware of a need to look at
any research in 'virtual file systems'
When you abstract it, software that is involved in the transformation
problem-frame is generally about transforming one tree of nodes to another
tree of nodes. This is particularly the case for compilers.
Software that organises the sequence in which these transformations are
applied ( ie. build-software ... such as make and Ant ) usually has to guess
via polling techniques which nodes in a given tree have been altered by
the previous transformation!
It is obviously much better for the algorithm controlling the build if
it gets event-style notification when a node is added/removed/modified,
as Yarda has already eloquently written.
Filesystems impose an artibrary granularity on the tree, however. For
example, a (valid) Java source-file contains a syntax-tree ( a tree of
nodes ). Similarly, an XML file contains hierarchically nested
elements ( a tree of nodes ), as does DNS. ( This may only be of limited
use ... not all nodes have identity, as they do in filesystems ... but
that does not mean they are not uniquely addressable ... xf: W3C XPath ).
The configuration system for Dan Bernstein's 'djbdns' program opened my
eyes to the patently obvious by example. Whereas the typical thing to
do is to have a 'configuration file' containing multiple entries, DJB
had each atomic value of the configuration file as an operating-system
file.
eg. from an installed dnscache
> find /etc/dnscache/
./env
./env/ROOT
./env/IP
./env/IPSEND
./env/CACHESIZE
./env/DATALIMIT
His programs have levergaged greatly off this type of effect in terms
of their simplicity ( no need to write routines to decompose or validate
the structure of the configuration file, or ensure transaction isolation
of operations on parts of the configuration store ... the OPERATING SYSTEM
handles that! ).
For instance, his qmail program uses a mailbox format called 'maildir'.
Instead of having all mail entries in a single mail file ( the usual
so-called 'MBOX' format ), each email is a file in its own. Additional
semantic information is encoded into the file name ( but only because
the filesystem metaphor is limited in the amount of metadata it can
express ). His system avoids the usual 'locking' issues with mail,
because the mail file never needs to be locked ... it just gets moved
from the 'unread' directory to the 'read' directory when required. New
mail gets placed in the 'unread' directory. Again, leveraging the
operating system.
In applying this idea to the abstract file system, one could insert a
'device driver' that exposed the syntax-tree of a Java file as sub-nodes
of that source-file, for instance, and the operations on the Java file
could have identical effects as operations on a directory tree.
The next step is then to provide a more robust set of facilities that
provides the usual transactional controls of databases as the backing
store behind the abstract file system.
I do not know what this API/system would be called, but I have no doubt
that it would be *extrememely* useful!
Just a few thoughts,
David.
On Mon, 11 Mar 2002, Jaroslav Tulach wrote:
> Hi neal.
>
> > See
> >
> >
<http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/api.htm\
l>
>
> even more rich resources can be found at http://openide.netbeans.org/fs/
>
> > For the kind of API I believe javac should use for its interaction
> > with the file system.
>
> It would be a pleasure for NetBeans to donate the library. Do you consider
using the
> API itself or are you just interested in "the kind" and plan to clone it?
>
> Regards,
> yarda
--
----
David Bullock - dbullock@... +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack
plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
--- In javax_compiler@y..., Jaroslav Tulach <yarda.tulach@c...> wrote:
> It would be a pleasure for NetBeans to donate the library.
> Do you consider using the API itself or are you just interested
> in "the kind" and plan to clone it?
I'd like to see this functionality in the core I/O libraries,
probably in java.nio. I don't think we should use anything
outside the core J2SE libraries in this interface.
I don't see any value in abstracting the abstract syntax trees
into a filesystem API - a direct AST API would make more sense.
But I don't expect to do that in the initial version of this
interface because that is an order of magnitude more complex
than just abstracting the compiler's interface to the outside
world (classpaths, files, diagnostics, etc).
Sure. I guess I was not thinking strictly about the compiler
domain, or the javac compiler in particular. I am kind of envisioning
infrastructure that would assist the makers of software that transformed
trees of nodes, and of software that ordered a sequence of
transformations. It's still a very immature idea ... I was just
wondering what folks thought of it, since the topic came up and
people in this forum might have some appreciation of the line of
thought.
I am sure the world would be very happy with the most common java
compilier making use of an abstract file system. If I was on the Ant
team, I'd be falling over myself with happiness. (I thought there were
a few Ant people on this list, but they seem quiet.)
And yes, the API should be JSR'd so that the API can evolve in step with
JDK releases, instead of independently of JDK releases. This is a major
source of pain with APIs such as SAX, DOM, CORBA etc.
On related matters, what are your own thoughts on the pros/cons of
exposing the AST?
cheers,
David.
On Mon, 11 Mar 2002, neal_gafter wrote:
> I don't see any value in abstracting the abstract syntax trees
> into a filesystem API - a direct AST API would make more sense.
> But I don't expect to do that in the initial version of this
> interface because that is an order of magnitude more complex
> than just abstracting the compiler's interface to the outside
> world (classpaths, files, diagnostics, etc).
--
----
David Bullock - dbullock@... +61 4 0290 1228
http://www.lisasoft.com/ (Architect) http://www.auug.org.au/ (President, SA)
http://www.ajug.org.au/sajug/sa.html (Activist) Sun Cert'd Programmer for Java 2
"The key ingredients of success are a crystal-clear goal, a realistic attack
plan to achieve that goal, and consistent, daily action to reach that goal."
Steve Maguire, "Debugging the Development Process".
> I am sure the world would be very happy with the most common java
> compilier making use of an abstract file system. If I was on the Ant
> team, I'd be falling over myself with happiness. (I thought there were
> a few Ant people on this list, but they seem quiet.)
I'm certainly extremely happy about it, just watching quietly :)
On the other hand, Ant tries to be very backwardly compatible - it'll almost
certainly require 1.2.2 for Ant2, but I don't think we'd want to start requiring
1.5! For that reason, I suspect it won't become a core part of Ant for a long
time, but it could certainly be useful for optional tasks.
In terms of the compiler aspect, I would imagine the Jasper team would be
happier - no need to write out full .java files etc...
Jon
neal_gafter wrote:
> --- In javax_compiler@y..., Jaroslav Tulach <yarda.tulach@c...> wrote:
>
>>It would be a pleasure for NetBeans to donate the library.
>>Do you consider using the API itself or are you just interested
>>in "the kind" and plan to clone it?
>
>
> I'd like to see this functionality in the core I/O libraries,
> probably in java.nio. I don't think we should use anything
> outside the core J2SE libraries in this interface.
I expected that. Does the JCP for this started?
yarda
> >>It would be a pleasure for NetBeans to donate the library.
> >>Do you consider using the API itself or are you just interested
> >>in "the kind" and plan to clone it?
> >
> > I'd like to see this functionality in the core I/O libraries,
> > probably in java.nio. I don't think we should use anything
> > outside the core J2SE libraries in this interface.
>
> I expected that. Does the JCP for this started?
No, but the process for deciding if Sun will start the JSR
for this in the 1.5 timeframe has begun.
-Neal
Clockware is 100% web based time tracking software and Online ASP
service. Its enterprise software provides rules based features for
attendance, project tracking, billing and payroll. For more
information please visit the company's web site at www.clockware.com
Clockware Timesheet the web.
Eliot Miller
eliot.miller@...
866- EZ clock or 408-749-7600
www.clockware.com
I am starting up a new JSR on an API for invoking a Java Language
compiler from within a Java program. That was the original purpose
for the existence of this group. A draft of the JSR proposal is
enclosed. The history of the discussion within this group is listed
as a reference for the definition of the JSR. As you probably know,
this API will be very useful in implementations of an IDE and for JSP
implementations, and it will make it possible for programs to compile
small snippets of Java source code very efficiently.
I'm currently at the stage of gathering support and endorsement to help
this proposal over the initial stages of the JSR process, most
hopefully from large influential Java licensees. Suggestions and
and offers of support are most welcome.
JSR Proposal
Title:
Java(TM) Compiler API
Summary:
A service provider API that allows a Java program to select
and invoke a Java Language Compiler programmatically.
Submitter:
Sun Microsystems
Contact Name:
Neal Gafter
Contact E-Mail:
Neal.Gafter@...
Contact Phone:
408-276-7080
Contact Fax:
408-276-7700
Spec Lead Name:
Neal Gafter
Spec Lead E-Mail:
Neal.Gafter@...
Spec Lead Phone:
408-276-7080
Spec Lead Fax:
408-276-7700
Initial Group Membership:
TBD
Supporting this JSR:
Sun Microsystems
Section 2.1: (Description of the proposed Specification)
The Java Compiler API is a set of interfaces that describes
the functions provided by a Java Language Compiler, and a
service provider framework so vendors can provide
implementations of these interfaces.
The interfaces abstract the way a compiler interacts with its
environment. While the existing command-line versions of
compiler receive their inputs from the file systems and
deposit their outputs there, reporting errors in a single
output stream, the new compiler API will allow a compiler to
interact with an abstraction of the file system. This
abstraction will likely be provided by an extension of the NIO
facilities in Tiger (1.5), and allow users to provide source
and class files (and paths) to the compiler in the file
system, in jar files, or in memory, and allowing the compiler
to deposit its output similarly. Diagnostics will be returned
from a compiler as structured data, with both pre- and
post-localization messages available.
In addition, the new API should provide a facility for a
compiler to report dependency information among compilation
units. Such information can assist an integrated development
environment in reducing the scope of future recompilations.
Future versions of this API might expose more of the structure
of the program, for example the declaration structure of the
program (ala the javadoc API), program annotations (JSR 175)
or even the code itself (ASTs: Abstract Sytntax Trees). These
are not goals of the initial version of this specifications.
Section 2.2: (The target Java platform)
J2SE
Section 2.3: (What need of the Java community will be addressed by the
spec)
The main initial audiences are
(1) JSP implementations, which must invoke a Java
Language compiler on generated Java code
(2) IDE (Integrated Development Environments) which
must process user-written source code
(3) Some internal Java facilities are simplified
by the ability to generate class files efficiently
through generation of source files.
Section 2.4: (Why isn't this met by existing specifications?)
There simply isn't anything like this in the platform.
Section 2.5: (Description of the underlying technologies)
The reference implementation will likely be built on Sun's javac.
Section 2.6: (Proposed package name for the API spec)
javax.compiler
Section 2.7: (Are there any dependencies on OS/CPU/devices?)
No
Section 2.8: (Are there any new security issues?)
No
Section 2.9: (Are there internationalization of localization issues?)
These will be explicitly addressed by the specification.
Section 2.10: (Will any existring specs become obsolete?)
No
Section 2.11: (What is the anticipated schedule for this spec?)
We hope to have the specification completed in time to be
included in the next major revision of the Java platform
(Tiger).
Section 2.12: (What is the working model for the expert group?)
Sun will lead the specification and implementation work, with
experts contributing to the API specification.
Section 3.1: (What existing documents, specs, or implementations
describe the technology?)
See http://groups.yahoo.com/group/javax_compiler for some very
early thoughts.
Sun's javac will likely form the basis of the reference
implementation.
Section 3.2: (How will these be used as a starting point?)
The expert group will consider them as a starting point for
ideas on defining the specification.
Section 4.1: (Additional Information)
Hi Neal,
We (that's the iAnywhere Solutions part of Sybase) would support your
effort.
If you get it through the preliminary red tape, I'd personally be available
to review documents, etc. I'd have a hard time justifying trips to
California for face-to-face meetings.
Our interest is in facilitating builds, which is similar but not identical
to the IDE problem.
Jim Welch
"Neal Gafter"
<Neal.Gafter@s To: javax_compiler@yahoogroups.com
un.com> cc:
Subject: [javax_compiler] New JSR
on Java(TM) Compiler API
10/10/2002
07:10 PM
Please respond
to
javax_compiler
I am starting up a new JSR on an API for invoking a Java Language
compiler from within a Java program. That was the original purpose
for the existence of this group. A draft of the JSR proposal is
enclosed. The history of the discussion within this group is listed
as a reference for the definition of the JSR. As you probably know,
this API will be very useful in implementations of an IDE and for JSP
implementations, and it will make it possible for programs to compile
small snippets of Java source code very efficiently.
I'm currently at the stage of gathering support and endorsement to help
this proposal over the initial stages of the JSR process, most
hopefully from large influential Java licensees. Suggestions and
and offers of support are most welcome.
JSR Proposal
Title:
Java(TM) Compiler API
Summary:
A service provider API that allows a Java program to select
and invoke a Java Language Compiler programmatically.
Submitter:
Sun Microsystems
Contact Name:
Neal Gafter
Contact E-Mail:
Neal.Gafter@...
Contact Phone:
408-276-7080
Contact Fax:
408-276-7700
Spec Lead Name:
Neal Gafter
Spec Lead E-Mail:
Neal.Gafter@...
Spec Lead Phone:
408-276-7080
Spec Lead Fax:
408-276-7700
Initial Group Membership:
TBD
Supporting this JSR:
Sun Microsystems
Section 2.1: (Description of the proposed Specification)
The Java Compiler API is a set of interfaces that describes
the functions provided by a Java Language Compiler, and a
service provider framework so vendors can provide
implementations of these interfaces.
The interfaces abstract the way a compiler interacts with its
environment. While the existing command-line versions of
compiler receive their inputs from the file systems and
deposit their outputs there, reporting errors in a single
output stream, the new compiler API will allow a compiler to
interact with an abstraction of the file system. This
abstraction will likely be provided by an extension of the NIO
facilities in Tiger (1.5), and allow users to provide source
and class files (and paths) to the compiler in the file
system, in jar files, or in memory, and allowing the compiler
to deposit its output similarly. Diagnostics will be returned
from a compiler as structured data, with both pre- and
post-localization messages available.
In addition, the new API should provide a facility for a
compiler to report dependency information among compilation
units. Such information can assist an integrated development
environment in reducing the scope of future recompilations.
Future versions of this API might expose more of the structure
of the program, for example the declaration structure of the
program (ala the javadoc API), program annotations (JSR 175)
or even the code itself (ASTs: Abstract Sytntax Trees). These
are not goals of the initial version of this specifications.
Section 2.2: (The target Java platform)
J2SE
Section 2.3: (What need of the Java community will be addressed by the
spec)
The main initial audiences are
(1) JSP implementations, which must invoke a Java
Language compiler on generated Java code
(2) IDE (Integrated Development Environments) which
must process user-written source code
(3) Some internal Java facilities are simplified
by the ability to generate class files efficiently
through generation of source files.
Section 2.4: (Why isn't this met by existing specifications?)
There simply isn't anything like this in the platform.
Section 2.5: (Description of the underlying technologies)
The reference implementation will likely be built on Sun's javac.
Section 2.6: (Proposed package name for the API spec)
javax.compiler
Section 2.7: (Are there any dependencies on OS/CPU/devices?)
No
Section 2.8: (Are there any new security issues?)
No
Section 2.9: (Are there internationalization of localization issues?)
These will be explicitly addressed by the specification.
Section 2.10: (Will any existring specs become obsolete?)
No
Section 2.11: (What is the anticipated schedule for this spec?)
We hope to have the specification completed in time to be
included in the next major revision of the Java platform
(Tiger).
Section 2.12: (What is the working model for the expert group?)
Sun will lead the specification and implementation work, with
experts contributing to the API specification.
Section 3.1: (What existing documents, specs, or implementations
describe the technology?)
See http://groups.yahoo.com/group/javax_compiler for some very
early thoughts.
Sun's javac will likely form the basis of the reference
implementation.
Section 3.2: (How will these be used as a starting point?)
The expert group will consider them as a starting point for
ideas on defining the specification.
Section 4.1: (Additional Information)
To unsubscribe from this group, send an email to:
javax_compiler-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Jim-
Thanks for your support. I think we will probably do all our business
through email.
-Neal
jim.welch@... wrote:
> Hi Neal,
>
> We (that's the iAnywhere Solutions part of Sybase) would support your
> effort.
>
> If you get it through the preliminary red tape, I'd personally be available
> to review documents, etc. I'd have a hard time justifying trips to
> California for face-to-face meetings.
>
> Our interest is in facilitating builds, which is similar but not identical
> to the IDE problem.
>
> Jim Welch
>
>
>
> "Neal Gafter"
> <Neal.Gafter@s To:
javax_compiler@yahoogroups.com
> un.com> cc:
> Subject: [javax_compiler] New JSR
on Java(TM) Compiler API
> 10/10/2002
> 07:10 PM
> Please respond
> to
> javax_compiler
>
>
>
>
>
> I am starting up a new JSR on an API for invoking a Java Language
> compiler from within a Java program. That was the original purpose
> for the existence of this group. A draft of the JSR proposal is
> enclosed. The history of the discussion within this group is listed
> as a reference for the definition of the JSR. As you probably know,
> this API will be very useful in implementations of an IDE and for JSP
> implementations, and it will make it possible for programs to compile
> small snippets of Java source code very efficiently.
>
> I'm currently at the stage of gathering support and endorsement to help
> this proposal over the initial stages of the JSR process, most
> hopefully from large influential Java licensees. Suggestions and
> and offers of support are most welcome.
>
> JSR Proposal
>
> Title:
> Java(TM) Compiler API
>
> Summary:
> A service provider API that allows a Java program to select
> and invoke a Java Language Compiler programmatically.
>
> Submitter:
> Sun Microsystems
>
> Contact Name:
> Neal Gafter
>
> Contact E-Mail:
> Neal.Gafter@...
>
> Contact Phone:
> 408-276-7080
>
> Contact Fax:
> 408-276-7700
>
> Spec Lead Name:
> Neal Gafter
>
> Spec Lead E-Mail:
> Neal.Gafter@...
>
> Spec Lead Phone:
> 408-276-7080
>
> Spec Lead Fax:
> 408-276-7700
>
> Initial Group Membership:
> TBD
>
> Supporting this JSR:
> Sun Microsystems
>
> Section 2.1: (Description of the proposed Specification)
> The Java Compiler API is a set of interfaces that describes
> the functions provided by a Java Language Compiler, and a
> service provider framework so vendors can provide
> implementations of these interfaces.
>
> The interfaces abstract the way a compiler interacts with its
> environment. While the existing command-line versions of
> compiler receive their inputs from the file systems and
> deposit their outputs there, reporting errors in a single
> output stream, the new compiler API will allow a compiler to
> interact with an abstraction of the file system. This
> abstraction will likely be provided by an extension of the NIO
> facilities in Tiger (1.5), and allow users to provide source
> and class files (and paths) to the compiler in the file
> system, in jar files, or in memory, and allowing the compiler
> to deposit its output similarly. Diagnostics will be returned
> from a compiler as structured data, with both pre- and
> post-localization messages available.
>
> In addition, the new API should provide a facility for a
> compiler to report dependency information among compilation
> units. Such information can assist an integrated development
> environment in reducing the scope of future recompilations.
>
> Future versions of this API might expose more of the structure
> of the program, for example the declaration structure of the
> program (ala the javadoc API), program annotations (JSR 175)
> or even the code itself (ASTs: Abstract Sytntax Trees). These
> are not goals of the initial version of this specifications.
>
> Section 2.2: (The target Java platform)
> J2SE
>
> Section 2.3: (What need of the Java community will be addressed by the
> spec)
> The main initial audiences are
> (1) JSP implementations, which must invoke a Java
> Language compiler on generated Java code
> (2) IDE (Integrated Development Environments) which
> must process user-written source code
> (3) Some internal Java facilities are simplified
> by the ability to generate class files efficiently
> through generation of source files.
>
> Section 2.4: (Why isn't this met by existing specifications?)
> There simply isn't anything like this in the platform.
>
> Section 2.5: (Description of the underlying technologies)
> The reference implementation will likely be built on Sun's javac.
>
> Section 2.6: (Proposed package name for the API spec)
> javax.compiler
>
> Section 2.7: (Are there any dependencies on OS/CPU/devices?)
> No
>
> Section 2.8: (Are there any new security issues?)
> No
>
> Section 2.9: (Are there internationalization of localization issues?)
> These will be explicitly addressed by the specification.
>
> Section 2.10: (Will any existring specs become obsolete?)
> No
>
> Section 2.11: (What is the anticipated schedule for this spec?)
> We hope to have the specification completed in time to be
> included in the next major revision of the Java platform
> (Tiger).
>
> Section 2.12: (What is the working model for the expert group?)
> Sun will lead the specification and implementation work, with
> experts contributing to the API specification.
>
> Section 3.1: (What existing documents, specs, or implementations
> describe the technology?)
> See http://groups.yahoo.com/group/javax_compiler for some very
> early thoughts.
>
> Sun's javac will likely form the basis of the reference
> implementation.
>
> Section 3.2: (How will these be used as a starting point?)
> The expert group will consider them as a starting point for
> ideas on defining the specification.
>
> Section 4.1: (Additional Information)
>
>
>
> To unsubscribe from this group, send an email to:
> javax_compiler-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> javax_compiler-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
The Java(tm) Compiler API has entered the Java Community Process.
It is JSR 199. See
<http://www.jcp.org/en/jsr/detail?id=199>
We are now accepting nominees for experts. If you or your
organization would like to participate in the definition of
this API, please fill out a nomination form on that page.
If your only interest is in following the progress of the expert
group as we work, you can join (or remain on) the mailing list
javax_compiler@yahoogroups.com. To join that list, visit
<http://groups.yahoo.com/group/javax_compiler/>
I expect to post periodic updates on our progress. Otherwise the
mailing list should see very low mail volume. I would like to
keep the expert group small, and include mainly people who will
be either using the API or implementing it. When you fill out
the nomination form, please also describe how you hope use the
API. I expect that the expert group will do most (perhaps all)
of its work by email.
In order to join an expert group, you must be either a JCP member
or be covered under the "Individual Expert Participation Agreement".
For more information, see
<http://www.jcp.org/en/participation/membership>
Regards,
Neal Gafter
All -
I just read the JSR description (199), and it only speaks about source code
compilation.
Do you think it's possible to add to the specification a byte code assembler
and/or an API to give to the users a convenient possibility to analyze,
create, and manipulate (binary) Java class files ?
Preprocessor, aspect oriented framework could use that kind of tool.
There is already a bytecode manipulator in MS.dotNet, and Java developers
have to some external products (opensource or not).
But in my opinion, a bytecode manipulator and/or assembler should be part of
the Java API, some developers and big companies are afraid to use tools that
are not part of the specification.
Do you know if there is already a group working on that specification, do you
think it should be part of this JSR ?
BCEL :
http://jakarta.apache.org/bcel/
Jasmin Assembler :
http://www.cat.nyu.edu/meyer/jasmin/
Jikes BT
http://www.alphaworks.ibm.com/tech/jikesbt
Regards,
--
Cyrille Morvan
IT Student / Orsay / France
(+1) 713-689-5489
--- In javax_compiler@y..., Cyrille Morvan <cmorvan@h...> wrote:
> Do you think it's possible to add to the specification
> a byte code assembler and/or an API to give to the users a
> convenient possibility to analyze, create, and manipulate
> (binary) Java class files ?
I don't think such an API would have anything at all in common with
a Javac compiler API, so I don't think there would be any value in
adding this to JSR#199.
On Wednesday 04 December 2002 17:32, Neal Gafter wrote:
> --- In javax_compiler@y..., Cyrille Morvan <cmorvan@h...> wrote:
> > Do you think it's possible to add to the specification
> > a byte code assembler and/or an API to give to the users a
> > convenient possibility to analyze, create, and manipulate
> > (binary) Java class files ?
>
> I don't think such an API would have anything at all in common with
> a Javac compiler API, so I don't think there would be any value in
> adding this to JSR#199.
In JSR# 198 ( A Standard Extension API for Integrated Development
Environments), they want to do a source code meta model :
" Data Model - The addin will have access to the metadata model for a source
file (Class, method, members, etc.) "
Do you will support this ? To compile the datamodel or create the DataModel ?
A default implementation could just serialize the datamodel into a buffer and
compile it. A more performant implementation could not.
The same, we could have a bytecode datamodel. and the compiler API would be
able to compile everything : bytecode and source code...
Am I stupid ?
javax.compiler.*
javax.compiler.source.*
javax.compiler.bytecode.*
If you don't see any value in adding this to JSR# 199, do you think it
has no value ? Is there anybody who is already working on that ?
--
Cyrille Morvan
IT Student, Orsay, France
> I just read the JSR description (199), and it only speaks about source
code
> compilation.
>
> Do you think it's possible to add to the specification a byte code
assembler
> and/or an API to give to the users a convenient possibility to analyze,
> create, and manipulate (binary) Java class files ?
Before an assembler could be provided, you'd need a standard for JVM
bytecode assembler format. Perhaps the Jasmin format could be adopted, but
there would need to be some official consensus on defining that language.
There hasn't been, of yet.
There is already at least one tool (BCEL, which you mentioned) to do the
latter bit. Perhaps that could become part of the language, too. Again,
though, it's not really related to a language compiler. It might be used in
the implementation of such a language compiler, but I see no connection in
terms of the API.
> There is already a bytecode manipulator in MS.dotNet, and Java developers
> have to some external products (opensource or not).
> But in my opinion, a bytecode manipulator and/or assembler should be part
of
> the Java API, some developers and big companies are afraid to use tools
that
> are not part of the specification.
That's a very poor reason to expand the core API. If any such companies
truly exist (ie, ones that won't use code only because it's outside the core
API), then they will die soon and be replaced by companies with more
reasonable approaches on licensing and applying third-party code. Efforts
to stop this natural evolution of matters are misguided.
> Do you know if there is already a group working on that specification, do
you
> think it should be part of this JSR ?
Not part of this JSR. If you think that the BCEL is useful enough to become
part of the core API, propose it as a new JSR.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Welcome to the discussion group for JSR 199, which will define
a standard interface for Java compilers.
This Yahoo group was previously a public forum for this topic, but
discussion seems to have died down. The list is now moderated. All
(and only) of the members of the JSR 199 expert group are moderators
of this group. Only the members of JSR 199 can post messages to this
group. We expect to carry on our discussions here, so if you're not
on the expert group you can still listen in by remaining subscribed to
this group. You can always send me feedback by private email.
First, two pieces of bad news. First, the Tiger (1.5) release of J2SE
will not include a file system API, which we were depending on.
Second, the folks who define the Tiger release contents have decided
not to drop JSR 199 altogether from Tiger, but to reduce its scope
considerably. For 1.5, the Tiger team wants to have a relaiable way
to invoke javac, without having to depend on any unsupported APIs.
Our first decision was to have our discussion in this public forum.
Our second decision will be whether or not we want to define this
simplified API, or whether we want to focus our attention on the more
complex API that is described in
<http://www.jcp.org/en/jsr/detail?id=199>
If we make the simplified API the goal for JSR 199, then we can
complete our work and ship the result within the next few months and
expect it to go into J2SE 1.5. However, the disadvantage is that we
would have to form a brand new expert group and start a new JSR if we
want to do the more ambitious spec, because the work of the expert
group will have been completed. We could probably do that very easily
with exactly the same set of members, but we would have to go through
the JCP process of proposing a new JSR.
On the other hand, if we focus our attention on the more ambitious
spec, then we cannot expect our work to be included in J2SE until the
1.6 release at the earliest, because that is the soonest we could
expect a filesystem API to be included in J2SE; that is the next
feature release of the platform after Tiger. However, we will be able
to produce public prototypes of our work in the meantime.
I suggest we take a middle road. We should state as the explicit goal
of JSR 199 that we will produce a spec as originally planned.
Meanwhile, we will define the simpler API as an unofficial product of
JSR 199 and I will get it included in Tiger.
I have attached a draft of my recommended simple API. If we go with
something like this, I will make it work with javac, javap, javah,
javadoc, and possibly rmic as well in Tiger.
It's used something like this:
import javax.shell.*;
try {
Command javac = Command.findTool("com.sun.tools.javac");
PrintWriter out = new PrintWriter(System.out);
String[] ags = {"-source", "1.5", "/tmp/Foo.java"};
javac.run(null, out, out, args);
} catch (CommandNotFound ex) {
// appropriate cleanup
}
What do you think?
package javax.shell;
import java.io.PrintWriter;
import java.io.InputStream;
/** A "Command" is a class named "Main" in a package whose name is the
* name of the command. For example, the javac tool is represented
* by class "com.sun.tools.javac.Main" that extends
* javax.shell.Command.
*
* */
public abstract class Command {
/** Run the command with the given I/O channels and arguments. By
* convention the command returns 0 for success and nonzero for
* errors.
*/
public abstract int run(InputStream in, PrintWriter out, PrintWriter err,
String... args);
/** Find the command (Main) for a given command, specified by its
* package name (for example, "com.sun.tools.javac"). */
public static final Command find(String name) throws CommandNotFound {
return find(null, name);
}
/** Find the command (Main) for a given command, specified by its
* class loader and package name (for example,
* "com.sun.tools.javac"). */
public static final Command find(ClassLoader loader, String pack) throws
CommandNotFound {
try {
String clazz = pack + ".Main";
return (Command)((loader == null)
? Class.forName(clazz)
: loader.loadClass(clazz)).newInstance();
} catch (ClassCastException ex) {
throw new CommandNotFound(pack, ex);
} catch (ClassNotFoundException ex) {
throw new CommandNotFound(pack, ex);
} catch (InstantiationException ex) {
throw new CommandNotFound(pack, ex);
} catch (IllegalAccessException ex) {
throw new CommandNotFound(pack, ex);
}
}
private static final ClassLoader getToolLoader() {
// implementation omitted
return null;
}
private static final ClassLoader toolLoader = getToolLoader(); // class
loader for tools.jar
/** Find a tool installed on the platform. */
public static final Command findTool(String pack) throws CommandNotFound {
return find(toolLoader, pack);
}
}
public class CommandNotFound extends Exception {
private final String name;
public CommandNotFound(String name, Throwable cause) {
super("command \'" + name + "\' not found", cause);
this.name = name;
}
public String name() {
return this.name;
}
}
I got the following from Jaroslav Tulach:
> ... I have few comments to your sample code:
>
> 1. When finding the compiler class you should fallback to
> Thread.getContextClassLoader, life of NetBeans will be easier then.
I think this is an excellent idea.
> 2. I suggest to use META-INF/services for registration of compilers. It
> is defacto standard (specified here
>
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Provider%20Configuration%20\
File
>
> our impl and description here http://openide.netbeans.org/lookup/) and
> allows to abstract from the fact that one is communicating with
> com.sun.tools.javac or fastjavac.
This too is a good idea. However, different complers may have completely
different command lines, which means a client may have to be aware of which
compiler is being used.
I've been getting some follow-up messages, but all of them
in private email. Please make a point of sending your replies
to the mailing list (if you're a member of JSR 199). If the
Reply-To field is wrong, I'll see what I can do to fix that.
Sachin Hejip wrote:
> I was wondering about the extent to which we intend to define the simplified
> API itself. From Neal's email it seems that the goal is to be able to invoke
> javac without having any direct reference to the com.sun packages. Can we
> define some of the other abstractions that were mentioned and be included in
> the Tiger release? I think a similar point was raised by Olivier.
The basic constraints are time and resources. To be included in Tiger, we
have to be substantially done with the spec and reference implementation by
August 15. I'm the only engineer working on the compiler for Tiger, and I
still have a lot of work to do before then with all the new language features
going in. As a practical matter, I don't have time to do much beyond what
I sent. If someone else can implement whatever else we can come up with in
that time, then we might be able to use it. Otherwise we'll have to settle
for what I have time to implement.
The middle road approach suits us. The long term story should however
consider existing alternate API, such as the one our Eclipse compiler
provides as of today.
This API isn't officially public yet, but it provides support for
abstracting compilation units, name environments, dependency
information and a few other aspects (like problem reporting).
For the middle road story, having compiler tools be able to process
the command line arguments, is a big improvement over the basic Ant
task compiler adapter approach.
Minor request: would it be possible to abstract the way a compiling
tool could feed a compilation error back ? Something fairly simple
containing a message, a file name and a text range ?
Please, folks: when you reply to an email to this list, edit the
recipient field. It defaults to javax_compiler_owner@yahoogroups.com,
which means it only goes to me. You should reply to
javax_compiler@yahoogroups.com. I don't know if there's anything I
can do to fix it automagically.
Olivier Lefevre wrote:
>>The middle road approach suits us. The long term story should however
>>consider existing alternate API, such as the one our Eclipse compiler
>>provides as of today.
>
>
> Do you have an URL for that API? Preferably a _design_ document, not
> a bunch of Javadocs, please.
>
> How does our chair feel about taking the time to study existing compiler
> APIs before we go beyond the "minimal" program? That might not be a bad
> idea since in the past Sun has been the target of much bitching in similar
> circumstances (as with, e.g., the Logging API).
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 work.
How would you feel about doing this study, proposing something else, and
prototyping it in javac?
>>For the middle road story, having compiler tools be able to process
>>the command line arguments is a big improvement
>
>
> If that is all you want, you can already call
com.sun.tools.javac.Main.compile.
> There are two minor problems with that: the first is that javac used not
> to be reentrant, so you had to use a new Main every time but that has since
> been fixed and anyway that was only a problem if you were not aware of it.
> The second is that the class in question is not a core one, so the story
> may be different with another vendor. The fix for that would be to pull
> javac.Main into the core or else provide a system facility to grab it
> (or a wrapper around it), which is just what Neal Gafter suggested, i.e.,
> his "minimal" program. If we go with that, you won't be able to do
> anything you couldn't already do: you will merely have an assurance that
> it will work across platforms and not just on the Sun VM. Hardly a "big"
> improvement... Or am I missing something?
That's exactly right: the simple API buys you a consistent and portable
way to run the compiler if it's present, and you don't have to worry about
finding the right jar file at compile-time and runtime (which varies from
platform to platform). It also supports the other tools (javah, rmic,
javadoc, etc) if present.
> Please, folks: when you reply to an email to this list, edit the
> recipient field.
Oops, sorry. You may have said this earlier and I may have noted it
but there is so little traffic on this list that I forgot ;-)
>> How does our chair feel about taking the time to study existing compiler
>> 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
> work.
You misunderstood me. I wasn't suggesting that you kill yourself at work:
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, and
> prototyping it in javac?
I don't think I can do that by August 15 either but otherwise I am
willing to try, yes.
Regards,
-- O.L.
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
front.
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.
Sincerly,
Philippe Mulet
Olivier Lefevre
<lefevre@...> To:
javax_compiler@yahoogroups.com
cc:
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
javax_compiler-ow
ner
> Please, folks: when you reply to an email to this list, edit the
> recipient field.
Oops, sorry. You may have said this earlier and I may have noted it
but there is so little traffic on this list that I forgot ;-)
>> How does our chair feel about taking the time to study existing compiler
>> 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
> work.
You misunderstood me. I wasn't suggesting that you kill yourself at work:
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, and
> prototyping it in javac?
I don't think I can do that by August 15 either but otherwise I am
willing to try, yes.
Regards,
-- O.L.
To unsubscribe from this group, send an email to:
javax_compiler-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Send Email
