Database Reference
In-Depth Information
As we march through the
for
loop, we observe our position. After every four characters, we want to
place a dash. We do a modulus 5 (% 5) to test our position. When the next place, modulus 5 equals 0, we
need to set the next place to a dash character. The first array position is 0, so we add one, and we want to
test our next place, so we add another one. We test
(i+2)%5
.
When our test is positive, we go ahead and increment it so we can set the next place to a dash and
continue; however, we don't want to try to tack another dash character on the end of our array, so we
only set a dash
if ( i < twoFactorLength )
.
Listing 9-20.
Build the Two-Factor Code
private static int twoFactorLength = 14;
private
static char[] twoFactorAuthChars
= null;
twoFactorAuthChars = new char[twoFactorLength];
for ( int i = 0; i < twoFactorLength; i++ ) {
// Use numeric only to accommodate old pagers
twoFactorAuthChars[i] =
( char )( random.nextInt( 58 - 48 ) + 48 )
;
// Insert dashes (after every 4 characters) for readability
if(
0 == ( ( i + 2 ) % 5 )
) {
i++;
if ( i < twoFactorLength )
twoFactorAuthChars[i] = '-';
}
}
String twoFactorAuth = new String( twoFactorAuthChars );
We are only using the
String
representation of our two-factor authentication code in this method,
so we set a method member. Everywhere else, the two-factor authentication code is referred to as a
char
array. We test the existence of
twoFactorAuthChars
array when we enter this method (see Listing 9-19),
and we retain it as a static class member.
Dealing with Oracle and Java Dates: Standard Practice
Are you familiar with the Jim Croce song, “Time in a Bottle”? One of my favorite lines from that song is,
“I've been around enough to know that you're the one I want to go through time with.” Some old coding
practices are like that. One particular standard practice I maintain is the exchange of dates between
Oracle database and Java. I have never gotten into trouble when abiding by this plan, which I'm about to
describe.
The only potential problem with what I am going to present to you is that the precision is limited to
seconds. If you need milliseconds precision, you will need to modify the approach somewhat. Well,
there is also the issue of time zone, which we have discussed; you may have to deal with that if your
company is spread across multiple time zones.
The first standard I propose is to always use
java.util.Date
, and never use
java.sql.Date
. Besides
the confusion due to the fact that they have the same name (but are mutually exclusive), there is the
problem that they operate differently. Learn
java.util.Date
. Always import it and use it exclusively. You
can use both
Date
classes, but great care is required to always address them as either
java.util.Date
or
