PROPOSAL: Byte and Short Integer Literal Suffixes (original) (raw)

Bruce Chapman brucechapman at paradise.net.nz
Wed Mar 25 01:59:43 PDT 2009

TITLE: Byte and Short Integer Literal Suffixes

latest html version at http://docs.google.com/Doc?docid=dcvp3mkv_0fvz5gx7b&hl

AUTHOR(S): Bruce Chapman

OVERVIEW

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 completeness.

FEATURE SUMMARY:

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

MAJOR ADVANTAGE:

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 };

MAJOR DISADVANTAGE:

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.

ALTERNATIVES:

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

EXAMPLES Show us the code! SIMPLE EXAMPLE:

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

ADVANCED EXAMPLE:

 byte[] buffer = ...;

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

    ...

 }

DETAILS SPECIFICATION:

"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?

LIBRARY SUPPORT:

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.

COMPATIBILITY 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?

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

URL FOR PROTOTYPE (optional):

More information about the coin-dev mailing list