Archive for September, 2006

Date and Calendar

Sunday, September 17th, 2006

I also saw a recent post on the Java Development Network concerning U.S. Daylight Saving Time Changes in 2007.

Many Java developers will probably have had some problems using the Date and Calendar objects in any Java Developent Kit.

As a developer we are torn by the two objects as Date is what we want to use, but it’s Calendar that is entirely correct. Also: Calendar is quite big to serialize. If you want speed you would probably use Date or even the UTC value.
I personally (and my collegues as well) often mix dates and calendars. For calculations we use the calendars and dates we use for serialising and the front end. But still we fell into some traps.

The getTime method on the Calendar quite dangerous. The javadoc clearly specifies:

Returns a Date object representing this Calendar’s time value (millisecond offset from the Epoch”).

Still we use it, and what does it mean? Here is an example:

Calendar calendar1 = Calendar.getInstance(TimeZone.getTimeZone("CEST"));
Calendar calendar2 = Calendar.getInstance(TimeZone.getTimeZone("PST"));
Calendar calendar3 = Calendar.getInstance(TimeZone.getTimeZone("Asia/Kamchatka"));

System.out.println(calendar1.toString());
System.out.println(calendar1.getTime());
System.out.println(calendar2.toString());
System.out.println(calendar2.getTime());
System.out.println(calendar3.toString());
System.out.println(calendar3.getTime());

And here is the output of the code (my appalogies for the bad formatting):

java.util.GregorianCalendar[time=1158477463667,areFieldsSet=true,areAllFieldsSet
=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useD
aylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ER
A=1,YEAR=2006,MONTH=8,WEEK_OF_YEAR=38,WEEK_OF_MONTH=4,DAY_OF_MONTH=17,
DAY_OF_YEAR=260,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=3,AM_PM=0,HOUR=7,HO
UR_OF_DAY=7,MINUTE=17,SECOND=43,MILLISECOND=667,ZONE_OFFSET=0,DST_OFFSET
=0]
Sun Sep 17 09:17:43 CEST 2006
java.util.GregorianCalendar[time=1158477463667,areFieldsSet=true,areAllFieldsSet=true,
lenient=true,zone=sun.util.calendar.ZoneInfo[id="PST",offset=-28800000,dstSavings=360
0000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=PST,offset=
-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=
2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,end
Month=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOf
Week=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2006,MONTH=8,WEEK_OF_YEAR=38,W
EEK_OF_MONTH=4,DAY_OF_MONTH=17,DAY_OF_YEAR=260,DAY_OF_WEEK=1,DAY_OF_W
EEK_IN_MONTH=3,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=17,SECOND=43,MILLIS
ECOND=667,ZONE_OFFSET=-28800000,DST_OFFSET=3600000]
Sun Sep 17 09:17:43 CEST 2006
java.util.GregorianCalendar[time=1158477463696,areFieldsSet=true,areAllFieldsSet=true
,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Kamchatka",offset=43200000,dst
Savings=3600000,useDaylight=true,transitions=118,lastRule=java.util.SimpleTimeZone[i
d=Asia/Kamchatka,offset=43200000,dstSavings=3600000,useDaylight=true,startYear=0
,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=7200000,startTi
meMode=1,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,
endTimeMode=1]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2006,MO
NTH=8,WEEK_OF_YEAR=38,WEEK_OF_MONTH=4,DAY_OF_MONTH=17,DAY_OF_YEAR=26
0,DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=3,AM_PM=1,HOUR=8,HOUR_OF_DAY=20
,MINUTE=17,SECOND=43,MILLISECOND=696,ZONE_OFFSET=43200000,DST_OFFSET=3
600000]
Sun Sep 17 09:17:43 CEST 2006

As you see: the Date object is created with the UTC code and does not know anything about timezones, the dates are set the the local timezone (CEST in my case).

If you what to be on the save side: allways use Calendar. Or consider using Joda-Time.

Great statement on copyright

Tuesday, September 5th, 2006

In an article on some Canadaian group seeking to license the internet i read this great comment:

Copyright is a crime against humanity
Copyright laws are nothing more than a tool of the ruling class to keep freedom and autonomy away from the people. The stifling blockade of draconian laws behind which which the free transmission of ideas is presently locked down is one of the more noxious devices by which the capitalist system perverts human society.

It is only the alienatied status of the modern worker that perpetuates the oppressive regime of copyright. The oppression of the ruling class that keeps workers in a constant state of anxiety, always burdened by financial worries, like Dickensian children chained to their machines, is what prevents creative workers from sharing their ideas freely, for the benefit of all.

For society to be free from the constricting bonds of copyright, it will be necessary to strike at the heart of the capitalist system itself. Only when the lies and distortions of the ruling class are confronted and rejected, only when workers are in control of the means of production, their efforts at last engaged, harmonious, and justly compensated, only then will we see a world where all people are free to share, copy, and most of all create those products of the marvellous human imagination that promote, in that golden phrase, “promote the progress of science and useful arts.”

Too bad the author was an Anonymous Coward I would have like to credit the guy.

Using the Service Provider approach

Monday, September 4th, 2006

A few days back I tried (and succeeded) in using the Service Provider approach. You can almost state that this is a very ‘old’ concept because it was introduced in JDK 1.3. Strangely enough I did not find many utilities that support this feature (except for an old commons project called discovery). It seems that the next JDK will have some utility classes for this.

What is so cool about using the service provider interface (SPI)?
You could create an interface, put it into a separate jar file and have the implementation be loaded and determined by what is on the classpath. Meaning this: never will you create an implementation object to work with. Even Spring requires you to full qualified name of the implementation in the XML file to wire it into your application.

So how do you create such a thing?
It’s simple.

Create the interface.
For instance:

package com.wordpress.technocratic.interface;
public interface TestInterface {
void welcome();
}

Create a factory class that will look for the implementation on your classpath (system classpath should be sufficient).
For instance something like this:

...
final String name = "META-INF/services/" + anInterface.getCanonicalName();
Enumeration serviceEnumeration = ClassLoader.getSystemResources(name);
...

After this read all the text files and parse the class names from them an create the objects as they are the implementation(s).

Create an implementation with the SPI standard.
For instance:

package com.wordpress.technocratic.impl;
public class Hello implements TestInterface {
public void welcome() {
System.out.println("Hello!");
}
}

Create an text file that contains the name of the class that implements the interface:
For instance:

com.wordpress.technocratic.impl.Hello

The name of the file must be com.wordpress.technocratic.interface.TestInterface.
And the file must be placed in the JAR file within the following directory: META-INF/services.

Note: the text file containing the classname of the implementation *MAY* contain comments (#) and these should be ignored during reading these files.