Java Links - Collection of Useful Java links

Many a times colleagues & friends who want to learn java were asking me to provide some good links to go through to start with. I compiled some set of useful links. I hope that this will be useful to all the people who want to know about Java.
In Java world, the difficulty isn't to find good API but is to use it well. Moreover, the Java API is too large to memorize all. That's why, the internet links are important. You name any task there will be minimum more than 10 ways of accomplishing in Java, that's the strength of Java. But irony is that's fastly becoming weakness as well compared to RoR & .NET at least in developing web applications. Having lot many options is not always good :-)
Each technology (Desktop, Enterprise, Content Management, Web applications...) is so big that each has enormous amount of information to learn. Here I have included the links that are generic in nature useful for starters.

Resources from creator of Java - I always maintained that Java API (JavaDoc & Java source code) is "the best" resource, Most of us don't realize this.
Java 6 - Programmer Guide
Java 1.5 API Specification
Sun Tutorials
Technical Articles from sun based on category

Most Java books are written by people who couldn't get a job as a programmer, since programming pays more than book writing. Most of the time they are outdates & comes with bad examples. This is especially true for free books, but I guess these books (Especailly first 2) deserves reading.

eBooks - Free
Java Language Specification - James Gosling- Father of Java It's like Ritchie book in C,
Thinking in Java - Bruce Eckel One of the best writer, Has also written books like Thinking in C++ along with other Java books. Now a days he is putting efforts behind Adobe Flex, RIAs
Object-Oriented System Development - Dennis de Champeaux, Douglas
Mastering Enterprise JavaBeans 3.0 - Ed Roman, EJB3.0 is definately not as bad as earlier versions.
Processing XML with Java - Elliotte Rusty Harold, I think we should avoid XML as much as possible, if required Groovy provides better alternative compared to Java
The J2EE Architect's Handbook - Ashmore - Don;t carried awayby the asserions
Servlets and JavaServer Pages: The J2EE Technology Web Tier - Falkner and Jones
Java Design patterns - James W. Cooper - Examples are provided in Swing
Well written set of Java Series books from Sun.

Good Java Websites
Sun's Java Site - Official java resources
Java practices - Supereb Collection of Java practices
The Server Side - Interesting discussion but usually consists lot of marketting literature, So
don't believe what ever people say there.
IBM's developerWorks- Wealth of Java information - IBM has made huge java investment in developing literature of building large scale applications.But they are quite slow in supporting new stuff like weblogic guys.
Weblogic - dev2dev - #1 in providing enterprise software
Spring - Lightweight framework providers ,
JBoss - First popular open source application server, Now Gavin King author of HIbernate, Seam works for JBoss
The essential Java language library - The resources you need like you need air
JavaRanch - Good old Java certification site - But you are forced to see all sort stupid questions & answers, If you not interested in certification no need to go here.
O'Reilly's onJava - O'Reilly books are generally good
Good Applet resources
Kick Java
Java open Source Collection - My #1 site for looking into java open source options. All kudos to creators of this site.

Java Tech magazines
Infoq - My favorite, If I start a magazine it is going to be like this (BTW I am planning to launch one)
Net Beans magazine - Good place for all NetBean lovers
Parleys - Belgium based site with lots of quality presentation on various interesting Java areas
JavaWorld IDG's online magazine for Java language and programming professionals--featuring news, views, tips, tools, technologies, and more. But I guess these days we are not getting much content here
Java Report Online Online segments of Java Report, featuring Java Tutor, products and services listing, articles, jobs and more.
About java An in-depth collection of news, tips, articles, and tutorials.
Javaposse News,Interviews about java.
Java Skyline - Magazine for Server Java developers
Java Developer Journal - Self proclaimed #1 magazine, with lot of ads.
Java Jazz Up -free online magazine on Java Technology
DevX - Java zone - Very good articles, again lots of ad
java blogs - A java blog aggregator.

learntechnology.net (EJB, JMS, Ajax, iBatis, Struts, Wicket, ...)
The Java Memory Model (lot of ressources ...)
Free Java EE (J2EE) Training Online

Some interesting DB related links

Storing tree in RDBMS

why too much database normalization can be a bad thing

Managing hierarchial data

Design Patterns - Nice explanation design patterns

I think these are important areas that any Java Programmer must be familar witth.
1. Java Programming
2. Java Collections -> Look at the apache commons as well as Google collections, You will understand both power & shortcomings of Java collections.
3. Java threading Model -> There is going to be lot of investment in coming years as the API that exploit the multiple CPU power are going to be important. Scala/Erlang is also important scripting languages to follow.
4. Understand the servlet model. You can look into source of Wicket or Tapestry pure object oriented component models for developing web applications. My Swing way of developing complex web applications is going to be popular in coming days. (WingS, ZK, Echo, GWT, JSeam)
5. Scripting/DSL is bringing lot of cahnges in development (Groovy looks to be the best bet for Java programmers), So it's also better to focus on Groovy support in Spring, Grails & Seam

Effective Java & Practical Java - The grand-old two books that are suggested for java basics.
I thought it might be helpful for Java programmers to glance through rule list as most of the recommendations here still have relevance.


Effective Java -Joshua Bloch
Creating and Destroying Objects
1: Consider providing static factory methods instead of constructors

Not always the best, Now a days Dependency Injection is better than factories for low coupling
We have 3 ways of instantiating a class,
1. Using 'new' operator
2. Using java reflection Class.forName("myClass")
3. Using clone() bitwise copying
4. Using Serialization (java.io.Serializable)
All have their own use-cases of use.
2: Enforce the singleton property with a private constructor

Over use of Singleton are regarded as bad practice because of increased usage multiple VMs & clustering. We have Singleton Detector (Google code) to find singletons and global state in the Java code that we produce to help us refactor them. This tool which analyzes Java bytecode and detects the use of Singletons.
Item 3: Enforce noninstantiability with a private constructor

Spring does this with abstract class (StringUtils) & static methods- I really likes this idea compared to private constructor.

4: Avoid creating objects

This also needs to be done based on requirement, With modren JVM's it's not so costly as you may think of, You can avoid re-instantiating heavy objects
like SimpleDateFormat in for loops etc... by caching them as private static final member variable. We should avoid creating duplicate objects
5: Eliminate obsolete object references

Google collection APIs should help us for better use of Java collections
6: Avoid finalizers

Why this was invented in the first place, there is no need of finalizers
Methods Common to All Objects

7: Obey the general contract when overriding equals
8: Always override hashCode when you override equals
Now IDE like NetBeans 6 provide the option to automatically do this.
9: Always override toString
This can come handy while analzing the logs, Again with modren debuggers we hardly need toString()
10: Override clone judiciously
Ideally Cloneable should be having clone() method instead of being a marker interface , I am still not convinced on the importance of Marker interfaces
(Serializable, Remote etc...)
11: Consider implementing Comparable
Yes sorting may be required @ any point of time & these days it's better put more work on JVM than the Database
Classes and Interfaces
12: Minimize the accessibility of classes and members
Make all members private, Give me explanation if you think otherwise
13: Favor immutability
I don;t think it's valid with modren JVM's there is no need to make inline (making final) the code, JVM takes care it automatically
14: Favor composition over inheritance
non intrusive model better compared to intrusive model, POJO's better compared to EJB (not the JEE version of course :-))
15: Design and document for inheritance or else prohibit it
Spring is a wonderful example of this principle& struts the worst offender
16: Prefer interfaces to abstract classes
Spring is a wonderful example of this principle& struts the worst offender
17: Use interfaces only to define types
18: Favor static member classes over nonstatic
I guess this is debatable
Substitutes for C Constructs
I am not sure how many people are really interested in converting C programs to Java now a days
19: Replace structures with classes
20: Replace unions with class hierarchies
21: Replace enum constructs with classes
Now we have enum type in Java 5
22: Replace function pointers with classes and interfaces
Methods
23: Check parameters for validity
Throw IllegalArguemtException for any errors & don;t throw checked Exception.
24: Make defensive copies when needed
25: Design method signatures carefully
26: Use overloading judiciously
I say don;t use it.
27: Return zero-length arrays, not nulls
Good point, For objects use Null Object pattern
28: Write doc comments for all exposed API elements
General Programming
29: Minimize the scope of local variables
30: Know and use the libraries
Don;t use any library blindly, Look into the code.
31: Avoid float and double if exact answers
are required
32: Avoid strings where other types are more appropriate
Again debatable point, I have seen people arguing String for even 'id' value, With the popularity of scripting languages I guess over-use of String not an offence as long as it simplifies coding
33: Beware the performance of string concatenation
There is one myth involved with this, Now if you use '+' operator for concatenation, it is better compared to StringBuffer & the Compiler(JDK1.5)
automatically does this for you by using non -synchrized StringBuilder classes.
So use '+' freely, Use StringBuffer if you need synchronization which is rare anyway.
34: Refer to objects by their interfaces
Use Java 5 Generics
35: Prefer interfaces to reflection
Now java reflection performance has improved a lot.
Hibernate used CGLIB (byte code manipulation framework) against java reflection
Now I am sure Gavin King would have selected Reflection with modren JVMs.
36: Use native methods judiciously
I say don;t use it, It's better to re-write
37: Optimize judiciously
38: Adhere to generally accepted naming conventions
Follow the Sun rule, I also discussed in length about java coding conventions in one of my previous blog
8 Exceptions
39: Use exceptions only for exceptional conditions
40: Use checked exceptions for recoverable conditions and
run-time exceptions for programming errors
41: Avoid unnecessary use of checked exceptions
42: Favor the use of standard exceptions
43: Throw exceptions appropriate to the abstraction
44: Document all exceptions thrown by each method
I guess it's better to choose the long meaning names as nobody reads Javadocs these days.
45: Include failure-capture information in detail messages
46: Strive for failure atomicity
47: Don't ignore exceptions
here is ultimate explanation on Exception Handling
Wonderfully explained concept "Runtime=FaultException" & "Checked=Contigency" , a progmatic way of using Checked (extending Exception) & UnChecked (extending RuntimeException)
9 Threads
48: Synchronize access to shared mutable data
49: Avoid excessive synchronization
50: Never invoke wait outside a loop
51: Don't depend on the thread scheduler
52: Document thread safety
53: Avoid thread groups
10 Serialization
54: Implement Serializable judiciously
55: Consider using a custom serialized form
56: Write readObject methods defensively
57: Provide a readResolve method when necessary

---

Practical Java - Peter Haggar

General
Understand that parameters are passed by value, not by reference.
Use final for constant data and constant object references.
Understand that all non-static methods can be overridden by default.
Choose carefully between arrays and Vectors.
Prefer polymorphism to instanceof.
Use instanceof only when you must.
Set object references to null when they are no longer needed. Objects and Equality
Differentiate between reference and primitive types.
Differentiate between == and equals.
Do not rely on the default implementation of equals.
Implement the equals method judiciously.
Prefer getClass in equals method implementations.
Call super.equals of base classes.
Consider carefully instance of in equals method implementations.
Follow these rules when implementing an equals method. Exception handling
Know the mechanics of exception control flow.
Never ignore an exception.
Never hide an exception.
Consider the drawback to the throws clause.
Be specific and comprehensive with the throws clause.
Use finally to avoid resource leaks.
Do not return from a try block.
Place try/catch blocks outside of loops.
Do not use exceptions for control flow.
Do not use exceptions for every error condition.
Throw exceptions from constructors. -> This is very tedeous
Return objects to a valid state before throwing an exception. Performance
Focus initially on design, data structures, and algorithms.
Do not rely on compile-time code optimization.
Understand runtime code optimization.
Use StringBuffer, rather than String, for concatenation. -> Is incorrect statement with JDK5 onwards
Minimize the cost of object creation.
Guard against unused objects.
Minimize synchronization.
Use stack variables whenever possible.
Use static, final, and private methods to allow in lining.
Initialize instance variables only once.
Use primitive types for faster and smaller code.
Do not use an Enumeration or an Iterator to traverse a Vector.
Use System array copy for copying arrays.
Prefer an array to a Vector or ArrayList.
Reuse objects whenever possible.
Use lazy evaluation.
Optimize source code by hand.
Compile to native code. Multithreading
Understand that for instance methods, synchronized locks objects, not methods or code.
Distinguish between synchronized statics and synchronized instance methods.
Use private data with an accessor method instead of public or protected data.
Avoid unnecessary synchronization.
Use synchronized or volatile when accessing shared variables.
Lock all objects involved in a single operation.
Acquire multiple locks in a fixed, global order to avoid deadlock.
Prefer notifyAll to notify.
Use spin locks for wait and notifyAll.
Use wait and notifyAll instead of polling loops.
Do not reassign the object reference of a locked object.
Do not invoke the stop or suspend methods.
Terminate threads through thread cooperation. Classes and Interfaces
Use interfaces to support multiple inheritance.
Avoid method clashes in interfaces.
Use abstract classes when it makes sense to provide a partial implementation.
Differentiate between an interface, abstract class, and concrete class.
Define and implement immutable classes judiciously.
Use clone for immutable objects when passing or receiving object references to mutable objects.
Use inheritance or delegation to define immutable classes.
Call super.clone when implementing a clone method.
Do not rely on finalize methods for non-memory resource cleanup.
Use care when calling non-final methods from constructors.

Some Architectural Notes:

"Practical Guide to Enterprise Architecture" book published by Prentce Hall has very readable contents. I enjoyed reading it. Here are some highlights

Architecture Is Business-Driven. This is the first and most important habit of an architect. All architectural undertakings should be done for the sole reason of solving business problems. Architecture planning is a continuous process that requires full alignment with business goals.

Communication Is King. Enterprise architecture must be communicated to all parties across all IT organizations and lines of business on an ongoing basis. This should include strategy, goals, and objectives. Its purpose is to increase awareness throughout an enterprise. It must also include a statement of shared values that are endorsed and supported by the executive team and incorporated into the IT governance model.

Unification Is Queen. For enterprise architecture to succeed, it must be unified across the enterprise. Success and failure of all forms of architecture depend upon the joint efforts of all business and IT areas, their support of the architecture, and consistent implementation.

The Frog Is a Prince. Support from the executive team is essential for the practice of architecture, but a successful architecture starts almost at a grass-roots level by seeking support from line managers and their direct reports where the sell is the hardest. Getting buy-in from the troops (Seek first to understand, then be understood) will shield the architecture from passive resistance.

K.I.S.S.: Keep Infrastructure Simple. Information technology assets and the elimination of the endless combinations of platforms that use disparate technologies are the main inhibitors of change and result in an inflexible architecture. A goal of sound enterprise architecture is the destruction of incompatible technologies. If infrastructure is kept simple and consistent, enterprise architecture can leverage existing skill sets, training, support, and services in a cost-effective and agile manner.

Agility Is Key. Sometimes the best solution for a particular business problem requires adoption of a technology and/or approaches that are not mainstream. Agile enterprise architecture will allow the modification of standards to support business requirements, and it will seek out alternate ways to integrate the technology with the current architectural model.
Crawl Before You Walk. Expectations should be managed. The best architecture for an enterprise is one that evolves versus one that is created. Each iteration of the architecture should build upon previous versions and provide an incremental improvement to the organization. Enterprise architecture should also focus initial efforts on near-term opportunities—what is within reach—that can provide immediate business benefit. Small but quick wins will help win allies from both the business and technology areas and will best demonstrate the value of agile enterprise architecture.

---

It's very important to capture & communicate business/technology drivers well in succinct manner to all the stake holders.Defining architecture satisfying all the stake holder is a very difficult task. Un-informed stake holders will have unrealistic architecture goals. CEO expects application to scale for decades, Manager wants no duplication efffort at any cost & expect that to come completely from architecture, Developers exepects libraries to ease out their coding & Designers expect check lists.


All the stake holders are correct in their own way on the expectation from architecture, but unfortunately Architecture cannot accomplish all the individual requierements & it's important to set the expectation clearly.

Architecture -> Is About Making Technology choices. In my openion this is the most important feature that will have huge impact on any projects. Application maintainence, Deveoper availability should be given as much importance as techincal excellence of the tools that we choose.
Architecture -> Is About understanding the context. All patterns/anti patterns work with aparticular context. If we miss out this context the patterns/anti pattern knowledge can have adverse impact on our judgements.
Architecture -> Is About understanding of problem space & strong connection with business. Respecting the domain experts & their openion is very important here.
Architecture -> Is not just about Reusable artifacts but flexible artifacts. There will be always better ways for implementiion techniques as time progresses. So "re-use" is overloaded word. So I guess flexibility is more important thatn reuse. Interfaces & Dependency Injection (Spring is excellent in serving this pupose & latest version gets you out of XML hell as well :-)) is more important as they give the power of changing the implementation with better means over the time without much pain.
Architecture -> Is about understanding varying scalability requirements, Every one don't require eBay or Amezon kind of requirements. I have personally executed 3 eBay projects as a lead & the rules of the game is totally different for those kind of applications.
Architecture -> Is About breaking rules.eBay doesn't rely on transactions. The data is heavily de-normalized, Most of the processing happens at the application tier. The asynchronous channels are heavily used. ThreadLocal's are used heavily. Scratch DB is preferred way to store the session data. Scaling happens @ the web-tier & EJB's doesn't even qualify as contenders & the XSL templates rule the presentation layer.These rules are definitely not suited all kinds of applications. It was very difficult for me to come out of hang-over of eBay code base.

Architecture -> Is about understanding the Return On Investment & ability to predict the future with political, local & legal aspects in the mind. Documenting patterns & anti-patterns in these areas will be invaluable as experience/historical knowledge holds the key.

Identifying the need of different stake folders & making sure that architecture artifact look relevant to all stake holders is important.So it is better to write different documents focusing on different stakeholders.It is important to keep the theme same in all artifacts. For Example,"System Architecture" document should capture the over-all technical decisions that were made along with explaining the rational & tried alternatives. This document should act as technical design review check list. It's important document non-functional or operational requirements as clearly as possible. Architecture goals and means (usually debating 2-3 options for achieving the same).Integration of various application modules (critical ones).
For any web based applications screens plays very important role & they capture the requirements in best manner. This exercise ideally should be part of requirements definition & this "System architecture" definition process should begin sometime during the middle of requirement definition. Unfortunately it's a tedious task define the screens manually& as of now there is no credible way to convert HTML directly into production by few tweaks (Frameworks like Tapestry & Wicket web frameworks certainly makes better compare to other approaches).
"Application Architecture" Should capture the different technical layers & their components. It also should capture the over-all application modules & their relationships. Integration is the most painful aspect development as it not only involves code integration it also requires to people also communicate & integrate. More emphasis should be given in declaring the interfaces & handshaking mechanisms between the teams & modules.

Conclusion:
Software Architecture is very challenging, I guess aspiring Architects need to focus get in touch with real developers & do active coding rather than relying on marketing literature available in Internet. The best brains sitting in ivory tower developing specification (Martin Fowler calls them Harvesting frameworks) really doesn't add much value compared to specification/frameworks that comes out as by-product of developing real time applications like Spring, Rails. (Non Harvesting frameworks). Unless Software Architects stop forming their opinions based marketing literature and blogs, they will be forced to be called as "White Elephants" of software industry.

Some tips on developing Swing applications:

I recently developed one small application in swing . Here are some comments on tricks & libraries I used.

1. Using Template Method Pattern to simplify code

ActionTemplate :

JButton button = new JButton("Ok");
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent event){
//do some stuff here
}
});

This is how usually we handle the actions (I don't believe in separating out actionlisteners code from components declarations, it is always easier/better to keep them as near as possible) Anonymous classes provides easier way of achieving this;

from the above code I noted that,
1. In anonymous class, I will never use ActionEvent class & I don't want see it. It's an intrusive model.
2. Many times I want to handle actions asynchronously (like using SwingUtilitilities.invokeLater() routine), I don't want to repeat in every action listeners code.
3. I also want to display a wait cursor during this time & should be optional way of passing the icon @ runtime;
4. I also want to print the time taken & memory consumed for each actions; & I don;t want to repeat that, I also want to take that out from the code once the application in production.
6. actionPerformed method name is not intuitive, although ActionEvent not used 90% of time I do use it 10% of time when I write inner or separate ActionListener classes, it should be available for me.

Here is how I propose to handle this using template pattern.
ActionTemplate is abstract class having clicked() as abstract method & with default implementation for all other features.

button.addActionListener(new ActionTemplate() {
public void clicked(){
//do some stuff here
}
});
This is fine for me 90% of time.Now code is less & looks simpler. This is clearly non-intrusive model & all the extra features are defaulted and can be easily changed by over-riding when required. (Convention over configurations)

In case to handle the event asynchronously whenever some tasks lot of time, we can over-ride isAsynchronus call. isAsynchronus() will return false by default.

button.addActionListener(new ActionTemplate() {
public void clicked(){
//Some lengthy stuff here, So cannot make AWTDispatch thread to wait till it's completed
}
public boolean isAsynchronus(){
return true;
}
});

Similarly there can be callback methods for setting the wait cursor, monitoring completion status, (getWaitCursorIcon(), done() etc...)
We can also get the ActionEvent which is member variable for ActionTemplate class.

Similarly for WindowTemplate we can add closed, closing, max(), min() etc...
& for MouseTemplate methods like pressed(), clicked(), hover(), rightClikced(), doubleclicked() etc...
These will easier to understand & code than their Listener counterparts. I guess this approach is near to closures. Lack of closure in java is really a bottleneck while coding event handling. We are forced to deal with anonymous & final variables

Although I don't feel these tricks can be used in large projects (As adding more APIs to likely to confuse more) but this type of techniques will be very useful when we write applications in a very small team or by a single person, where using AOP, XML, Properties file based action handling framework using reflection is not an option (because of learning curve & the increase in total java source/jar size)

2. Window Dissolving tricks
While going through the Swing Hacks book, I came across one dissolving hack. I also wrote some inspired from that, although they are too simple but can give window closing a different experience :-), Feel free to copy & use it from here.

3. External libraries
There is no point re-inventing the wheel, there are abundant high quality JFC components freely available, but the problem is most of them will come big baggage (in terms of size & API complexity).
I used these libraries & had no problem whatsoever with these.
JFreeCharts - For reporting through charts
iText - For Generating the pdf reports
I have used these excellent libraries in the past (but with J2ee applications)
DesignGridLayout - As layout manager

It is always better to code these in such a manner that if even when we take out these jars, application should work properly.It is always better to make these libraries not to be part of core functionalities. I handled these by neglecting ClassNotFoundException in appropriate place where-ever I am using such libraries. In case of applet & webstart it is not practical to use these heavy libraries as they increase the download time & there might be issues with licensing as well. So for an applet/java webstart versions JFree charts, iText & other external jars will not be included, I just remove these jars from library to make it light weight, that's it no code change required :-)

4. Layout Manager
I did not wanted to use the GridBagLayoutManager, it was regarded as un-necessarily complex for developing Swing applications. I tried out generating UI with my favorite IDE NetBeans. I did not like the code it generated. May be I need adjust with this kind of code in future. First the code generated was looking ugly & I wanted to use my custom components which I need to add & I like doing small tasks by defining actionlisteners there itself, the code generated lot of default methods. As of now I can think of using it only for prototype.


I looked into layout managers who all claimed to be better alternative to GridBagLayoutManager, I actually looked into the code of most of these layout managers & they are indeed provide lot ease in developing layouts,some introduce more complexity
I came across this debate on from layout manager showdown, All kudos to John for the splendid job done by comparing layout managers.
I found MigLayout to be best in solving all types of complex requirements, But for my screens I found DesignGridlayout the simplest after going through the sample code. As it is based in standard JDK library, this should be first choice for developing simple grid based screens.

For example, I wanted to design my layout something like this;

& it took 12 lines to do that, & code was too simple.

public void build(DesignGridLayout layout){
layout.row().center().add(title());layout.row().height(10);
layout.row().center().add(new JLabel("Email ")).add(user());
layout.row().height(5);
layout.row().center().add(new JLabel("Password ")).add(pwd());
layout.row().height(5);
layout.row().center().add(new JLabel("Exam List")).add(examList());
layout.row().height(5);
layout.row().center().add(signIn());
layout.row().height(15);
cancelButton = new JButton("Cancel");
loginButton = new JButton("Ok");
layout.row().center().add(loginButton).add(cancelButton);
}

It was such a simple task to develop for other such screens as well

5. Code Samples from Experts
Swing Hacks & Filthy Rich Clients are the best books on swing written by highly credible authors. The source code that comes with these books are also excellent resources.
There are quite very nice ideas explained well for developing custom components. Source code for the both the books can be freely downloaded, but I suggest to buy the books.

These are the excellent code I re-used in my application
Pieter-Jan Savat's wonderful utility on page turning effects in swing.
Simon's flashy & bouncy effects with swing.
Hyper Link listener for handling links

6. Leveraging New JDK1.5 APIs Features:
Using new JDK1.5 features can simplify the coding to great levels; JDK1.5 has been one of the biggest release in java's history.
For example, now it is possible to add data to the to list like this;
List l= list("praveen","manvi","test"); using

public static List list(T... elements) {
List list = new ArrayList(elements.length);
for (T elem : elements){
list.add(elem);
}
return list;
}

These tricks will be useful especially writing Models for UI components. The above sample shows the usage of improved for() loop, generics & variable argument options.
I found this explanation good with samples.

Java Coding Guidelines
Establishing coding guidelines is one of the main task for Technical Lead or the Technical Architect for any newly starting project. This is one of the ritual which attracts very little attention form both developers & management.In past I have tried to set up coding standards for J2EE based projects & came up with guidelines for each layer (Service, DAO & Presentation).Although it was well advertised, most of the developers did not even seem to interested in looking into the content & were happy to follow the prototype. In that sense establishing a coding guidelines is the least impressive job & probably the most thankless job.

With this background, I started looking into the existing published coding guidelines with the intention of extracting best of all the published guidelines. Surprisingly Sun published java coding guidelines in 1999 & never thought it to be worth revising.I also looked into the other big java shops like IBM,eBay,BEA & Oracle, I couldn't find any content that focuses solely on coding guidelines (Please correct me if I am wrong on this).

Most of the information I found on coding guidelines was repetitive. With Java replacing C,C++ as primary computer learning language & with best IDEs taking care of indentation, style etc... there is no need to have full fledged coding guidelines & I guess Sun is right in not revisiting their coding guidelines document. So coming up with Java coding standards doesn't make sense, the best option would be come up with Technology centric coding guidelines (SWING, EJB ,Spring, custom framework etc...) to really have some value addition in this area.

So I am enumerating few topics here that I have observed over the years while writing Java code & mentoring programmers. I guess the that's the better option than coming up with a clone of sun coding standards by changing some content here and there.

These are some mistakes (or bad practices from Java point of view) I found with the guys coming from C++ background & junior engineers in my experience:
1. Method name starts with capital letter (Like GetThis() etc..)
2. Passing reference & manipulating them (Writing methods like void getData(SomeObject obj) etc...)
3. Very conservative about writing many methods & classes (over cautious about the performance)
4. Poor understanding of abstraction
5. Writing lot of static methods
I think best way to understand the Java coding standard is by going through the source code of JDK.

Objective of coding standards:
- Creating concise code
- Improve readability, maintainability & continuity (Programmers changing over the time should have least impact)
So although it is trivial, it is important for the organization to enforce the coding guidelines strictly(Sun java guidelines).

List of some good Coding Guideline links:
Sun Java Code Conventions
Coding standards from nejug
Standard Java coding guidelines -This I found it very interesting as it was trying layout the guidelines on OO principles.
I am planning to come up my own standards some time in future.:)

I really liked the idea of Google where they have listed out only the missing information from Sun standards, This is the approach I am going to suggest for my future projects as well.

The most important point I feel in writing the good quality code is considering the good design principles & have them as part of coding checklist.I have also published some points on presentation layer in one of my previous blog.

Here are my favorite picks:
1. Handling NullPointerException
This is most disgraceful error that a programmer can make, I always used to treat this exception as insult the programmer's intellect. Before calling any methods programmer needs to ask himself a question "Hey can this be Null" if he thinks it can be a null, then putting Null check is also not always correct. I personally hate null checks in the code. Most of the time it is like looking at both side of the road while crossing a one way road.
So I prefer throwing IllegalArgumentException & usage of assert keyword

2. Exception Handling
Spring, Hibernate & other popular frameworks have established one fact that Checked Exception are over-used & Runtime exceptions offers best solutions in most of the cases. Although James Gosling hails Checked Exception or Fault containment as one of the best feature of Java I tend to agree with usage of Runtime Exceptions heavily with the caviet that if there is alternate flow that API user can handle or we are writing APIs & exposing them to third part checked Exceptions are the best.

All the Exception that happen very rarely & is because of hardware/network or programmatic errors which end user can't really help should be declared as RuntumeExceptions & any checked exception thrown by other APIs should be declared in throws bloc if we can't take any action in the try{}catch{} bloc.Exception should be thrown only in case of alternate flows.FinderException is very bad design in EJB as it throws Exception if there are no records rather than returning empty list, that's silly.

With the above stated principle RemoteEception should have been RuntimeException & ParseException (For example Integer.parseInt(String str) is likely to go wrong should have been Checked Exception.

3. Usage of proper APIs
There are quite lot of hidden gems of Java that are under-utilized, Like java reflection, WeakHashMap & lazyloading with Runnable can really make applications more faster and robust. Spending time Javadocs is most useful exercise.

We need tools to correct the mistakes, We need to make static analyzers intelligent enough to take care of all the unit testing issues & performance issues. Tools like PMD offers the huge benefits in terms of productivity and improving the quality of code. The plug-ins available for popular IDEs like NetBeans, eclipse makes developer life still simpler.

PMD rules Index - There are about 200+ PMD rules for code checking.As prevention is better than cure, it always better if developer visits these before writing code.

Here are my best rule that can be used as mandatory ones
Unused Code Rules
Basic Rules
Optimization rules
Strict Exception Rules
Import Statement Rules

These rules also can be considered
Design Rules
Type Resolution Rules
Code Size Rules

Some bad rules;
AtLeastOneConstructor
CallSuperInConstructor
LongVariable
ShortVariable
I fully agree with this link on PMD Bad Rules.

Hammurapi,CheckStyle and Findbugs also provides similar rules, It will be good exercise to extract best out of all these.

Finally,
All the rules, Conventions & best practices are here to help us. We definitely not here to help these rules. Common sense should prevail over these guidelines. Consider what you like & disdain what you don't like.

SWING CORNER

I have been involved with development J2EE projects from past several years. As I am looking to work with a SWING project now, I wanted to collate all the information regarding the SWING that should help me refresh my SWING skills & also to help new programmer to ramp up on SWING quickly. I also wanted to use this SWING corner blog as my SWING books-marks for my future reference.So I will keep adding/editing the information here. :-)

Real time applications are best testimonials for any technology.Here are the set of real world applications for non-SWING believers.

Selected links to start with Java SWING for beginners:
wikipedia SWING Overview
Best place to start with SWING
Swing Pointers
Sun Tutorial about SWING architecture

It is always best approach to follow best SWING programmers to learn new techniques. Here is my favorite list & their blogs. All are committed SWING developers.
1. Romain Guy with amazing swing skills
2. Ethan Nicholas
3. Kirill Grouchnikov & http://www.curious-creature.org/
4. Shannon Hickey
One more interesting Blog

There are also equally credible people saying Java SWING has reached it's dead end :-( like Bruce Eckel of Thinking Java fame, So it is equally important to watch the Adobe Flex APIs & Flash. Also there is lot of effort is being put on developing JSF components. After looking into exadel , GWT & ICE Faces I feel like do we really need thick clients?

Some Useful Java Links that will be helpful for new development:
Lot of links Articles,Blog Posts,Interviews Commercial/Open Source Projects reated to dektop development
Libraries that can ease development effort
Great Swing Components from Swing labs
Popular layout managers (Gridbaglayout has been very un-popular & difficult to work)
FormLayout
TableLayout
JGoodies Validation https://validation.dev.java.net
JGoodies Binding https://binding.dev.java.net
Spin http://spin.sf.net
Foxtrot http://foxtrot.sf.net
Swing Code samples http://www.codeguru.com/java/Swing/index.shtml
Chart building solution for swing : http://www.jfree.org/jfreechart/ - Google AdWords & Jasper Reports uses these APIs

SWING Books & Frameworks:
Popularity of any technology can also be measured from the dedicated books that have been published, Considerably there are less books focusing completely on SWING, although most of Java generic books covers SWING superficially.

There are two books published by Orielly on SWING (Hacking Swing & Java SWING ) & both are good ones, There is one book from Manning publisher Swing in Action & there is also Desktop Java Live—published by SourceBeat.
USefulness of these books are limited as it will be totally API driven & time bound, the sample source code can be downloaded from the provided by these books & learn APIs by going though the code.I guess that's the best way.The cooper's book on Design patterns contains the design pattern samples developed in SWING. The book & source code are free & can be downloaded from here.

The single-most important point to choose Java as development platform for me is availability of massive amount of open source frameworks & utilities. I guess this point is not well appreciated by well known Java opponents Joel& Paul Graham (Although they are on my favorite writers list :-)). Unfortunately there are less number of frameworks & re-usable components in SWING compared web part of java (Tag libraries, JSF components, Library utilities & MVC frameworks)
But these are few attempts in that direction, basically these frameworks tries to come up with configurable action handling, form validation, custom UI components built over standard JFC components, Custom layout managers to ease out component layering & lot of static utilities for handling validation & threading issues.

http://www.artima.com/lejava/articles/swingframework.html
http://carbonfive.sourceforge.net/springadapter/api/com/carbonfive/flash/spring/package-summary.html#documentation
Spring Rich Client - As usual Spring efforts here also are very singificant in reducing source code lines which is very important in the SWING context
"Spring makes heavy use of the "Inversion of Control" (IoC) design pattern, meaning simply that individual JavaBeans don't go looking for data, the data is handed to them by the framework"

Some important Concepts:

1. Understanding lightweight architecture
Each heavyweight component contains its own z-order layer (the notion of depth of layering) all lightweight components are inside heavyweight components and maintain their own layering scheme defined by Swing.when a heavyweight inside another heavyweight container is placed it will, by definition overlap all lightweights in that container.we have to use mixing of AWT and SWING components cautiously

-A lightweight does not contain the native code (JNI), You don't have call "System.loadLibraty()" & hence inherently cross-platform, there are may off the shelf compoenents providing different Skins (Look and Feel Factory)
-A lightweight component can have transparent pixels; a heavyweight is always opaque.
-A lightweight component can appear to be non-rectangular because of its ability to set transparent areas; a heavyweight can only be rectangular.
-Mouse events on a lightweight component fall through to its parent; mouse events on a heavyweight component do not fall through to its parent.
-When a lightweight component overlaps a heavyweight component, the heavyweight component is always on top, regardless of the relative z-order of the two components.
-JFrame , JDialog, JApplet,JWindow are the top level components & hence extend AWT compoenent instead of JComponent unlike other components

A Swing component does NOT have a corresponding native OS GUI 'peer', and is free to render itself in any way that is possible with the graphics APIs.However, at its core, every Swing component relies on an AWT container, since (Swing's) JComponent extends (AWT's) Container. AWTEvent root event class for all AWT events & there is no JVM from Sun that uses full HW acceleration, and it SHOWS. Java 5 has *partial* HW acceleration - although significantly more than java 1.4 had

2. Understand the layout managers,data binding & validation well

3. Understand Good coding practices w.r.t. Swing.
Follow the open source code (As per the list above)
Written in 2000, but still good to go though http://www.oreillynet.com/pub/a/oreilly/java/news/learningjava_0500.html

There has been quite lot of work on SWING (Now unfortunately it looks like Sun also started loosing interest in pushing Java in Desktop arena, It is now left for Open source hacker to push SWING to next level) Swing classes contributed heavily to the exponential growth of total number of java classes as part of JDK.JFC has got solid framework & design.
Total # of Java Files as of now stands at
JDK1.4 : 3,883
JDK1.5 : 6,558
JDK1.6 : 7,061


As a SWING proponent (With vested interest :-) as of now), I tried to find some answers for the current stated SWING problems

A. SWING is very slow compared to SWT.
IntelliJ-IDEA (Swing) is faster than Eclipse IDEA and Eclipse have matching complexity, and despite Eclipse is backed by IBM and open source. it still does not perform better than IDEA, which is proprietary and developed by small group of smart individuals.
Java IDE's like netbeans, Weblogic Workshop & JBuilder are written in SWING.
So it's all about how well we understand & write the code.

B. SWING solutions have very bad distribution model (With lot of confusing JREs)
I guess Sun is working hard to improve the Webstart & I hope it will be as simple as Flash plug-in (Both in terms of size and ease of use)

3. SWING is complex to work with
I guess with proper usage of scripting (Like F3, Groovy solutions) & XML should make the life simpler

Hope this blog will be useful for new as well as old SWING developers. :-)

Bug Patterns:

While developing web applications there are few common errors that get reported again & again.We don't usually document these.I thought it will be very useful if we can document these after consolidating from the existing bug reports. So here I am trying capture few.

I am sure it will be helpful for new developers to reduce the bug count in their web related projects. I will be updating this list whenever I come across new common mistakes. So keep checking this blog for latest updates :-)

UI Bug Patterns:

1. Handle the date display format @ common place, there is great possibilityto change here.
2. Screen resolution/Browser Compatibility issues (Make sure these are part of NFR) should be tracked well.
   
3. Make sure about UI issues while taking off the shelf tag libraries (For example tag libraries dsiplay tag, struts-menu comes with good CSS support)
4. "Enter" key should work for search screens (Use java script), Struts submit won't work most of the times
5. Session clearing issues- (Use case dependency, back button), Test all the scenarios by pressing the back button & clicking on the links/buttons.
   
6. Horizontal scroll bar appearence (Look for fields that accepts more than 80 chanracters) Look into IFrame, Frame and <div> tags.
7. Wrapping of characters in the table (header & other cells) will certainly help to avoid the horizontal scrool bar but for a continous String (without any space) wrapping will no effect
   
8. Placement Calender window(Any pop-up for that matter) all platforms (Mac Safari, IE behaviour), Don't include calender option below the screens with vertical scrollbar.
9. Don't use high resolution images(for thumbnails etc...),it takes more time to load the screens
10. Don't add all the import statements as part of the common init.jsp.
11. Before using any variable from session check for null if you are taking care of clearing of that session variable (Ideally you should not keep variables in the session,avoid if possible)
12. Instead of hardcoding, use context Root path in JS or JSP files, make sure to use the relative paths. Use http server to load all the static data (if possible). It will reduce the sover-all ize of EAR file to be deployed.
13. If user provides some junk values as HTML parameters (by directly editing url in the browser, just forward to same page by validating the same.For Example: He may enter the some String for Integer ID, then expect NumberFormatException & forward it to the same page.
14. Cache all the Combo-box related data & make sure to update cache data as well if there is seperate edit(add/update/delete) for these data.
15. Make sure to trim the input data while reading from text area/text feild
16. Use "value".equals(value) rather than value.equals("value") to avoid NullpointerException - This is not general rule but failrly applicable in web applications
17. Externalize all the user visbile data into properties file even if internationalization is not required. Eclipse(or any IDE) provides easy way to refarctor for externalizing
18. Handle duplicate submission
    

I am also planning to come similar kind of list for Java track as well. I am sure this would be helpful for developers/managers as checklist which can be part of defect prevention activity.

Choosing Java Web Framework - Evaluation Parameters

Selecting a web framework is one of the difficult decision that Java architect has to make upfront while architecting enterprise web application
First, we need to select between MVC frameworks(strut, struts-2, Spring MVC) and Component oriented frameworks (JSF,Tapestry... they are also MVC based although!). Hybrid solutions also can be better solution for certain areas.General thumb rule should be, if the application is more stateful with less read only pages we should go for JSF (Possibly the best bet is using frameworks like Seam & ICEFaces).We can also look into Spring webflow(I have not tried) if the application is tightly coupled with Spring back end & has to work with pre-Java EE envioronment. These frameworks offers much mature in handling statefulness of application (we don't have mess around HttpSession) and inbuilt future to handle workflows & continuations.Struts(Classic one) should be fine for small CRUD app with read only pages.

It is very difficult to layout the evaluation parameters for selection. I tried to come up following parameters (which I think are going to be more important in the year 2007) after spending some time in going through these frameworks. Depending on weightage (which is project dependent) we can take decision. I also give set of links that should help the evaluator for zeroing on some framework (or frameworks :-))

1. RIA Factor
I guess giving rich experience to web users is not going to fancy feature but a mandatory one in coming days.If this feature becomes #1 driving factor while building the application (Ex:entertainment & media industry) traditional MVC frameworks cannot be even part of such evaluations.
JSF - Because of better ecosystem provided by the IDEs and off the shelf component libraries that easily blend with AJAX.
Adobe Flex - For all Flash lovers. I am yet to see a practical full fledeged scalable big enterprise application although samples & SDK look impressive
Web start SWING - The most undervalued/under utlized option according to me while developing intranet applications
targetting finite #(with known pattern) of users.
Winner : JSF

2. Data Validation and Binding framework
Struts 2 (Webwork) is the best choice here. Although Tapestry (Good but has steep learning curve),JSF and Spring MVC provides fairly good data binding/validation support, but are not as attractive as Struts 2 (with OGNL)
Classical Struts is very poor (because of fundamental design flaw in dealing with web forms & stateless Action classes) while handling this.
Winner : Struts 2

3. Presentaion layer options
Some times it becomes importnat political decision to go with trditional templating engine option (like Velocity & Free marker) when we need to build a very big site with seperate UI and back end team. But I personally don't value this point much, all the frameworks should be able to use all the best of off the shelf custom tags (Like popular Display tag & Struts menu & site mesh ) & template options.
In these situations Struts 2 and Spring MVC shines well. Although HTML native support by Tapestry is the most likable option if need to provide HTML prototype for each & every screen before implementation & we can directly roll-out the screens to production by making the changes to HTML itself.Spring MVC comes with inbuilt design for handling the various presentation layer option from it's inception.
Winner : Spring MVC

4. Navigation mechanisms and Controller infrastructure
Component Frameworks provide event driven approach (JSF & Tapestry) like our regular SWING listener classes that we can attach to UI components. we can even attach sophistgated renderers. But I personlly not very receptive this idea of taking away request/response paradigm and low level APIs (HttpRequest, URLs, etc...) from the developer.
Struts 2 comes with most sophistigated support for the interception infrastructure and works well with our thinking.
Winner : Struts 2

5. People & deadline Issues/Learning curve
Usagewise Struts 2 doesn't seem to have won many supporters (Unfortunately :)).There is pretty steep leanrning curve involved with all non classic -struts option as 90% developers are familiar with struts & continue to use it. (Why to waste time 1 month time in learning for 3-4 months simple CRUD project even if it takes is a valid argument). I think some time down the line we need to work with better tools and techniques that can simplify the programmer's job.In longer run it is better to scale up programmer's ability to learn new things & adopt in a faster time. Hence it is better to use latest tools rather than relying on classical struts. After all we are not going to work with single project throughout our life. We have to consider market behaviour, effort investment & future project oppportunities.
Winner: JSF

In Summary,
Unless the site to be built is not stateful, small & includes mainly read only pages with less complex navigation requirement compoenent framework is over-kill & traditional MVC framework (Struts -2 my favorite) is a better option.
Most of time we end up evaluating frameowork based on their technical capability rather our business applicability. I felt it is important to focus on business applicabilty rather than techincal capability.

1. Total # of lines of code for accomplishing particular activity(use cases)
2. Non functional requirements. (People,longevity,envioronment,existing investments etc...)
should also guide the decision

I came across these links & found useful.
SWING is not better option compared to JSF as per Oracle
Java Web Framework Sweet Spots - By Matt Raible