PROPOSAL: Binary Literals
Reinier Zwitserloot
reinier at zwitserloot.com
Wed Mar 25 20:46:38 PDT 2009
In regards to j2me: j2me is on its way out, and will not be receiving
many updates regardless, because sun can't exactly update the java
version on the billions of phones out there.
On performance: I don't understand. The result of a library call is a
byte primitive, which you can then assign to a private static final
byte constant. From there on out, that will be as fast as a code
literal. Unless you were planning on using a few million binary
literals in your code, there shouldn't be a performance impact; just
an annoyance that you have to constantize every literal you use in a
time sensitive area instead of using Byte.of("01000100") directly in
your method body.
The odds that "0b01000100", where you've added a zero too many (or
left one out) is going to result in a compile time error seems odd.
Why would that cause a compile time error, exactly?
Evidently that wasn't clear, but my reference to "real programmers
think in hex since they are A years old" was intended as a joke. I
apologize if that wasn't obvious.
How many bits are set in 0x4EC6? 8. I was able to count that about as
quickly as with 0b0100111011000110. Shame we didn't bet on it.
Quick: How many nibbles are in 0b0100111011000110? How many bits are
set in the upper byte?
There are a select few questions that are just easier when written out
in binary, even if that results in a massive amount of digits, such as
finding contiguous sequences of bits (the packing into nibbles gets in
the way for that kind of thing). Which is why I said that
Byte.of("01000100") is a good idea.
The theory of 'those who don't care can just ignore it' has a
fundamental flaw: It leads to readable-only-by-author code. Grab some
perl example code and try to ascertain what it's trying to do. I wish
you good luck!
Optimally speaking, every language feature is at least somewhat
familiar to every programmer of that language. Java is a few steps
beyond that already (see the Java Puzzlers for proof), but that
doesn't mean we should no longer care about that tenet anymore. Such a
feature should introduce extremely significant improvements in a niche
area, and/or allow you to things that you just can't do now. This
clearly isn't the case.
Speaking of 'things that you just can't do now', for bit wrangling and
performance, I'd love to see a Math.* library that foregoes exact spec
precision and trades it for raw speed. Right now java Math.* can't use
the gfx pipelines because those don't use quite the same floating
point spec that java docs say they should. Just to give an example of
a change that I would wholeheartedly support even if it is extremely
niche.
--Reinier Zwitserloot
On Mar 26, 2009, at 03:55, Derek Foster wrote:
> I am all for the addition of library methods to handle bit/byte/word/
> whatever munging. I plan to submit proposals for a few myself once
> the opportunity arises.
>
> However, library methods only cover a small subset of the use cases
> my proposal was intended to address. In my proposal, I specifically
> discussed the use of a library method and explained why it was not
> an acceptable substitute. I pointed out the performance impact of
> library calls, and noted that in the cases where low-level
> programming is most needed (in severely resource-constrained
> devices, J2ME, and so forth) that having library calls all over the
> place just to translate numbers from a readable form poses an
> unacceptable overhead in terms of performance, code size, and
> maintainability, not to mention the fact that bugs end up appearing
> at runtime (if you happen to run the code in _just_ the right way)
> rather than at compile time. I also pointed out the impossibility of
> using 'switch' statements with such techniques.
>
> With regards to the issue of "real programmers think in hex", by the
> way, I should point out that I started writing assembly language
> programs starting in sixth grade, and that that was around thirty
> years ago. Apparently even though I've been doing both high-level
> (Java, etc.) and low-level (assembly and occasional hand-coded
> machine language) programming for most of my life, I'm not a 'real
> programmer' because I use decimal, hex, binary, and even on some
> rare occasions, octal in the circumstances where they seem
> appropriate, rather than sticking religiously to hex regardless of
> the circumstance. (This is ridiculous, of course: Real Programmers
> don't really use hex. They program core memory using front-panel
> switches, in binary. Or possibly using punched cards if they are
> feeling a need for luxury.)
>
> In my experience, *real* "Real Programmers" use the appropriate tool
> for the job they are doing at the moment. Hex is simply not the
> appropriate tool for all jobs. It's great to use when it is
> appropriate (like when data lines up nicely on four-bit boundaries,
> or when the specification you are working from states its important
> numbers in hex), but it is extremely inconvenient to use hex the
> situations where it's not appropriate. Having to translate back and
> forth between hex and binary all the time when what you really want
> to do are fundamental binary operations (which are easily and
> clearly expressed in binary, and easily checkable against the
> relevant specifications documents which specify them in binary), is
> a waste of time and a rich source of bugs.
>
> Quick: How many bits are set in the number 0x4EC6?
>
> If the number were written in binary, you would be able to answer it
> as fast as you can count to eight. I'll bet you can't do it half
> that fast when it's expressed in hex.
>
> Here's a few more to contemplate:
>
>
> How many contiguous bit ranges exist in the number 0x5FF99C? What
> are their starting offsets?
>
> What will be the result of XORing together 0x4DE6 and 0x3837?
>
> Will 0x8567124 and 0x7218DB, ANDed together, be nonzero?
>
> What's the index of the fifth-highest set bit in the number 0x4687?
>
>
> All of the above questions are easy and quick to answer in binary,
> but difficult and error-prone in hex. In fact, the most difficult
> part of answering them in hex isn't answering the problem -- it's
> translating the hex to binary so the problem can be solved! When I
> am doing code review, I don't want "difficult and error prone". I
> want simple, direct, and mapping as directly to the specification I
> am implementing as possible.
>
> For a recent job, I had to deal with writing a decompiler for a
> processor which had lots of bitfields that didn't fall on nice even
> nybble boundaries, but instead often straddled them and had strange
> widths (3 bits, 9 bits, etc.). Furthermore, there were often
> multiple noncontiguous ranges of bits that had to be merged into the
> same field. Using hex numbers for this kind of situation makes the
> code all but unreadable without close study, and basically required
> that the size of the code be doubled due to all the extra named
> hexadecimal constants (for shifting, bit masking, and so forth) plus
> the comments needed to explain what the heck the code was doing,
> since its structure no longer directly expressed the problem it was
> trying to solve as stated in the specification. In most cases, I
> ended up having to write the binary representations of the numbers
> as comments alongside the hex translations of them, and then
> manually check the two against each other, just so I could later a
> lso manually check the binary numbers in my comments against the
> printed specification.
>
> Then I wrote and ran unit tests and found that even though I had
> manually verified the translations, I had still made a mistake. (Not
> too bad considering that I was translating a couple of hundred
> numbers in my head).
>
> I have recently had the occasion to do programming for
> microcontrollers in GCC, and was able to use the binary literal
> support provided by that compiler. It was so easy to use, and made
> the code so much clearer, that I found myself wondering again why I
> have to give up this feature when I move to the supposedly more
> convenient Java language.
>
> Why should programmers have to waste their time translating between
> hex and binary, when this is trivial for a compiler to do, and is
> considered a common enough need that multiple programming languages
> already support it?
>
> The effort to support this in a Java compiler is tiny, it fits well
> with the rest of the language and is similar to features in other
> languages. It won't break any existing code, and it is easy for
> those who don't want to use it to ignore it.
>
> Derek
>
> -----Original Message-----
>> From: Reinier Zwitserloot <reinier at zwitserloot.com>
>> Sent: Mar 25, 2009 7:47 PM
>> To: Stephen Colebourne <scolebourne at joda.org>
>> Cc: coin-dev at openjdk.java.net
>> Subject: Re: PROPOSAL: Binary Literals
>>
>> Good points. Another useful method:
>>
>> public class Byte {
>> public static byte withBitsSet(int... positions);
>> public static byte withBitsCleared(int... positions);
>> public static byte of(String bitString);
>> }
>>
>> where setBits starts with 0 and then turns on the bit at each listed
>> position, and clearBits starts with -1 and turns off the bit at each
>> listed position.
>>
>> 0x1C can then be implemented as:
>>
>> Byte.withBitsSet(4, 3, 2);
>> Byte.withBitsCleared(7, 6, 5, 1, 0);
>> Byte.of("00011100");
>>
>>
>> That WOULD be a useful library addition. Not only are they almost as
>> short as the proposed byte literal, anybody that doesn't have the
>> first clue about bit masking can at least find some javadoc this way
>> and learn. They would be awfully slow compared to a literal, but
>> presumably any literal needs to be calculated only once, so any
>> slowness in the methods should never have a measurable impact. It's a
>> shame the JVM can't memoize, though.
>>
>>
>>
>> --Reinier Zwitserloot
>>
>>
>>
>> On Mar 25, 2009, at 23:17, Stephen Colebourne wrote:
>>
>>>> A couple of quick notes:
>>>>
>>>> 1) Ruby already has this. (The underscores in numbers, that is)
>>>
>>> So, does Fan. Yes, someone should write up underscores in numbers
>>> as a
>>> separate proposal. It won't be me.
>>>
>>>
>>>> Of all low impact coin submissions, this just isn't very
>>>> compelling.
>>>> Real Programmers can count in hexadecimal ever since they were A
>>>> years
>>>> old, after all.
>>>
>>> Actually, my experience suggests that lots can't count in hex - we
>>> have
>>> calculators and the internet we that kind of thing these days.
>>>
>>> There are definitely use cases for this too, but they occur
>>> relatively
>>> rarely. For example, I once encoded the 30 year repeating pattern of
>>> leap years in the Islamic calendar system as a binary. This was a
>>> mess
>>> to write:
>>>
>>> Years to encode: 2, 5, 7, 10, 13, 16, 18, 21, 24, 26 & 29
>>>
>>> Final int value: 623191204
>>>
>>> Binary literal: 0b00010010_10010010_10010010_01010010
>>>
>>> It is also beneficial in teaching.
>>>
>>> But the truth is it will always be low priority (mind you, I'd have
>>> placed it higher than hexadecimal floating point literals...)
>>>
>>> Stephen
>>>
>>>
>>>
>>>
>>> Reinier Zwitserloot wrote:
>>>> Of all low impact coin submissions, this just isn't very
>>>> compelling.
>>>> Real Programmers can count in hexadecimal ever since they were A
>>>> years
>>>> old, after all.
>>>>
>>>> --Reinier Zwitserloot
>>>>
>>>>
>>>>
>>>> On Mar 25, 2009, at 20:35, Gaseous Fumes wrote:
>>>>
>>>>> A couple of quick notes:
>>>>>
>>>>> 1) Ruby already has this. (The underscores in numbers, that is)
>>>>>
>>>>> 2) I considered adding this to the proposal as I was writing it,
>>>>> but
>>>>> decided it was an orthogonal issue and deserved its own proposal,
>>>>> since it has nothing per se to do with binary literals. (As James
>>>>> mentions, it would make sense for all numbers, not just binary
>>>>> ones.)
>>>>>
>>>>> 3) I encourage someone else to write it up as a proposal. If I get
>>>>> done with the other proposals I intend to submit, and still have
>>>>> time, I might do it myself, but if you want to ensure that the
>>>>> proposal gets proposed, I suggest you don't wait for me. One
>>>>> caveat:
>>>>> Consider the impact on Integer.parseInt, Long.decode(), etc. (I
>>>>> suggest the decode methods get changed to accept underscores, but
>>>>> the parseInt ones don't.)
>>>>>
>>>>> 4) An observation to Joe Darcy and the other Sun engineers
>>>>> involved
>>>>> in reviewing proposals: The expected "about five" limit on
>>>>> proposals
>>>>> really encourages people to lump a bunch of semi-related things
>>>>> into
>>>>> one proposal rather than making each their own proposal, even when
>>>>> the latter would be a more logical way of getting individual
>>>>> orthogonal ideas reviewed separately. I think this is a problem.
>>>>>
>>>>> For instance, the "null safe operators" proposal (all or nothing)
>>>>> vs. splitting each of them out as individual proposals. There have
>>>>> been a number of proposals put forth where I thought "I agree with
>>>>> half of this proposal and wish the other half wasn't in the same
>>>>> proposal."
>>>>>
>>>>> I hope that the "about" in "about five" is flexible enough to
>>>>> allow
>>>>> a bunch of very minor proposals to expand that limit well past
>>>>> five
>>>>> if they seem good ideas and easy to implement with few
>>>>> repercussions. Five seems like a pretty low number to me, given
>>>>> that
>>>>> it's been MANY years since it was even possible for users to
>>>>> suggest
>>>>> changes to Java (basically, since JDK 5 was in the planning
>>>>> stages,
>>>>> as JDK 6 was announced to be a "no language changes" release), and
>>>>> there has been much evolution in other programming languages
>>>>> during
>>>>> that time. I think that good ideas should make it into Java (and
>>>>> bad
>>>>> ideas shouldn't) subject to the necessary manpower in review and
>>>>> implementation, regardless of the number of proposals used to
>>>>> submit
>>>>> them. Otherwise, Java risks getting left in the dust as other
>>>>> languages become much easier to use, much faster.
>>>>>
>>>>> Derek
>>>>>
>>>>> -----Original Message-----
>>>>>> From: james lowden <jl0235 at yahoo.com>
>>>>>> Sent: Mar 25, 2009 12:07 PM
>>>>>> To: coin-dev at openjdk.java.net
>>>>>> Subject: Re: PROPOSAL: Binary Literals
>>>>>>
>>>>>>
>>>>>> Actually, that's a good idea in general for long numeric
>>>>>> constants. 9_000_000_000_000_000L is easier to parse than
>>>>>> 9000000000000000L.
>>>>>>
>>>>>>
>>>>>> --- On Wed, 3/25/09, Stephen Colebourne <scolebourne at joda.org>
>>>>>> wrote:
>>>>>>
>>>>>>> From: Stephen Colebourne <scolebourne at joda.org>
>>>>>>> Subject: Re: PROPOSAL: Binary Literals
>>>>>>> To: coin-dev at openjdk.java.net
>>>>>>> Date: Wednesday, March 25, 2009, 1:50 PM
>>>>>>> See
>>>>>>> http://www.jroller.com/scolebourne/entry/changing_java_adding_simpler_primitive
>>>>>>> for my take on this from long ago.
>>>>>>>
>>>>>>> In particular, I'd suggest allowing a character to
>>>>>>> separate long binary strings:
>>>>>>>
>>>>>>> int anInt1 = 0b10100001_01000101_10100001_01000101;
>>>>>>>
>>>>>>> much more readable.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>> 2009/3/25 Derek Foster <vapor1 at teleport.com>:
>>>>>>>> Hmm. Second try at sending to the list. Let's see
>>>>>>> if this works. (In the
>>>>>>>> meantime, I noticed that Bruce Chapman has mentioned
>>>>>>> something similar in his
>>>>>>>> another proposal, so I think we are in agreement on
>>>>>>> this. This proposal
>>>>>>>> should not be taken as to compete with his similar
>>>>>>> proposal: I'd quite like
>>>>>>>> to see type suffixes for bytes, shorts, etc. added to
>>>>>>> Java, in addition to
>>>>>>>> binary literals.) Anyway...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Add binary literals to Java.
>>>>>>>>
>>>>>>>> AUTHOR(S): Derek Foster
>>>>>>>>
>>>>>>>> OVERVIEW
>>>>>>>>
>>>>>>>> In some programming domains, use of binary numbers
>>>>>>> (typically as bitmasks,
>>>>>>>> bit-shifts, etc.) is very common. However, Java code,
>>>>>>> due to its C heritage,
>>>>>>>> has traditionally forced programmers to represent
>>>>>>> numbers in only decimal,
>>>>>>>> octal, or hexadecimal. (In practice, octal is rarely
>>>>>>> used, and is present
>>>>>>>> mostly for backwards compatibility with C)
>>>>>>>>
>>>>>>>> When the data being dealt with is fundamentally
>>>>>>> bit-oriented, however, using
>>>>>>>> hexadecimal to represent ranges of bits requires an
>>>>>>> extra degree of
>>>>>>>> translation for the programmer, and this can often
>>>>>>> become a source of errors.
>>>>>>>> For instance, if a technical specification lists
>>>>>>> specific values of interest
>>>>>>>> in binary (for example, in a compression encoding
>>>>>>> algorithm or in the
>>>>>>>> specifications for a network protocol, or for
>>>>>>> communicating with a bitmapped
>>>>>>>> hardware device) then a programmer coding to that
>>>>>>> specification must
>>>>>>>> translate each such value from its binary
>>>>>>> representation into hexadecimal.
>>>>>>>> Checking to see if this translation has been done
>>>>>>> correctly is accomplished
>>>>>>>> by back-translating the numbers. In most cases,
>>>>>>> programmers do these
>>>>>>>> translations in their heads, and HOPEFULLY get them
>>>>>>> right. however, errors
>>>>>>>> can easily creep in, and re-verifying the results is
>>>>>>> not straightforward
>>>>>>>> enough to be done frequently.
>>>>>>>>
>>>>>>>> Furthermore, in many cases, the binary representations
>>>>>>> of numbers makes it
>>>>>>>> much more clear what is actually intended than the
>>>>>>> hexadecimal one. For
>>>>>>>> instance, this:
>>>>>>>>
>>>>>>>> private static final int BITMASK = 0x1E;
>>>>>>>>
>>>>>>>> does not immediately make it clear that the bitmask
>>>>>>> being declared comprises
>>>>>>>> a single contiguous range of four bits.
>>>>>>>>
>>>>>>>> In many cases, it would be more natural for the
>>>>>>> programmer to be able to
>>>>>>>> write the numbers in binary in the source code,
>>>>>>> eliminating the need for
>>>>>>>> manual translation to hexadecimal entirely.
>>>>>>>>
>>>>>>>>
>>>>>>>> FEATURE SUMMARY:
>>>>>>>>
>>>>>>>> In addition to the existing "1" (decimal),
>>>>>>> "01" (octal) and "0x1"
>>>>>>>> (hexadecimal) form of specifying numeric literals, a
>>>>>>> new form "0b1" (binary)
>>>>>>>> would be added.
>>>>>>>>
>>>>>>>> Note that this is the same syntax as has been used as
>>>>>>> an extension by the GCC
>>>>>>>> C/C++ compilers for many years, and also is used in
>>>>>>> the Ruby language, as
>>>>>>>> well as in the Python language.
>>>>>>>>
>>>>>>>>
>>>>>>>> MAJOR ADVANTAGE:
>>>>>>>>
>>>>>>>> It is no longer necessary for programmers to translate
>>>>>>> binary numbers to and
>>>>>>>> from hexadecimal in order to use them in Java
>>>>>>> programs.
>>>>>>>>
>>>>>>>> MAJOR BENEFIT:
>>>>>>>>
>>>>>>>> Code using bitwise operations is more readable and
>>>>>>> easier to verify against
>>>>>>>> technical specifications that use binary numbers to
>>>>>>> specify constants.
>>>>>>>> Routines that are bit-oriented are easier to
>>>>>>> understand when an artifical
>>>>>>>> translation to hexadecimal is not required in order to
>>>>>>> fulfill the
>>>>>>>> constraints of the language.
>>>>>>>>
>>>>>>>> MAJOR DISADVANTAGE:
>>>>>>>>
>>>>>>>> Someone might incorrectly think that "0b1"
>>>>>>> represented the same value as
>>>>>>>> hexadecimal number "0xB1". However, note
>>>>>>> that this problem has existed for
>>>>>>>> octal/decimal for many years (confusion between
>>>>>>> "050" and "50") and does not
>>>>>>>> seem to be a major issue.
>>>>>>>>
>>>>>>>>
>>>>>>>> ALTERNATIVES:
>>>>>>>>
>>>>>>>> Users could continue to write the numbers as decimal,
>>>>>>> octal, or hexadecimal,
>>>>>>>> and would continue to have the problems observed in
>>>>>>> this document.
>>>>>>>> Another alternative would be for code to translate at
>>>>>>> runtime from binary
>>>>>>>> strings, such as:
>>>>>>>>
>>>>>>>> int BITMASK =
>>>>>>> Integer.parseInt("00001110", 2);
>>>>>>>> Besides the obvious extra verbosity, there are several
>>>>>>> problems with this:
>>>>>>>> * Calling a method such as Integer.parseInt at runtime
>>>>>>> will typically make it
>>>>>>>> impossible for the compiler to inline the value of
>>>>>>> this constant, since its
>>>>>>>> value has been taken from a runtime method call.
>>>>>>> Inlining is important,
>>>>>>>> because code that does bitwise parsing is often very
>>>>>>> low-level code in tight
>>>>>>>> loops that must execute quickly. (This is particularly
>>>>>>> the case for mobile
>>>>>>>> applications and other applications that run on
>>>>>>> severely resource-constrained
>>>>>>>> environments, which is one of the cases where binary
>>>>>>> numbers would be most
>>>>>>>> valuable, since talking to low-level hardware is one
>>>>>>> of the primary use cases
>>>>>>>> for this feature.)
>>>>>>>>
>>>>>>>> * Constants such as the above cannot be used as
>>>>>>> selectors in 'switch'
>>>>>>>> statements.
>>>>>>>>
>>>>>>>> * Any errors in the string to be parsed (for instance,
>>>>>>> an extra space) will
>>>>>>>> result in runtime exceptions, rather than compile-time
>>>>>>> errors as would have
>>>>>>>> occurred in normal parsing. If such a value is
>>>>>>> declared 'static', this will
>>>>>>>> result in some very ugly exceptions at runtime.
>>>>>>>>
>>>>>>>>
>>>>>>>> EXAMPLES:
>>>>>>>>
>>>>>>>> // An 8-bit 'byte' literal.
>>>>>>>> byte aByte = (byte)0b00100001;
>>>>>>>>
>>>>>>>> // A 16-bit 'short' literal.
>>>>>>>> short aShort = (short)0b1010000101000101;
>>>>>>>>
>>>>>>>> // Some 32-bit 'int' literals.
>>>>>>>> int anInt1 = 0b10100001010001011010000101000101;
>>>>>>>> int anInt2 = 0b101;
>>>>>>>> int anInt3 = 0B101; // The B can be upper or lower
>>>>>>> case as per the x in
>>>>>>>> "0x45".
>>>>>>>>
>>>>>>>> // A 64-bit 'long' literal. Note the
>>>>>>> "L" suffix, as would also be used
>>>>>>>> // for a long in decimal, hexadecimal, or octal.
>>>>>>>> long aLong =
>>>>>>>>
>>>>>>> 0b01010000101000101101000010100010110100001010001011010000101000101L
>>>>>>> ;
>>>>>>>> SIMPLE EXAMPLE:
>>>>>>>>
>>>>>>>> class Foo {
>>>>>>>> public static void main(String[] args) {
>>>>>>>> System.out.println("The value 10100001 in
>>>>>>> decimal is " + 0b10100001);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> ADVANCED EXAMPLE:
>>>>>>>>
>>>>>>>> // Binary constants could be used in code that needs
>>>>>>> to be
>>>>>>>> // easily checkable against a specifications document,
>>>>>>> such
>>>>>>>> // as this simulator for a hypothetical 8-bit
>>>>>>> microprocessor:
>>>>>>>> public State decodeInstruction(int instruction, State
>>>>>>> state) {
>>>>>>>> if ((instruction & 0b11100000) == 0b00000000) {
>>>>>>>> final int register = instruction &
>>>>>>> 0b00001111;
>>>>>>>> switch (instruction & 0b11110000) {
>>>>>>>> case 0b00000000: return state.nop();
>>>>>>>> case 0b00010000: return
>>>>>>> state.copyAccumTo(register);
>>>>>>>> case 0b00100000: return
>>>>>>> state.addToAccum(register);
>>>>>>>> case 0b00110000: return
>>>>>>> state.subFromAccum(register);
>>>>>>>> case 0b01000000: return
>>>>>>> state.multiplyAccumBy(register);
>>>>>>>> case 0b01010000: return
>>>>>>> state.divideAccumBy(register);
>>>>>>>> case 0b01100000: return
>>>>>>> state.setAccumFrom(register);
>>>>>>>> case 0b01110000: return
>>>>>>> state.returnFromCall();
>>>>>>>> default: throw new IllegalArgumentException();
>>>>>>>> }
>>>>>>>> } else {
>>>>>>>> final int address = instruction & 0b00011111;
>>>>>>>> switch (instruction & 0b11100000) {
>>>>>>>> case 0b00100000: return state.jumpTo(address);
>>>>>>>> case 0b01000000: return
>>>>>>> state.jumpIfAccumZeroTo(address);
>>>>>>>> case 0b01000000: return
>>>>>>> state.jumpIfAccumNonzeroTo(address);
>>>>>>>> case 0b01100000: return
>>>>>>> state.setAccumFromMemory(address);
>>>>>>>> case 0b10100000: return
>>>>>>> state.writeAccumToMemory(address);
>>>>>>>> case 0b11000000: return state.callTo(address);
>>>>>>>> default: throw new IllegalArgumentException();
>>>>>>>> }
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> // Binary literals can be used to make a bitmap more
>>>>>>> readable:
>>>>>>>> public static final short[] HAPPY_FACE = {
>>>>>>>> (short)0b0000011111100000;
>>>>>>>> (short)0b0000100000010000;
>>>>>>>> (short)0b0001000000001000;
>>>>>>>> (short)0b0010000000000100;
>>>>>>>> (short)0b0100000000000010;
>>>>>>>> (short)0b1000011001100001;
>>>>>>>> (short)0b1000011001100001;
>>>>>>>> (short)0b1000000000000001;
>>>>>>>> (short)0b1000000000000001;
>>>>>>>> (short)0b1001000000001001;
>>>>>>>> (short)0b1000100000010001;
>>>>>>>> (short)0b0100011111100010;
>>>>>>>> (short)0b0010000000000100;
>>>>>>>> (short)0b0001000000001000;
>>>>>>>> (short)0b0000100000010000;
>>>>>>>> (short)0b0000011111100000;
>>>>>>>> }
>>>>>>>>
>>>>>>>> // Binary literals can make relationships
>>>>>>>> // among data more apparent than they would
>>>>>>>> // be in hex or octal.
>>>>>>>> //
>>>>>>>> // For instance, what does the following
>>>>>>>> // array contain? In hexadecimal, it's hard to
>>>>>>> tell:
>>>>>>>> public static final int[] PHASES = {
>>>>>>>> 0x31, 0x62, 0xC4, 0x89, 0x13, 0x26, 0x4C, 0x98
>>>>>>>> }
>>>>>>>>
>>>>>>>> // In binary, it's obvious that a number is being
>>>>>>>> // rotated left one bit at a time.
>>>>>>>> public static final int[] PHASES = {
>>>>>>>> 0b00110001,
>>>>>>>> 0b01100010,
>>>>>>>> 0b11000100,
>>>>>>>> 0b10001001,
>>>>>>>> 0b00010011,
>>>>>>>> 0b00100110,
>>>>>>>> 0b01001100,
>>>>>>>> 0b10011000,
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> DETAILS
>>>>>>>>
>>>>>>>> SPECIFICATION:
>>>>>>>>
>>>>>>>> Section 3.10.1 ("Integer Literals") of the
>>>>>>> JLS3 should be changed to add the
>>>>>>>> following:
>>>>>>>>
>>>>>>>> IntegerLiteral:
>>>>>>>> DecimalIntegerLiteral
>>>>>>>> HexIntegerLiteral
>>>>>>>> OctalIntegerLiteral
>>>>>>>> BinaryIntegerLiteral // Added
>>>>>>>>
>>>>>>>> BinaryIntegerLiteral:
>>>>>>>> BinaryNumeral IntegerTypeSuffix_opt
>>>>>>>>
>>>>>>>> BinaryNumeral:
>>>>>>>> 0 b BinaryDigits
>>>>>>>> 0 B BinaryDigits
>>>>>>>>
>>>>>>>> BinaryDigits:
>>>>>>>> BinaryDigit
>>>>>>>> BinaryDigit BinaryDigits
>>>>>>>>
>>>>>>>> BinaryDigit: one of
>>>>>>>> 0 1
>>>>>>>>
>>>>>>>> COMPILATION:
>>>>>>>>
>>>>>>>> Binary literals would be compiled to class files in
>>>>>>> the same fashion as
>>>>>>>> existing decimal, hexadecimal, and octal literals are.
>>>>>>> No special support or
>>>>>>>> changes to the class file format are needed.
>>>>>>>>
>>>>>>>> TESTING:
>>>>>>>>
>>>>>>>> The feature can be tested in the same way as existing
>>>>>>> decimal, hexadecimal,
>>>>>>>> and octal literals are: Create a bunch of constants in
>>>>>>> source code, including
>>>>>>>> the maximum and minimum positive and negative values
>>>>>>> for integer and long
>>>>>>>> types, and verify them at runtime to have the correct
>>>>>>> values.
>>>>>>>>
>>>>>>>> LIBRARY SUPPORT:
>>>>>>>>
>>>>>>>> The methods Integer.decode(String) and
>>>>>>> Long.decode(String) should be modified
>>>>>>>> to parse binary numbers (as specified above) in
>>>>>>> addition to their existing
>>>>>>>> support for decimal, hexadecimal, and octal numbers.
>>>>>>>>
>>>>>>>>
>>>>>>>> REFLECTIVE APIS:
>>>>>>>>
>>>>>>>> No updates to the reflection APIs are needed.
>>>>>>>>
>>>>>>>>
>>>>>>>> OTHER CHANGES:
>>>>>>>>
>>>>>>>> No other changes are needed.
>>>>>>>>
>>>>>>>>
>>>>>>>> MIGRATION:
>>>>>>>>
>>>>>>>> Individual decimal, hexadecimal, or octal constants in
>>>>>>> existing code can be
>>>>>>>> updated to binary as a programmer desires.
>>>>>>>>
>>>>>>>>
>>>>>>>> COMPATIBILITY
>>>>>>>>
>>>>>>>>
>>>>>>>> BREAKING CHANGES:
>>>>>>>>
>>>>>>>> This feature would not break any existing programs,
>>>>>>> since the suggested
>>>>>>>> syntax is currently considerd to be a compile-time
>>>>>>> error.
>>>>>>>>
>>>>>>>> EXISTING PROGRAMS:
>>>>>>>>
>>>>>>>> Class file format does not change, so existing
>>>>>>> programs can use class files
>>>>>>>> compiled with the new feature without problems.
>>>>>>>>
>>>>>>>>
>>>>>>>> REFERENCES:
>>>>>>>>
>>>>>>>> The GCC/G++ compiler, which already supports this
>>>>>>> syntax (as of version 4.3)
>>>>>>>> as an extension to standard C/C++.
>>>>>>>> http://gcc.gnu.org/gcc-4.3/changes.html
>>>>>>>>
>>>>>>>> The Ruby language, which supports binary literals:
>>>>>>>> http://wordaligned.org/articles/binary-literals
>>>>>>>>
>>>>>>>> The Python language added binary literals in version
>>>>>>> 2.6:
>>>>>>> http://docs.python.org/dev/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax
>>>>>>>> EXISTING BUGS:
>>>>>>>>
>>>>>>>> "Language support for literal numbers in binary
>>>>>>> and other bases"
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025288
>>>>>>>> URL FOR PROTOTYPE (optional):
>>>>>>>>
>>>>>>>> None.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
More information about the coin-dev
mailing list