14 May 2005
Lately we’ve been re-using a few legacy components in other applications and its forced me to think a little bit about developing for re-usability.
Here are a few off the cuff thoughts on re-usable component development
1) Adequately comment all public/protected (and ideally private) methods.
– By adequate I mean full javadoc including expected parameter value ranges, is null?, etc. If a method throws an exception (checked or unchecked), includ
e that in the documentation.
– If appropriate, consider external non-code documentation for the component.
2) Provide controlled accessors to variables instead of direct access.
– Avoid allowing people to do componentInstance.variable = null. It’s just good coding habits.
3) A failure in the component should not bring down the calling application.
– No one would actually consider doing this right? but a System.exit() inside a method is just plain terrible and unacceptable.
– Exception conditions should be handled appropriate and resources/connections closed.
4) Adequate (but not excessive) logging
– Make proper use of the different logging levels.
– Don’t hardcode log4j usage and create an unwanted dependency in calling applications.
– Don’t log stack traces and then proceed to re-throw the exception: ie)
catch (IOException e)
{
// this logger is worthless and may cause unnecessary console prints
// in the calling application.
logger.error(“Error accessing file: ” + file, e);
throw new CustomException(“Error accessing file: ” + file, e);
}
5) Unit-test
– A unit-test should help self-document and code review the component. The unit test should cover all boundary conditions on variables and alert the devel
oper if they missed something.
– A unit-test will act as a form of documentation showing expected uses and results.
– A test will serve as a foundation point that other developers can build upon as they integrate. There’s nothing worse than wanting to use a component bu
t not being sure if it actually works correctly and having to test it yourself.
6) Interface development (updated)
– Start with the development/specification of an interface between your code and the outside world.
– When it comes time to implement your component, program to the interface.
– Avoid directly calling/loading of implementing classes, consider the use of Factories or alternatively DI frameworks like Spring.
I’ve got to run now so that’s all for now.
13 May 2005
Well, we’re not a dot com, but we (GenoLogics Life Sciences Software) did just move into very nice new office di
gs. Of course it wasn’t the first thing we spent the VC money on so I guess that drops us from the .com designation.
It’s been an interesting two years, seen the company go from 2 employees to 30, $0 in the bank to fairly significant VC investment. Looking forward to the
future and all the responsibility that’s going to bring.
We took a bunch of pictures of the old office today and I’ll post them whenever I get them from Sandy’s digital camera. I’ll take some pictures of the new
office when I get my new coolpix.
Moving sucks tho! We changed phone systems, going from a traditional PBX to VOIP. VOIP is going to be nice but it looks like we have a few wiring mishaps
so theres a few ports that are in-active and won’t be usable by developers come monday morning. Fun stuff! Other than that, new desks, dedicated server
room, kitchen complete with the uber expensive capucino machine (don’t drink coffee personally so not really a benefit). All that’s missing is the plasma
and the futons (and the fountain pop machine from the success days)
09 May 2005
Went to Sun’s Code Maneuvers 05 Session last Monday in Vancouver, B.C.
I’ve included notes on some of the talks below. It was alright, nothing too spectular or ground breaking for me but the overviews provided were beneficial
to others in my group.
The following notes are unfiltered. I didn’t have my laptop on at all times nor was I present for all presentations.
==============================
Keynote
Missed the keynote but the buffet on the ferry was good. Supposedly it was about J2ME and looked cool.
J2SE 5.0
Missed the first half of this presentation but it was a good overview of whats
new in tiger. New foreach, generics and annotations look worthwhile. Missed the comments on the new concurrency utilities.
Java Web Services
Personally I don’t have an interest in web services so I pretty much just zzz’d through this presentation. Was a little bit overly focused on Sun’s spec f
or JBI. The whole service oriented architecture sounds plausible but also just makes sense when developing. They showed a before and after picture of goi
ng from a ‘traditional’ system to a SOA system. Sure SOA painted a prettier picture but in reality, you’re going to be re-using components either way. Ta
king a web services would make hooking up a distributed system easier but I’m of the belief that SOA is more marketing than true breakthrough.
J2EE Persistence
Nothing new here. Touched on CMP, JDO, Hibernate, etc. Was 45 minutes long and didn’t touch on anything I didn’t already know. We had 2 coops with us so
it was valuable for them.
Java Studio Creator
I’m an eclipse user. Not too interested in switching ide’s at this point. Started talking about java server faces and got into how Java Studio Creator ca
n make your life easier.
CodeCamp: J2SE & J2EE Performance
Use StringBuilder instead of StringBuffer for unsynchronized cases. Performance improvement in JDK 5.0. New smart tuning techniques should do as good a j
ob as hand tuning (eliminates the need for setting heap sizes, etc). GC mechanisms are different between client/server configurations (server has parallel
gc’s, client has serial).
Use ArrayList vs. Vector for unsynchronized cases (Vector’s methods are synchornized).
JDK 5.0 has native threading support.
Server class machine > 2 CPUs, 2GB Ram
Heap initially 1/64th physical memory, max 1/4 physical mem (up to 1gb). User is able to specify throughput and JVM will try and reach it.
NetBeans sets XX:PermSize to 20MB, XX:MaxPermSize (added performance??)
General Tuning Advice:
1. Continue profiling. Look for bottlenecks and adjust parameters to optimize performance (GC tuning, etc).
2. Allocate more memory to JVM (64MB is default)
3. Set -Xms and -Xmx to be the same (increases predictability, improves startup time)
‘GC Portal’ can be used to analyze ‘verbose:gc’ output (not sure if JDK 5.0 only???)
Use Jconsole to connect to local and remote applications (JDK 5.0 only feature but looks cool)
Could also use visualgc to visual gc
http://java.sun.com/developer/technicalArticles/Programming/GCPortal
J2EE
Cache EJB references to avoid JNDI lookups
Cache bean specific resources in setSessionContext() or ejbCreate() (release resources in ejbRemove())
Remove stateful session beans when not needed
Caching is used when number of concurrent users of beans exceeds that of maximum allowable number of bean instances.
Avoid passivation (modify pool sizes, etc.)
Ensure initial and max values of pool size are representative of normal and peak loads. Incorrect values could leave to unnecessary object creation and GC
.
Cache too big, longer and more frequent full GCs. Application server might run out of memory.
Cache too small, lots of passivation and activation, serialization and de-serialization.
Bigger cache for frequently used beans.
Entity bean caches larger than session bean caches.
Mark entity beans as read-only or read-mostly.
Commit option B avoids ejbActivate()/ejbPassivate() (usually better performance)
Commit option C better if beans in cache are rarely used.
To determine what to use, look at the cache-hits value using ejb server monitoring tools.
Misc Tuning: Avoid excessive directories in server classpath (affects class loading times).
sridhar.reddy@sun.com about getting notes