Take the following code example:
Integer a = 130;
Integer b = 130;
if (a == b) {
System.out.println("a == b");
}
Integer c = 100;
Integer d = 100;
if (c == d) {
System.out.println("c == d");
}
Integer e = new Integer(100);
Integer f = new Integer(100);
if (e == f) {
System.out.println("e == f");
}
What is output by the following code fragment? The answer is...
c == d
If the equals-equals operator evaluated to true for c==d why did it not for a==b? And furthermore, if c == d then why does e ==f evaluate to false?
This shows an interesting aspect of auto-boxing and the way Java manages/saves memory. The golden rule is that for the types Boolean, Byte, Character (\u0000 to \u007f), Short, and Integer (-128-127), if a variable is created by auto-boxing an evaluation of the == operator will return true for equal value items.
Your next question may be... "Well why is e == f evaluating to false?" This is because when we explicitly call the Integer constructor, passing it 100 we are bypassing the auto-box feature of java and therefore the rule doesn't apply.
PS: You should never rely on == for wrapped objects. Always use the .equals method!
Java is full of little nuances. One interesting is the handling of overridden methods and the auto-boxing feature that was introduced in Java 1.5. For example suppose you had a class with the following methods..
public void doStuff(long myParam) {
System.out.println("long");
}
public void doStuff(Integer myParam) {
System.out.println("Integer");
}
Now take the following code block
int myInt = 4; doStuff(myInt); doStuff(3);
What would be output? The answer is...
long
long
Why is this? Well one might thing that Java will take myInt and automatically box it to be an Integer then call the method that accepts an Integer parameter. This is not the case. When autoboxing was introduced in Java 1.5 the designers wanted to make absolutely sure that legacy code (previous to Java 1.5) would still work as it always has. To guarantee this they had to make implicit casting favored over auto-boxing when overriding methods.
Here is a step by step run through of creating a java ssl keystore using VeriSign as your certificate authority. I recently ran through this with a client so I figured I'd share since this has little to no correct documentation.
PREREQUISITE: You will need a jdk installed for you operating system. Also, I assume that you have added the $JAVA_HOME/bin folder to your $PATH environment variable. If you have not done so, you will need to run the commands I give from within the $JAVA_HOME/bin directory. You should see an executable named keytool.exe in this folder that is used throughout this tutorial.
First things first, we need to create a keystore, which in turn will create you private encryption key that will be used in the authentication process with clients. I like to think of a keystore as somewhat of a secure zip file. A keystore can contain many certificates which are distinguished by unique name identifiers (just like a java.util.HashMap in the Java world). The following command will create a 2048 bit RSA private key which is pretty standard today.
keytool -genkey -keyalg RSA -keysize 2048 –keystore –alias my_cert my-keystore.keystore
Next, keytool will ask you for a password for your newly created keystore. Specify whatever password you like. Along with your password, you will be asked a series of questions.
NOTE: For the "What is your first and last name?" question, enter the full domain name. When I say full domain name, I mean whatever a user will type into the address bar in their browser when they go to your site. For example, if we were creating this keystore for google.com. You would specify www.google.com for this question.
At this point you now have a keystore named my-keystore.keystore. The next step is to create what is known as a certificate signing request. This request is what VeriSign will ask for to generate your public key (signing your certificate). The following command will generate your CSR
keytool –certreq –keyalg RSA –alias my_cert –file certreq.csr –keystore my-keystore.keystore
NOTE: It is important to use the same –alias and –keystore as used in command 1)
Now send your CSR to verisign per their instructions (they will send you instructions after you purchase your certificate). Verisign will then respond with your certificate. We will need to import the certificate they generate for you as well as the Intermediate Certificate from verisign.
At the time of authoring this guide the intermediate CA can be found here http://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html . Copy the encrypted text to a file named intermediate.cer (make sure you do not add extra spaces) Next import intermediate.cer into your keystore
keytool –import –trustcacerts –alias intermediatechain –file intermediate.cer –keystore my_keystore.keystore
Next we want to import the certificate supplied from Verisign (what you bought). This is your public key. I assume for the below command that you saved your certificate in a file named server.cer.
keytool –import trustcacerts –alias my_cert –keystore my_keystore.keystore –file server.cer
NOTE: You must give this the same alias as used for your private key in command 1). Namely, this is ‘my_cert’ in this example.
At this point your keystore is properly configured and now you must configuration JBOSS to use it. Copy my_keystore.keystore to JBOSS_HOME\server\default\conf .
Next open the file JBOSS_HOME\server\default\deploy\jbossweb.sar\server.xml .
You should see some lines that look like below... You may need to uncomment these lines in the xml file if they are commented out.
Change the keystorePass to be whatever you password you gave your keystore when we created it in command 1)
Congratulations, you have configured your VeriSign purchased certificate to work with JBoss.
