A picture is worth a thousand words they say. So, without much ado, here it is… having been with Java since the beginning, here is how I feel about it now.
And to justify with some concrete evidence, here is the page count from the Java In A Nutshell book that was one of my most beloved Java books in the last decade. Not anymore, the friggin book is 1252 pages!
- 1st Edition: 460 pages
- 2nd Edition: 628 pages
- 3rd Edition: 720 pages
- 4th Edition: 992 pages
- 5th Edition: 1252 pages
Hell, it should be renamed to “Java in a Coconut Shell”. And I am just talking about core of Java here, not all the other extensions around it. Because there are spawns of Nutshell books like “Java Enterprise in a Nutshell” and what not.
PS: Apologies to those who came here looking for some philosophical/technical discussion about how I really feel about Java.
Java Humor
November 7th, 2005
As I mentioned in my earlier post, I spend some of my time on building a rich UI application using Swing. And when it came to choosing a mechanism to store my user preferences, I decided to not use property files which was how I had stored preferences before. But, now (since Java 1.4) I use the java.util.Preferences API to store and retrieve my preferences. I would not store sensitive information in preferences, but for non-sensitive info, Preferences API is a great way to persist and manage them. The reason I am posting this is that while talking to some of my friends I realized that not many were aware of the Preferences API despite it being around for a while now. Perhaps because most of us have been focussed on server-side software where we have many other options to store preferences such as JNDI registry or a centralized configuration management system. Anyway, if you are building a stand-alone Java application or a rich client and have a need to store user preferences, take a look at the Preferences API. I think it is a cool API.
Some references:
Java Programming
May 2nd, 2005
It shouldn‘t be this wicked. Ok, I admit it has been a while since I implemented
a Java RMI based
client/server. But, it shouldn‘t be this wicked. So, I was trying to get some
RMI client/server code running on my machine. And I kept getting was this friggin
exception:
Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ServerException:
RemoteException occurred in server thread;
nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments;
nested exception is: java.lang.ClassNotFoundException: com.sun.salsa.PatternModelImpl_Stub
The RMI docs said that anytime you get a ClassNotFoundException, it
is most likely caused by an improperly set codebase[J] So I checked
the value of my java.rmi.server.CodeBase property. It was set as follows:
java.rmi.server.CodeBase=file://dev/salsa/classes
I checked to make sure that the directory was there and that all the stubs
and other classes were in there. They were. So, I ran the RMI server program
again. But, again I got the same exception. What the heck is going on? And then
it hit me. Isn‘t that supposed to be codebase and not CodeBase?
So I change "CodeBase" to "codebase" and reset the property
as follows:
java.rmi.server.codebase=file://dev/salsa/classes
And give the program another try. This time, I got a different exception.
Exception in thread "main" java.security.AccessControlException:
access denied (java.io.FilePermission //dev/salsa/classes read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
…
Hmm…this looks like we need some permissions granted. That‘s easy, let me go
the $JRE/lib/security directory and change the java.policy file
and add a new grant permission and it should all be fine. So I edit the
java.policy file and add the grant permission:
grant codeBase "file://dev/salsa/classes" {
permission java.io.FilePermission ">", "read";
};
I run the program thinking I fixed the problem for good. But not so fast! I
see the same exception again. Then it hit me again. I had committed another
silly error. It appears that I gave 2 slashes (file://…) to the codebase
to separate the protocol and the url.
So I quickly undo the changes I made to the java.policy file.
I go back to the codebase property and this time I set it as follows:
java.rmi.server.codebase=file:/dev/salsa/classes
I restart my RMI server and voila! Everything works fine this time!
Thought this record of my silly errors might help someone else sometime.
[J] Thanks to Jeremy Pitten
for reminding me the codebase settings.
RMI Java Programming
April 20th, 2005
Over the years, I have worked on and off on rich user interfaces. Recently, I have been pluggin away at a Swing UI for a cool project called SALSA that I will write about some other time. If you have ever used the Swing GridBag layout, I am sure you will identify with this cool Flash animated weblog by Matt Quail. I sure do.
So for many years, I have struggled with GridBag everytime I use it.
But ever since Netbeans 4 was released, I have been liberated of this curse of the GridBag. NetBeans makes Swing development fast and easy and no more messing around with gridbag constraints, layout issues, etc. (unless you like to).
As part of my customer facing job, I have used all the Java IDEs out there. But for me, when it comes to Swing in specific, and Java in general, nothing beats the new Netbeans!
I Love NetBeans! Thanks, Netbeans team!
Check it out!
March 15th, 2005