project coin: byte and short integral literals
joe.darcy at oracle.com
joe.darcy at oracle.com
Thu Apr 22 19:03:39 PDT 2010
Sorry for the belated reply.
A few points here. Most fundamentally, my latest thinking on how the
problem of "the byte type is signed" should be addressed is with
unsigned integer literals with a trailing "u" suffix, as discussed in
However, it is good to have prototypes of other approaches to gain
experience with them. I haven't fully fleshed out what the "u" proposal
would look like; I think a new "unsigned constant" would be defined in
JLSv3 15.28 along with new widening/narrowing unsigned primitive
conversions. Widening conversion would zero extend rather than sign
extend; the most worked-through exposition of this approach is at:
In any case, in terms of the logistics of getting a change to javac
back, we generally use the webrev script
(http://blogs.sun.com/jcc/resource/webrev) to generate a webrev, a
series of html pages with different styles of diffs, to highlight the
change and facilitate the review. Once you have an OpenJDK id, you can
upload files like webrevs to http://cr.openjdk.java.net/ so there is a
standard place to host them.
As you may have already seen, one of my blog entries about strings in
switch (Project Coin: Anatomy of adding strings in switch to javac,
discusses some of the development guidelines we follow in evolving javac
and writing tests.
The compiler generally uses fairly fine-grained allowFoo methods and I
would strongly discourage use of project names likes "Coin" in the
method names. If a few years when Project Coin is a distant memory, the
name would distract rather than enlighten.
On 4/12/2010 3:21 AM, Bruce Chapman wrote:
> I have a working implementation of byte and short integral literals in
> my mercurial repository ready to export a change set (almost).
> I have just filed an RFE for this so that I can have the bug number to
> put in my jtreg tests, which is the last change I want to make before
> exporting the change set. (I presume we are using the bugs.sun.com
> database and not openJDK bugzilla system which seems to be empty)
> I need three things to proceed:
> 1) A mentor to hold my hand and review and commit the changes.
> 2) Someone (see 1) to accept the rfe so I have a bug number ( no review
> id yet)
> 3) One last question answered:
> Do we want 3/4 separate boolean features in code.Source and
> parser.Scanner for the coin integral literals stuff as at present
> (Scanner in my repository currently has...
> allowBinaryLiterals = source.allowBinaryLiterals();
> allowUnderscoresInLiterals = source.allowBinaryLiterals();
> allowShortLiterals = source.allowShortLiterals();
> allowByteLiterals = source.allowByteLiterals();
> or should I roll these all into one omnibus feature
> "allowIntegralLiteralEnhancements" (possibly put "Coin" into the name)
> or do what binary literals and underscores already do (see above) and
> mix the meanings, 2 in source and 4 in scanner (heaven forbid :) ?
> (merged updated integral literal omnibus proposal is next on my todo -
> have some marked up edits to do then will post to coin mailing list in
> next few days).
More information about the compiler-dev