—
« One more interview | Main | JavaOne 2007 »

Search

Categories

Links

Referers

Today's Page Hits: 316

Who Need a Java Compiler API?

Apr 12 2007, 02:04:21 PM PDT »Java»Compiler Comments [8]

I was recently interviewed by Jan for java.sun.com; where I said: Although most developers do not want to know how to use the Java Compiler API, it will provide a lot of indirect benefits. This was discussed on comp.lang.java.programmer, and I think it may have been misunderstood.

99% of Java developers will newer need to know anything about the Java Compiler API (JSR 199). A small number of Java developers will use the API directly. However, the software these few developers make is used by all Java developers. I'm talking about software such as IDEs (NetBeans, Eclipse, IntelliJ IDEA, etc), Java EE application server, build infrastructures such as Maven and Ant, and test frame works. All these pieces of software have one thing in common: they all need to invoke a compiler to translate Java source code to class files. However, 99% of all developers will not and should not care about how the compiler is invoked.

The compiler API becomes interesting for all developers when we start measuring build times in milliseconds instead of seconds (when you invoke Ant from NetBeans), or when start measuring deployment time in seconds, not minutes. These are the indirect benefits you will all notice, without learning how to use the API, as soon as your favorite tool migrates to the API.

If questions about the compiler API ever shows up on a Java certification exam, please have the examiners call me and I'll set them straight ;-)

That being said, if you are interested in compiler technology and want to hack on the compiler, please come and join us at https://openjdk.dev.java.net/compiler/.

Post a Comment:
Comments are closed for this entry.
Comments:

Hi, Peter at this very moment the JC API is not yet in my concerns (and telling the truth, still I've not read the specs), but within a month I'll be involved with a project where we need to dynamically produce bytecodes. The textual code comes via tcp, in subsequent and independent compilation units, that is each network message has to be transformed in memory to Java bytecodes and executed, therefore we can't follow the usual compilation flow, as nothing is ever saved on disk. My first thought went to ASM, but I'd like to know whether, in your opinion, the JC API could satisfy as well the above requirements. thanks in advance

Posted by Lucio Biondi on April 13, 2007 at 10:15 AM PDT #

That is exactly what the Compiler API is for. See https://openjdk.dev.java.net/source/browse/openjdk/compiler/trunk/test/tools/javac/api/evalexpr/

Posted by Peter von der Ahé on April 13, 2007 at 10:26 AM PDT #

Just downloaded the openjdk from svn. Thanks for the link. It was posted just two days ago ;)

Posted by Lucio Biondi on April 13, 2007 at 10:50 AM PDT #

No, the timestamps are messed up due to how we bridge from our internal version control system to the read-only subversion on openjdk.dev.java.net.

Posted by Peter von der Ahé on April 13, 2007 at 10:54 AM PDT #

Hello Peter. IMHO, JSR 199 is a very limited approach for meta-programming. Limited from two sides - initial input (which must match java syntax) and operations with java AST only. Of cause, such a limited meta-programming is much better then nothing. But it's a tendency in Java - asserts instead of work-by-contract, erased generics instead of run-time type parameters and so on...

Posted by Maxim Kizub on April 17, 2007 at 08:22 PM PDT #

Maxim,

It is true to say that the meta-programming approach of JSR 199 is limited. Which I think is fine since JSR 199 is not about meta-programming. You use JSR 269 and com.sun.source.* for meta-programming.

I think you are confusing meta-programming of the Java programming language with a general framework for building compiler.

Anyways, you should ask yourself: "do I want to be obnoxious, or do I want to influence what becomes available in future version?"

Posted by Peter von der Ahé on April 17, 2007 at 08:38 PM PDT #

Having a Java Compiler API is a great advance. Thanks. Why not also adding the front-end of a compiler phase into JDK ? The Java Compiler API could be bigger while playing with other tools.

Let's take an example. OCaml is one language I really like and I have already written mostly here about how C# and Java look like moving towards it. OCaml distribution includes ocamllex and ocamlyacc. Then, it is easier to build DSL using OCaml. OK, using ANTLR could already be done within Java space. But, adding such a ANTLR-like to the JDK would enhance the "Java as platform" message.

What do you think about it ?

Posted by Dominique De Vito on April 23, 2007 at 10:59 PM PDT #

Hi Peter!
I'd like to introduce another use case for the Compiler API (and I am really thankful that there is this API). I developed Modern Jass which is a novel Design by ContractTM implementation for Java. It is based on Java 5 Annotations, the Annotation Processing API, and the Compiler API. The latter two are used to validate contracts while Javac runs - JSR 269 is used to participate in the compilation process and JSR 199 is used to validate/compile expression like @Pre("obj != null"). Under the hood some transformations are performed, e.g. <code>@Pre{"obj != null")</code> will be transformed to <code>boolean pre$1(Object obj){ return obj != null; }</code> before passing to the compiler.

Alltogether, Modern Jass does not only offer a rich set of features, but it is very easy to use (annotations), integrates seamlessly (annotation processing/java agents), and it is cheap to maintain (compiler API).

cheers, johannes - modernjass.sourceforge.net

Posted by Johannes Rieken on May 10, 2007 at 02:03 AM PDT #

Java is a trademark of Sun Microsystems, Inc.
Copyright © 2006,2007 Peter von der Ahé