While browsing the Google news today about Sun laying off 6000 employees, Google has matched that item with actual “Sun” logo instead of Sun Microsystems logo. Google has some areas for improvement ah?

While browsing the Google news today about Sun laying off 6000 employees, Google has matched that item with actual “Sun” logo instead of Sun Microsystems logo. Google has some areas for improvement ah?

CNN projected that Barack Obama will become the first African-American president of the United States. Congratulations Senator.
I got to know of saying “Never say never and never say always” from some source (which I don’t recall), which is all the more applicable in our fickle Java ecosystem.
I have been using Eclipse all this while and have defended religiously too. But going through the features/options NetBeans latest version 6.5 RC, makes me feel that Eclipse is some (rather a lot) catchup to do when it comes to JEE lineup support.
So being a ardent Eclipse user (to the extent that I have said, I will never use any other IDE), I’m going to give NetBeans 6.5 a try (that’s why never say never) and find out if I can be more productive when doing JEE development.
Friend of mine recently had one issue with SLS Mutual Authentication (aka Client Authentication) that server was failing with error “Re-negotiation handshake failed: Not accepted by client!” and at client side it was throwing following error.
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:117)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1650)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:925)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:739)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
After all the debugging to make sure all the required system parameters are specified like keyStore and trustStore and wasting lot of time, it was found out that the certificate the client was using had some issues with private/public keypair.
So if you get into this above issue or any other issues related to SSL connectivity, check out the certificate you are using on both sides. Even better try out the SSL Connectivity with simple client/server ssl app and make sure it is working then try out in the real application.
Well for same friend, I actually wrote a simple client/server SSL app which which let’s client/server exchange some user keyedin data.
Here is how to use it.
1. Download the source and class files from here and extract to a folder.
2. Put your certificate files (you can rename your certificate files as client.jks/server.jks or change the parameters in the bat files)
3. Run server.bat, which starts a server on port 7001 (you can pass parameter “true”, which enables the client authentication else disables it)
4. Run client.bat and notice that it is talking to server and finishing the handshake. To confirm client is communicating with server, type some text and notice that it is echoed back by the server.
Here is the sample output.
Client:
C:\Projects\EclipseWorkspace\SSLTest\temp>client Connecting to the server at localhost:7001 Connected to the server. Type something and press enter. Whatever you type will be sent to the server, which will echo back. SSL Handshake Completed with following details: CipherSuite: SSL_RSA_WITH_RC4_128_MD5 LocalPrincipal: CN=Client Test, OU=Java Unit, O=Java Company, L=Java City, ST=Java State, C=US RemovePrincipal: CN=Server Test, OU=Java Unit, O=Java Company, L=Java City, ST=Java State, C=US Session: [Session-1, SSL_RSA_WITH_RC4_128_MD5] Socket: 1f33675[SSL_RSA_WITH_RC4_128_MD5: Socket[addr=localhost/127.0.0.1,port=7001,localport=3206]] hello hello world world
Server:
C:\Projects\EclipseWorkspace\SSLTest\temp>server true Enabling client authentication Listening for a new connection at port 7001 Connection accepted from /127.0.0.1:3206 SSL Handshake Completed with following details: CipherSuite: SSL_RSA_WITH_RC4_128_MD5 LocalPrincipal: CN=Server Test, OU=Java Unit, O=Java Company, L=Java City, ST=Java State, C=US RemovePrincipal: CN=Client Test, OU=Java Unit, O=Java Company, L=Java City, ST=Java State, C=US Session: [Session-1, SSL_RSA_WITH_RC4_128_MD5] Socket: 7c6768[SSL_RSA_WITH_RC4_128_MD5: Socket[addr=/127.0.0.1,port=3206,localport=7001]]
Hope this helps.
Not many might not have used, if not noticed about the Google Lucky search feature. Instead of clicking on Search button, if you click on “I’m Feeling Lucky”, Google would automatically redirect to the first result. This would be very useful many times, if you want to select the url from bookmarks or type the full address. Even better is adding a Search Keyword in Firefox so you can just type “gl
1. Download this search plugin xml and add to the “Mozilla Firefox\searchplugins” folder. In Windows, it would be “C:\Program Files\Mozilla Firefox\searchplugins”.
2. Open your Firefox browser and select “Manage Search Engines…” in the Search box

3. Select “Google Lucky” on the list of Search Engines and Click on “Edit Keyword”

4. Enter gl as the keyword and Click Ok (twice)

5. You are good to go, give it a try. Type “gl java 1.5 api” and notice that you are taken automatically to the Java 1.5 API Spec in Java.
I think it is time to remember Microsoft’s antitrust suit because another one may be coming soon to Apple. Apple has been monopolizing the platform by blocking all applications which competes slightly with it getting passed through the gate. Apple should have confidence that if it has better product than others, people do use it (And no other company better than Apple in make it happen) and let other compete.
When I moved to California from Jersey and getting ready to take the California Driver’s written test, I didn’t find good sample test papers to get the feel of the test or to evaluate myself to see where I stood. After the exam, I thought I will collect/create some sample test papers to it would ease anybody else who is attempting to take the exam but managed to procrastinate till today.
I wanted to write some generic code so that extra time need not be spent if I had to add additional sample papers. I was in good mood today to deal with the javascript quirks (really, you got to code in understand the quirks) so wrote up javascript to load the xml data file with all questions and render the (supporting both single and multiple choice) questions and evaluate the answers to findout of tester is passed or failed.
It came out pretty good and I’m quite happy with it. Another interesting twist is that first person who going to use is my wife
She trying to take the exam sometime this week.
I’m planning to add around 6-7 papers over period. Take a look and pass the url along to whoever might benefit.
There has been lots of discussion going on for a very long time weather to use NPE or IAE when a null is passed when a non-null object is expected as an method/constructor argument.
After developing java applications for quite sometime, I have observed that when one sees a NPE in the log file, it usually means some serious bug which should be dealt with. I strongly think that NPE should only ever be thrown by the JVM when it try to access some properties/methods of a null object (hey did you notice, it is called Null Pointer Exception where pointer means trying to access a property or method on null).
However javadoc for NPE allows applications to throw NPE in other subjective scenarios, which led to misuse of it.
Thrown when an application attempts to use null in a case where an object is required. These include:
- Calling the instance method of a null object.
- Accessing or modifying the field of a null object.
- Taking the length of null as if it were an array.
- Accessing or modifying the slots of null as if it were an array.
- Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal uses of the null object.
To move on, if only all developers follow the convention to use only IAE and leave the NPE to the JVM, life would far better for the troubleshooters
So next time you validating the constructor/method parameter, forget NPE and use IAE.
public void doSomething(String anything) {
if (anything == null) {
throw new IllegalAccessError("Parameter anything is null");
}
}
I have been wanting to write some tutorial about Java Server Faces for easy on-ramping. I will be writing the tutorial in slow paced, simple steps which learners can be follow along as they try out. This post would be updated with links for all of these steps as and when they posted.