Bech on Enterprise Java
Thursday, June 16, 2005
Java SE: Avoiding NullpointerExceptions by not initializing local variables to null
I'm sure this is fairly obvious to a lot of experienced programmers. However, having not paid enoght attention to the small details this was recently pointed out for me (emberrasingly enough!) It's now a part of my "good coding practices".
In this piece of code we might get a NullPointerException at the 0.toString(). This happens if an exception is thrown inside the try/catch block We shold have logged the event and terminatet the flow of execution in the catch block, but forgot to do so!
public void bad() {
Object o = null;
try {
o = callSomeMethod();
} catch (Exception someException) {
someException.printStackTrace();
}
o.toString() ;
}
This code compiles, but will result in a nullpointer exception when in the cases where someMethod throws someException.
Situations like this can easily be avoided by not initializing the variable o to null. In this piece of code we not NOT initialize the object o, and get a compiler error at the .toString() method call, because there is a change that the variable 'o' has not been initialized.
public void good() {
Object o ;
try {
o = callSomeMethod();
} catch (Exception someException) {
someException.printStackTrace();
}
o.toString() ;
}
By avoiding initializing local varibales to null, we can avoid some of those NullpointerExceptions, and get more robust code! ¶ 12:59 AM 3 comments
In this piece of code we might get a NullPointerException at the 0.toString(). This happens if an exception is thrown inside the try/catch block We shold have logged the event and terminatet the flow of execution in the catch block, but forgot to do so!
public void bad() {
Object o = null;
try {
o = callSomeMethod();
} catch (Exception someException) {
someException.printStackTrace();
}
o.toString() ;
}
This code compiles, but will result in a nullpointer exception when in the cases where someMethod throws someException.
Situations like this can easily be avoided by not initializing the variable o to null. In this piece of code we not NOT initialize the object o, and get a compiler error at the .toString() method call, because there is a change that the variable 'o' has not been initialized.
public void good() {
Object o ;
try {
o = callSomeMethod();
} catch (Exception someException) {
someException.printStackTrace();
}
o.toString() ;
}
By avoiding initializing local varibales to null, we can avoid some of those NullpointerExceptions, and get more robust code! ¶ 12:59 AM 3 comments
Monday, June 13, 2005
Team dynamics; What happened to all the emails ?
After working two or three weeks as a consultant for a very small client I'm puzzled by my current working environment!
My sureprise might come from fact that I've spent the last three years as an employed developer in in a fairly large financial organisation. A month ago I had a spacious desk, located in an open office solution with my project coworkers located in both the same room and the one adjacent. The customer was located in a different building.
At the moment, Im crammed into a small office, working with six or seven developers, litteraly sharing a desk with a co-worker. The closest thing to a "Customer", is the manager of the company (also speaking "tech") coming in from coffee once in a while.
It's natural to guess that it's going to be less formal and written communication in such an organisation, but what sureprises me is that almost no emails are sent!
Working for the large oranisation , I would often write lengthy emails to developers working in the room adjacent to mine, and cc the customer (or project manager) just to keep things "on the record" or to inform. I would use email to send files, tools, documents or whatever information that I wanted to distribute to team members.
The Outlook calendar was the plan of the day, and I would use it to organize meetings with my co-workers (located in the same room!) Even repeated meetings were scheduled this way.
Now things are different. USB Memory sticks are litterly flying around in the room, other files, links, code and documents are transfered using MSN or other IM variants. Meetings seem to be organised on a "need to have" basis, both regarding to timing and who actually participates.
In three weeks, I have received one or two emails from team members, in the same period of time, working for the financial institution my number written and receieved project related emails would have been in the range 100-150 (aproxemately 10 a day).
Im not sure what to make of this; It's just very interesting to see how different teams work differently. But Im sure I could have spent less hours writing emails and more hours writing code :-) ¶ 12:35 PM 3 comments
My sureprise might come from fact that I've spent the last three years as an employed developer in in a fairly large financial organisation. A month ago I had a spacious desk, located in an open office solution with my project coworkers located in both the same room and the one adjacent. The customer was located in a different building.
At the moment, Im crammed into a small office, working with six or seven developers, litteraly sharing a desk with a co-worker. The closest thing to a "Customer", is the manager of the company (also speaking "tech") coming in from coffee once in a while.
It's natural to guess that it's going to be less formal and written communication in such an organisation, but what sureprises me is that almost no emails are sent!
Working for the large oranisation , I would often write lengthy emails to developers working in the room adjacent to mine, and cc the customer (or project manager) just to keep things "on the record" or to inform. I would use email to send files, tools, documents or whatever information that I wanted to distribute to team members.
The Outlook calendar was the plan of the day, and I would use it to organize meetings with my co-workers (located in the same room!) Even repeated meetings were scheduled this way.
Now things are different. USB Memory sticks are litterly flying around in the room, other files, links, code and documents are transfered using MSN or other IM variants. Meetings seem to be organised on a "need to have" basis, both regarding to timing and who actually participates.
In three weeks, I have received one or two emails from team members, in the same period of time, working for the financial institution my number written and receieved project related emails would have been in the range 100-150 (aproxemately 10 a day).
Im not sure what to make of this; It's just very interesting to see how different teams work differently. But Im sure I could have spent less hours writing emails and more hours writing code :-) ¶ 12:35 PM 3 comments
Sunday, June 12, 2005
Distributed Caching mechanisms and sharing data in a cluster
Working in the area of telecom, I just had the need to share data in an environment that has to ble highly scalable. The system will be set up as a cluster of BEA weblogic servers.
So.. How is it possible to share data, and efficiently cache data in such environments ? Im currently researching this, and have to implement some kind of sollution. The alternatives so far seems to be either to do it in the managed Weblogic environment, or do it on a lowever
level (Using socket communications).
Managed environments
This article describes a mechanisms for configuring up a Cache MBean in the weblogic server.
This article describes both an "easy to configure" solution that requires the administration server to be up and running all time. That is probably not acceptable in a HA environment.
It also introduces a JMS based broadcast sollution that are more robust, but requires more code.
http://dev2dev.bea.com/pub/a/2004/01/jiang.html
Using lower level mechanism
Distributed sharing of data and caching is also possible using TCP/UDP directly. The downside is that you have to configure this outside the component container, reducing maintainability.
(Copied from the site) JCS is a distributed caching system written in java for server-side java applications. It is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, the JCS is most useful for high read, low put applications. Dynamic content and reporting systems can benefit most. However, any site that repeatedly constructs pages, dropdowns, or common search results from a database that is updated at intervals (rather than across categories continuously) can improve performance and scalability by implementing caching. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system.
http://jakarta.apache.org/jcs/index.html ¶ 7:24 AM 0 comments
So.. How is it possible to share data, and efficiently cache data in such environments ? Im currently researching this, and have to implement some kind of sollution. The alternatives so far seems to be either to do it in the managed Weblogic environment, or do it on a lowever
level (Using socket communications).
Managed environments
This article describes a mechanisms for configuring up a Cache MBean in the weblogic server.
This article describes both an "easy to configure" solution that requires the administration server to be up and running all time. That is probably not acceptable in a HA environment.
It also introduces a JMS based broadcast sollution that are more robust, but requires more code.
http://dev2dev.bea.com/pub/a/2004/01/jiang.html
Using lower level mechanism
Distributed sharing of data and caching is also possible using TCP/UDP directly. The downside is that you have to configure this outside the component container, reducing maintainability.
(Copied from the site) JCS is a distributed caching system written in java for server-side java applications. It is intended to speed up dynamic web applications by providing a means to manage cached data of various dynamic natures. Like any caching system, the JCS is most useful for high read, low put applications. Dynamic content and reporting systems can benefit most. However, any site that repeatedly constructs pages, dropdowns, or common search results from a database that is updated at intervals (rather than across categories continuously) can improve performance and scalability by implementing caching. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system.
http://jakarta.apache.org/jcs/index.html ¶ 7:24 AM 0 comments
