Let’s say your Java Web Service client wants to make a call (SOAP over SSL/https) to a service running on some server and is using a legitimate certificate or say a self-signed certificate.

Now, your client can either bypass this certificate business by using XTrustProvider.install() or do it the right way by importing the certificate in your JRE_HOME/lib/security/ folder.

Either read the documentation on keytool or read further.
(My snippets below use JDK 1.6.0_26 and are done Windows. You can do equivalent stuff on Linux as well)

To View the list of certificates in the JDK, goto JRE_HOME\lib\security and run the following:

C:\Java\jdk1.6.0_26\jre\lib\security>..\..\bin\keytool keytool -list -keystore cacerts
Enter keystore password:default password is changeit

To Import the certificate into JDK, goto JRE_HOME\lib\security and run the following:

C:\Java\jdk1.6.0_26\jre\lib\security>..\..\bin\keytool -import -alias myTestCert -keystore cacerts -file c:\Temp\Certificates\DER_Cert.cer
Enter keystore password:default password is changeit

Now, your Java Web Service Client should now be able to make the calls over SSL without connection issues.

In case you want to Delete the Certificate:

C:\Java\jdk1.6.0_26\jre\lib\security>..\..\bin\keytool -delete -alias myTestCert -keystore cacerts
Enter keystore password: default password is changeit

More information can be found here: http://sites.google.com/site/ankurrathi/trustingacertificate and also explains how to download certificates if you don’t already have it.

If you’re using Soap UI for testing and you might want to configure SoapUI with client certificate authentication.

Finally your Web Service client might might also need to verify the hostnames as shown below where I trust all hosts.

static  {
		HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
			public boolean verify(String hostname, SSLSession session) {
				// Make sure that hostname is valid
				return true;
			}
		});
	}

JDK 7 Early Access came out after almost 5 years.

The Sun has set and with Oracle’s first official Java release we’ll see how things play out for Java and the community.

More new features to read about!

I’m tempted to try it out with Eclipse Indigo, but I’ll hold off until the P4Eclipse plugin works with the new 3.7 release.

IDEA 10.5 is out and claims full Java 7 support. The community edition is FREE to download.

You can download the latest JDK 7 publicly available build (currently b145).

I’ve been using Eclipse since forever and even though I know for a fact that IntelliJ IDEA is in many ways a more pleasing experience, I’m yet to make the switch. I’ve installed IDEA 9.0.1 full version but never really cared to get super comfortable with it. Maybe I might just give it a shot!

Got deadlock?

killall -QUIT java

This will log the thread dumps for your java processes wherever the processes standard output is configured.

Folks, look no further. java.util.UUID works great. I’ve tried the Axis’s UUIDGenFactory and and was NOT unique. 10 reps of 40 threads pounding simultaneously. At least, two or three of the forty were duplicates every time (only thirty seven were unique) Geeze!!! And I thought it was the synchronization.

java.util.UUID.randomUUID().toString(); // This works

Moreover, it uses SecureRandom number generator algorithms – so it is secure (in terms of predicting the next UUID etc.).

Sometimes you might want to create some JavaDoc for some APIs (as a one-off) say for a customer (Doc Team etc.). Simply use the javadoc command line option. Use the -d option to specify the destination for generated HTML content.

~/java/jdk1.6.0_20/bin/javadoc ./src/java/com/domain/api/MyService.java -d ~/tmp/javadoc

Alternatively, from within Eclipse – you can start the JavaDoc wizard and select the class you want generate the JavaDoc for.

File => Export => Java => JavaDoc => Select The Class, Desitination and hit Finish