Posts tagged java code convention

Not because we were instructed to, or for maintainability sake (although it is also), but when it means trouble (big one) not doing so, is the focal point of this discussion today. Failing to adhere to the standard convention could result in drastic and sometimes fatal code refactoring and a whole range of unit testings and fixing aftermaths.

Why is it that the Sun Java code convention dictate us or even to come up with the idea to use our organization’s internet namespace and sometimes together with unique project names?

Consider this case study:

You are in team A working on the “Singapore Bus Timetable Management System”. (A bespoke system that manages bus timetable!)

Gary is in team B working on the “Trans Temesek Singapore Bus Management System”. (Also a Singapore company, besides the point actually.)

Now, both you and Gary wrote a Calendar utility class called MyCalendar.java and both placed it in the package production.utils. Both calendar utility classes does different things, your utility class mingles with Juliet calendar, and Gary’s utility class mingles with a little Juliet calendar and more Gregorian calendar, coincidentally. After code review, the project architect decided to reuse both calendar utility classes for future projects.

Thats where the problem starts.

Now, supposing that team C decides to use both calendar utility class, your MyCalendar.java and Gary’s MyCalendar.java. Both utility classes are packaged under the same namespace production.utils. How would team C be able to use both from within the same class in project C?

This simply does not work!

import production.utils;

public class TeamC{
	public static void main(String args[]){
		// use Gary's calendar
		MyCalendar.getDate();

		// use your calendar
		MyCalendar.getDate();
}

This does not work either because the Java compiler is unable to differential and determine which MyCalendar implementation to link.

public class TeamC{
	public static void main(String args[]){
		// use Gary's calendar
		production.utils.MyCalendar.getDate();

		// use your calendar
		production.utils.MyCalendar.getDate();
}

How to solve this problem?

- Use Sun Java Code Convention for Packaging

Gary’s MyCalendar.java packaged under the sg.java.projectA.utils namespace

package sg.java.projectA.utils;

/**
 * @Author Me
 */
public class MyCalendar{
	public static String getDate(){
		...
	}
}

Gary’s MyCalendar.java packaged under the sg.java.projectB.utils namespace

package sg.java.projectB.utils;

/**
 * @Author Gary
 */
public class MyCalendar{
	public static String getDate(){
		...
	}
}

So team C, when trying to reference both MyCalendar utility class may do so like:

Note that you may not do an import for both classes using the import statement tho, and must reference their fully qualified name in the code.

public class TeamC{
	public static void main(String args[]){
		// using your calendar utility class
		sg.java.projectA.utils.MyCalendar.getDate();

		// using Gary's calendar utility class
		sg.java.projectB.utils.MyCalendar.gerDate();
	}
}

(I have commonly seen Microsoft .NET import statements to be like use namespace bean; use namespace utils; and i assume such convention either do not exist, existed late, or makes no sense to enforce in the .NET paradigm, can someone from .NET share this with us please?)

Check out Sun Java Code Convention