So you want to change "javac" ...
javac is an important component of the Java and OpenJDK ecosystem. Changes, especially new features cannot be undertaken lightly, as they imply a commitment on the part of Oracle to supporting that feature going forward.
If you still think you want to change javac, read on ...
So you want to change the Java language...
This is not the place to start. The language is specified by the Java Language Specification (JLS). Changing the JLS can only be done by an "umbrella" JSR which defines the Java SE platform as a whole. Even Sun cannot introduce JSRs to change the JLS whenever it feels like it. In practice, an umbrella JSR which desires new language features will spawn further JSRs so the right people can work in focused Expert Groups to design the features.
Bear in mind that almost everything you see in the Java language is the result of an Expert Group's deliberations (e.g. JSR 175, JSR 201). Some language features that are requested over and over were considered in detail by an EG and explicitly rejected (e.g. Iterators in enhanced-for). The chances of Sun supporting such features now are essentially nil.
For private experiments, check out KSL and also Joe Darcy's blog entry "So you want to change the Java Programming Language...". If you want to go beyond that stage, and have a JSR approved, the next step would be to create an OpenJDK project to host your prototype. Projects normally have to be sponsored by an OpenJDK group, and once a JSR has been approved, the Compiler Group would normally be open to sponsor a language-oriented project. If the language work is a part of a larger project, it might be more appropriate for another group to sponsor the project.
So you want to add or improve a feature to javac...
Your feature may change the language without you realizing it. Adding a new keyword is changing the language. Changing how assignment and casts work is changing the language. Allowing a program that uses complicated generic types to compile when it doesn't compile today is probably changing the language. It's hard to give complete guidance but in general, a feature which depends on knowing the type of an expression is almost certainly a language change. See the previous section if you think your feature might cause a change to the language.
Even if you don't change the language, it is still a
Medium Big Deal to change any of the public
specifications of the compiler. The specs include:
- JLS, for the input language
- JVMS, for the output classfile format
- JSR 199, for the Compiler API (javax.tools.*)
- JSR 269, for the Language Model API (javax.lang.model.*)
- man pages and guides on java.sun.com for command line options
- API docs on java.sun.com for Sun-supported API (com.sun.source.*, for example)
Basically, if it is an observable feature that people may be expected to rely on, then it should be covered by a public specification, and will need some appropriate degree of review and approval to change it.
Some features may be observable but not formally covered by a specification, such as the details of individual diagnostic error messages. Adding or changing such a feature (such as improving diagnostics) is not such a Big Deal.
So you want to fix a bug in javac...
First, check it really is a bug. If it involves a language feature, check against the Third Edition of the JLS (and if necessary the Second Edition of the JVMS). By default, assume that these specifications are correct. If you think you have found an error in JLS or JVMS, start by filing a bug against (category) java, (subcategory) specification.
If you get to change "javac", what do you have to do...
- Make sure there is an issue (bug/RFE) filed at bugs.sun.com under "java"/"compiler" for tracking purposes.
- See The OpenJDK Developers' Guide for general info about OpenJDK procedures and processes.
- All bug fixes require regression tests. All features require unit tests. These are both covered by the Regression Test Harness for the OpenJDK platform: jtreg.
- All language changes require JCK tests. We'll tell you more if and when you get that far ...