PROPOSAL: Byte and Short Integer Literal Suffixes

Bruce Chapman brucechapman at
Wed Mar 25 01:59:43 PDT 2009

TITLE: Byte and Short Integer Literal Suffixes

latest html version at

AUTHOR(S): Bruce Chapman


Problems occur when trying to create literal byte values for known bit
patterns because byte is signed therefore 0x80 thru 0xFF are not valid
byte values.

Working with bytes (binary files, network communications) can be
simplified by allowing byte size integer literals (and short for
consistency). Specifically allow hexadecimal byte literals, others for


Allow byte and short integer literals by introducing 4 new integer type
suffixes 'y' & 'Y' for bytes, 's' & 'S' for shorts.


Somewhat reduces the pain resulting from byte being a signed type,
removes the need to downcast integer literals to byte or short.

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

cruddy code like

     byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};

can be recoded as

     byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };


Some familiarisation curve required before the syntax stops looking
slightly odd.

Would prefer to but cannot use 'B' as Integral type suffix because it is
a hexadecimal digit, 'Y' can be used but is slightly esoteric, but
probably no more so than 'X' for hexadecimal prefix.


An alternative language change would be to have hexadecimal integer
literals that are typed according to the number of digits.

Show us the code!

     byte[] utf8bom7 = { 0xEFy, 0xBBy, 0xBFy };


     byte[] buffer = ...;

     if(buffer[i] == 0xBBy) { // never equal with 0xBB




"3.10.1 Integer literals" is amended  as follows - additions in bold.

     IntegerTypeSuffix: one of
     l L y Y s S

     An integer literal is of type long if it is suffixed with an ASCII
letter L or l (ell), of type short if it is suffixed with an ASCII
letter S or s and of type byte if it is suffixed with an ASCII letter Y
or y; otherwise it is of type int (§4.2.1).  For long literals the
suffix L is preferred, because the letter l (ell) is often hard to
distinguish from the digit 1 (one).

and at the end of 3.10.1 add

     A compile-time error occurs if a decimal literal of type short is
larger than  32767 (215), or if the literal 32767 appears anywhere other
than as the operand of the unary - operator, or if a hexadecimal or
octal short literal does not fit in 16 bits.

     A compile-time error occurs if a decimal literal of type byte is
larger than  128 (27), or if the literal 128 appears anywhere other than
as the operand of the unary - operator, or if a hexadecimal or octal
byte literal does not fit in 8 bits.

COMPILATION: How would the feature be compiled to class files? Show how
the simple and advanced examples would be compiled. Compilation can be
expressed as at least one of a desugaring to existing source constructs
and a translation down to bytecode. If a new bytecode is used or the
semantics of an existing bytecode are changed, describe those changes,
including how they impact verification. Also discuss any new class file
attributes that are introduced. Note that there are many downstream
tools that consume class files and that they may to be updated to
support the proposal!

TESTING: How can the feature be tested?


No library support required.

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need
to be updated? This list of reflective APIs includes but is not limited
to core reflection (java.lang.Class and java.lang.reflect.*),
javax.lang.model.*, the doclet API, and JPDA.

OTHER CHANGES: Do any other parts of the platform need be updated too?
Possibilities include but are not limited to JNI, serialization, and
output of the javadoc tool.

MIGRATION: Sketch how a code base could be converted, manually or
automatically, to use the new feature.

BREAKING CHANGES: Are any previously valid programs now invalid? If so,
list one.

EXISTING PROGRAMS: How do source and class files of earlier platform
versions interact with the feature? Can any new overloadings occur? Can
any new overriding occur?

EXISTING BUGS: Please include a list of any existing Sun bug ids related
to this proposal.


More information about the coin-dev mailing list