At times the problem with Java eco-system is its complexity due to availability plethora of choice of tools/frameworks. Getting a basic application with appropriate stack working is the big hurdle.
Same goes with the effort to get the Gwt-Spring-Hibernate stack working.
There have been lots of references about Gilead and Gwt-Sl libraries and how to use them to glue the stacks together but couldn’t find a complete deploy-able application. Hence this post.
Here is a complete deploy-able war file and its source. The example uses the following libraries.
- Smart Gwt
- Gwt
- Gwt-Sl
- Gilead
- Spring
- Hibernate
- Hsqldb
Download the war, deploy and test it. Explore the source to get the understanding of stack. Post a comment if you have any questions.
Sometime back I posted about Java Text Table Formatter. As I worked on that, I realized that most of the data export model could be reused to export the content in various formats, like Xml, Html or Json etc.,
To that end, I started to refactor the code base to support various formats and I’m releasing it as new project data-exporter. It is very simple and flexible library to export the data in various formats. Check out the features and try it out. Let me know if you want some specific feature.
For one of the open source project I was working on, I wanted a library which would format the given data set in text table format. Even though I found a library which sort of provides this feature (http://trac.inamik.com/trac/jtable_format) but features were not good enough. More over from the example it looked very complicated to construct the data set as it was not possible to hook up directly into the existing data set (like beans or list).
So I decided to write one and after four days of night coding, I’m releasing the Text-Table-Formatter at Google code. I dedicate this to Madhu. Happy anniversary. Check it out and let me know your feedback.
As a technical person working in Java related technologies, I have come across many situations where I was looking for a tool but either was not available or not meeting the expectation. So end up in writing them myself. I have grouped them together and released them in Google Code as JD Tools.
As of now, it has a tool called JarVer but I will be adding more in coming days. So please use it if you find it appropriate.
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");
}
}
Recent Comments