Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Jörg Schaible wrote: Gary Gregory wrote: On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jörg Schaible wrote: sebb wrote: [snip] I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. Has anyone a better idea for the names? I would probably loose the plural to indicate an array. This is also ambiguous. Probably it would be better to use array directly. e.g.: - byteArrayToLong - longToByteArray Done. Used binary for boolArray though, because that's what it meant. I would expand M0 to Msb0 which itself is an acronym. Abbreviating an acronym is to mysterious to me. Done. [snip] I would use real examples in the Javadoc: * p * (true, false, false, false) is converted as follow: '8' ... instead of: * p * (1, 0, 0, 0) is converted as follow: '8' ... and use [ ] instead of ( ) to show an array The example is for binary representation (which is modeled with boolean arrays), therefore I kept the representation here. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jörg Schaible wrote: sebb wrote: [snip] I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. Has anyone a better idea for the names? I would probably loose the plural to indicate an array. I would expand M0 to Msb0 which itself is an acronym. Abbreviating an acronym is to mysterious to me. So I'd end up with: boolBeMsb0ToHexDigit(boolean[] src) instead of: boolsBeM0ToHexDigit(boolean[] src) I would use real examples in the Javadoc: * p * (true, false, false, false) is converted as follow: '8' ... instead of: * p * (1, 0, 0, 0) is converted as follow: '8' ... and use [ ] instead of ( ) to show an array my 2c, Gary - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Urgh; I find these method names rather painful. Why wouldn't we simply provide endianness and bit ordering as enums, and parameterize accordingly? Matt On Wed, Oct 3, 2012 at 9:07 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jörg Schaible wrote: sebb wrote: [snip] I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. Has anyone a better idea for the names? I would probably loose the plural to indicate an array. I would expand M0 to Msb0 which itself is an acronym. Abbreviating an acronym is to mysterious to me. So I'd end up with: boolBeMsb0ToHexDigit(boolean[] src) instead of: boolsBeM0ToHexDigit(boolean[] src) I would use real examples in the Javadoc: * p * (true, false, false, false) is converted as follow: '8' ... instead of: * p * (1, 0, 0, 0) is converted as follow: '8' ... and use [ ] instead of ( ) to show an array my 2c, Gary - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Also note that we have org.apache.commons.*io*.EndianUtils which does not do the same thing but it a good class name. Gary On Wed, Oct 3, 2012 at 10:51 AM, James Carman ja...@carmanconsulting.comwrote: Agreed. This is very cryptic, IMHO. On Wed, Oct 3, 2012 at 10:42 AM, Matt Benson gudnabr...@gmail.com wrote: Urgh; I find these method names rather painful. Why wouldn't we simply provide endianness and bit ordering as enums, and parameterize accordingly? Matt On Wed, Oct 3, 2012 at 9:07 AM, Gary Gregory garydgreg...@gmail.com wrote: On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jörg Schaible wrote: sebb wrote: [snip] I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. Has anyone a better idea for the names? I would probably loose the plural to indicate an array. I would expand M0 to Msb0 which itself is an acronym. Abbreviating an acronym is to mysterious to me. So I'd end up with: boolBeMsb0ToHexDigit(boolean[] src) instead of: boolsBeM0ToHexDigit(boolean[] src) I would use real examples in the Javadoc: * p * (true, false, false, false) is converted as follow: '8' ... instead of: * p * (1, 0, 0, 0) is converted as follow: '8' ... and use [ ] instead of ( ) to show an array my 2c, Gary - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Gary Gregory wrote: On Wed, Oct 3, 2012 at 7:28 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Jörg Schaible wrote: sebb wrote: [snip] I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. Has anyone a better idea for the names? I would probably loose the plural to indicate an array. This is also ambiguous. Probably it would be better to use array directly. e.g.: - byteArrayToLong - longToByteArray I would expand M0 to Msb0 which itself is an acronym. Abbreviating an acronym is to mysterious to me. So I'd end up with: boolBeMsb0ToHexDigit(boolean[] src) instead of: boolsBeM0ToHexDigit(boolean[] src) Sounds reasonable. I would use real examples in the Javadoc: * p * (true, false, false, false) is converted as follow: '8' ... instead of: * p * (1, 0, 0, 0) is converted as follow: '8' ... and use [ ] instead of ( ) to show an array OK. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Matt Benson wrote: Urgh; I find these method names rather painful. Why wouldn't we simply provide endianness and bit ordering as enums, and parameterize accordingly? Because the algorithm is different (although similar) every time and not all combinations are implemented? Honestly, we would have to use in most cases a switch/case statement internally anyway and either throw UnsupportedOperationException for the unimplemented cases or someone would have to implement it ... ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On 3 October 2012 18:24, Jörg Schaible joerg.schai...@gmx.de wrote: Matt Benson wrote: Urgh; I find these method names rather painful. Why wouldn't we simply provide endianness and bit ordering as enums, and parameterize accordingly? Because the algorithm is different (although similar) every time and not all combinations are implemented? Honestly, we would have to use in most cases a switch/case statement internally anyway and either throw UnsupportedOperationException for the unimplemented cases or someone would have to implement it ... ;-) I think the enum-based solution is much more elegant; the JavaDoc could then contain a table demonstrating which combinations are supported. The better of two evils, IMO. I'm always in favour of methods that can be easily understood from a cursory glance. It bodes well for easy code maintenance. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
I like the enum idea too. G On Wed, Oct 3, 2012 at 2:12 PM, Duncan Jones dun...@wortharead.com wrote: On 3 October 2012 18:24, Jörg Schaible joerg.schai...@gmx.de wrote: Matt Benson wrote: Urgh; I find these method names rather painful. Why wouldn't we simply provide endianness and bit ordering as enums, and parameterize accordingly? Because the algorithm is different (although similar) every time and not all combinations are implemented? Honestly, we would have to use in most cases a switch/case statement internally anyway and either throw UnsupportedOperationException for the unimplemented cases or someone would have to implement it ... ;-) I think the enum-based solution is much more elegant; the JavaDoc could then contain a table demonstrating which combinations are supported. The better of two evils, IMO. I'm always in favour of methods that can be easily understood from a cursory glance. It bodes well for easy code maintenance. Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Gary Gregory wrote: On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible joerg.schai...@gmx.dewrote: sebb wrote: [snip] Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? While semantically the same, I wonder if changing the output style will surprise some users. I'm 50/50. Or further usage of JDK functionality? I think it has to be considered on a case by case basis if there are any side-effects like the one above. This code is completely new for 3.2, so *now* is the time to decide ;-) - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On Sep 29, 2012, at 6:58, Jörg Schaible joerg.schai...@gmx.de wrote: Gary Gregory wrote: On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible joerg.schai...@gmx.dewrote: sebb wrote: [snip] Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? While semantically the same, I wonder if changing the output style will surprise some users. I'm 50/50. Or further usage of JDK functionality? I think it has to be considered on a case by case basis if there are any side-effects like the one above. This code is completely new for 3.2, so *now* is the time to decide ;-) Well, we should just reuse the JRE then. The question should be flipped: why should we /not/ reuse the JRE in this case? G - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
sebb wrote: On 28 September 2012 18:47, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: [snip] Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Thanks! Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? 50/50 I tend to follow the JDK here. But it needs to be documented better; e.g. intToHexDigitM0 does not say whether output is upper or lower case. It's good that the code accepts either case on input. == I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 I am all open for better names, all *I* want to have is the functionality. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
2012/9/28 Jörg Schaible joerg.schai...@scalaris.com: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? YourKit has a licence for open source projects. Looks like you only have to contact their sales by mail (using your @apache.org account?!). Benedikt - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On 28 September 2012 08:17, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? Is a hoped for performance gain why you made the change? Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
sebb wrote: On 28 September 2012 08:17, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? Is a hoped for performance gain why you made the change? Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? Or further usage of JDK functionality? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On Fri, Sep 28, 2012 at 1:47 PM, Jörg Schaible joerg.schai...@gmx.dewrote: sebb wrote: On 28 September 2012 08:17, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? Is a hoped for performance gain why you made the change? Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? While semantically the same, I wonder if changing the output style will surprise some users. I'm 50/50. Or further usage of JDK functionality? I think it has to be considered on a case by case basis if there are any side-effects like the one above. Gary - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On 28 September 2012 18:47, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: On 28 September 2012 08:17, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Sebb, sebb wrote: On 27 September 2012 23:53, joe...@apache.org wrote: Author: joehni Date: Thu Sep 27 22:53:46 2012 New Revision: 1391258 URL: http://svn.apache.org/viewvc?rev=1391258view=rev Log: Use conversion tables for boolean arrays. I think the previous code was much clearer. At first sight it now looks as though the static arrays are shared (which would not be safe) but in fact they are cloned. At least I should have checked it with a profiler before. Don't we have a YourKit license for Apache somewhere? Is a hoped for performance gain why you made the change? Unless there is a significant improvement across several Java versions, I'm -1 on the change as the code is now more obscure. Done. Thanks! Any comment on replacing the standard hex representation (i.e. lower case letters like JDK does)? 50/50 But it needs to be documented better; e.g. intToHexDigitM0 does not say whether output is upper or lower case. It's good that the code accepts either case on input. == I find the naming convention rather difficult to follow. For example, the letter 's' sometimes means 'array' and sometimes means 'string' Also M0 is not obvious as an abbreviation, nor is BeM0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1391258 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
On 27 September 2012 23:53, joe...@apache.org wrote:
Author: joehni
Date: Thu Sep 27 22:53:46 2012
New Revision: 1391258
URL: http://svn.apache.org/viewvc?rev=1391258view=rev
Log:
Use conversion tables for boolean arrays.
I think the previous code was much clearer.
At first sight it now looks as though the static arrays are shared
(which would not be safe) but in fact they are cloned.
Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java?rev=1391258r1=1391257r2=1391258view=diff
==
---
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
(original)
+++
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Conversion.java
Thu Sep 27 22:53:46 2012
@@ -18,7 +18,6 @@
***/
package org.apache.commons.lang3;
-
/**
* p
* Static methods to convert a type into another, with endianness and bit
ordering awareness.
@@ -56,6 +55,24 @@ package org.apache.commons.lang3;
*/
public class Conversion {
+
+private static final boolean[] BOOL_ = {false, false, false, false};
+private static final boolean[] BOOL_TFFF = {true, false, false, false};
+private static final boolean[] BOOL_FTFF = {false, true, false, false};
+private static final boolean[] BOOL_TTFF = {true, true, false, false};
+private static final boolean[] BOOL_FFTF = {false, false, true, false};
+private static final boolean[] BOOL_TFTF = {true, false, true, false};
+private static final boolean[] BOOL_FTTF = {false, true, true, false};
+private static final boolean[] BOOL_TTTF = {true, true, true, false};
+private static final boolean[] BOOL_FFFT = {false, false, false, true};
+private static final boolean[] BOOL_TFFT = {true, false, false, true};
+private static final boolean[] BOOL_FTFT = {false, true, false, true};
+private static final boolean[] BOOL_TTFT = {true, true, false, true};
+private static final boolean[] BOOL_FFTT = {false, false, true, true};
+private static final boolean[] BOOL_TFTT = {true, false, true, true};
+private static final boolean[] BOOL_FTTT = {false, true, true, true};
+private static final boolean[] BOOL_ = {true, true, true, true};
+
/**
* p
* Converts a hexadecimal digit into an int using the default (Lsb0) bit
ordering.
@@ -184,50 +201,68 @@ public class Conversion {
* @return a boolean array with the binary representation of
codehexDigit/code
*/
public static boolean[] hexDigitToBools(char hexDigit) {
+final boolean[] array;
switch (hexDigit) {
case '0':
-return new boolean[]{false, false, false, false};
+array = BOOL_;
+break;
case '1':
-return new boolean[]{true, false, false, false};
+array = BOOL_TFFF;
+break;
case '2':
-return new boolean[]{false, true, false, false};
+array = BOOL_FTFF;
+break;
case '3':
-return new boolean[]{true, true, false, false};
+array = BOOL_TTFF;
+break;
case '4':
-return new boolean[]{false, false, true, false};
+array = BOOL_FFTF;
+break;
case '5':
-return new boolean[]{true, false, true, false};
+array = BOOL_TFTF;
+break;
case '6':
-return new boolean[]{false, true, true, false};
+array = BOOL_FTTF;
+break;
case '7':
-return new boolean[]{true, true, true, false};
+array = BOOL_TTTF;
+break;
case '8':
-return new boolean[]{false, false, false, true};
+array = BOOL_FFFT;
+break;
case '9':
-return new boolean[]{true, false, false, true};
+array = BOOL_TFFT;
+break;
case 'a':// fall through
case 'A':
-return new boolean[]{false, true, false, true};
+array = BOOL_FTFT;
+break;
case 'b':// fall through
case 'B':
-return new boolean[]{true, true, false, true};
+array = BOOL_TTFT;
+break;
case 'c':// fall through
case 'C':
-return new boolean[]{false, false, true, true};
+array = BOOL_FFTT;
+break;
case 'd':// fall through
case 'D':
-return new boolean[]{true, false,
