project coin: byte and short integral literals

[joe.darcy at oracle.com]

Hi Bruce.

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 
the thread
http://mail.openjdk.java.net/pipermail/coin-dev/2009-May/001929.html

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:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002088.html

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, 
http://blogs.sun.com/darcy/entry/project_coin_string_switch_anatomy) 
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.

Cheers,

-Joe


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 :) ?
>
> thanks
>
>
> (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).
>
> regards
>
>
> Bruce
>