Felipe Gaucho's Blog

The Gods Must Be Crazy - Java Edition

This blog entry is the summary of a long discussion I had with my friend Jason Brazile about Calendar and Date manipulation in Java. Jason is one of those agnostics against Java platform and he is also a high skilled developer and researcher, so our discussions often unveil interesting details about the Java language. This one made me be totally stoned.

How many concrete implementations of the java.util.Calendar are released in your JDK?

1. ONE: the Gregorian Calendar
2. TWO: the Gregorian Calendar and a new one from Japan
3. THREE: because there is secret Calendars somewhere
4. None of the above

Well, I have to admit I am quite surprise with the answer but, like a Java Puzzler, the most correct answer is: None of the above. If you ask this for a specific version of the JDK, perhaps I can guess how many calendars you have available - but the generic answer considers it is dependent of the JDK version, and probably also dependant on particular revisions of JDK nightly builds.

Skeptic? Just copy/paste and run the code below:

	public static void main(String[] args) {
		// JDK 1.5: This is the hidden Buddhist bug
		Calendar budish = Calendar.getInstance(new Locale("th", "TH"));
		System.out.println(budish.getClass());

		// JDK 1.6: This is the undocumented Imperial mistake
		Calendar japanese = Calendar.getInstance(new Locale("ja", "JP", "JP"));
		System.out.println(japanese.getClass());

		// Any JDK: nobody really knows about the type - suposedely Gregorian
		Calendar suposeGregorian = Calendar.getInstance();
		System.out.println(suposeGregorian.getClass());
	}

	class sun.util.BuddhistCalendar
	class java.util.JapaneseImperialCalendar
	class java.util.GregorianCalendar

In respect of my lovely technology I will avoid to transcript here my first thoughts about that, but I propose to the reader the following questions:

• What kind of Calendar is instantiated when you call Calendar.getInstance()?
  • Answer: I suppose it is GregorianCalendar, but if you are trying it in Thailand, who knows?
• PersonalJava API and debug packages are supposed to be available in the production versions of JDK?
  • Answer: to allow an API to run an unpredicted behaviour based on an undocumented library seems weird. The Japanese Imperial Calendar seems less complicated because its package follows the recommended naming convention and it is just not documented. But the Buddhist Calendar should be the preferred Calendar of Mr. Val Valentino
• If your system uses the Calendar.getInstance() method, is it safe? Even if some day it runs in a place containing a dangerous Locale? How easy is to find a bug if a developer is testing in a safe Locale and the production environment is in a dangerous one?
  • Answer: I have now answer for that ;) please help to enlight my mind on this topic.

Bookmark blog post: del.icio.us Digg DZone Furl Reddit


Comments

Comments are listed in date ascending order (oldest first) | Post Comment



• Calendar source has all the answers to your questions.

  Posted by: kirillcool on July 23, 2007 at 12:32 PM

• I know, then I suppose we can start to ignore the javadoc since it is not trustable anymore?

  Posted by: felipegaucho on July 23, 2007 at 12:36 PM

• I look at Javadocs of Calendar.getCalendar and it states:
  Gets a calendar using the default time zone and locale. The Calendar returned is based on the current time in the default time zone with the default locale.
  So, in Thai environment (which can be easily simulated by either Locale.setDefault() or user.language / user.region / user.country / user.variant VM flags), it will return the BuddhistCalendar. But if you're programming to the interface (which in this case is the abstract Calendar class), why would that matter?

  Posted by: kirillcool on July 23, 2007 at 12:45 PM

• The tricky part here is: there is no documentation of such class BuddhistCalendar :) How can I figure out about that ? and how about the other calendars people are creating right now and probably available in JDK 6 patch x? Who knows ? Even experienced developers are not supposed to check the source code of JDK to decipher its enigmas.. A simple set of Constants could make it much easier - IMHO.

  Posted by: felipegaucho on July 23, 2007 at 12:49 PM

• I still don't understand why do you need documentation on the internal classes. You call Calendar.getInstance(), and you get the calendar that best matches the current environment. It implements all the methods from Calendar base class. So, if your code is behaving nicely and not making any assumptions on the specific calendar implementation (casting to GregorianCalendar to call some specific public method, such as isLeapYear), why would you care about that? New locales are being added all the time, new timezones are being added all the time, so you could be complaining about those (test-wise) as well...

  Posted by: kirillcool on July 23, 2007 at 12:53 PM

• I fail to see the confusion here. The javadoc states http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html#getInstance()
  "Gets a calendar using the default time zone and locale." So, if you are working with Calendar and locale does not matter, you would use the default instance, where as if you believe your code will be run in unknown locales, you would like to specify particular locale or even better use: Calendar calendar = new GregorianCalendar();
  That said, since I have not worked with code that can be potentially run anywhere internationally, this post is a good heads up!

  Posted by: khattak on July 23, 2007 at 12:58 PM

• For me on Mac (1.5.0_07):

  There are 2 Calendars from 132 Locales
  class sun.util.BuddhistCalendar
  class java.util.GregorianCalendar

  The Buddhist one extends Gregorian.
  For me, the whole Calendar thing is dumb in Java. Why should fixed concepts such as weeks and months be in defined in Calendar?

  Posted by: goron on July 23, 2007 at 01:13 PM

• JSR 310 - Date and Time API might be worth a look at (inspired by Joda Time) as you've got a nice programmer-friendly and calendar-friendly API, with lots of calendar implementations.
  - Chris

  Posted by: chris_e_brown on July 24, 2007 at 12:55 AM

• "How can I figure out about that ? and how about the other calendars people are creating right now and probably available in JDK 6 patch x?" And that's precisely why you should program to the interface and use the factory method, so you don't have to care.
  Basic OO concept, ever heard of the factory pattern?.
  

  Posted by: jwenting on July 24, 2007 at 06:05 AM

• I would love to have any interface related to the calendar to use instead of rely my code in a crazy hacked abstract class :).As goron commented, why a generic calendar should be locked into concepts like Day and months ? I have methods like getActualMaximum(int field) but depending on the calendar being used, it can return an unexpected number.. If I can at least know what kind of calendar exist, I can try to avoid problems.. but since it is random, the best solution seems to be to lock my code in a specific Locale.. and do a big IF for each locale I am planning to deploy.. :(

  Posted by: felipegaucho on July 24, 2007 at 06:13 AM

• @goron: an acceptable compromise perhaps? Don't all calendar systems have lunar and solar cycles? And can't those cycles be subdivided? What would you propose instead?

  Posted by: ljnelson on July 24, 2007 at 12:18 PM

• well, collecting different opinions I have some draft ideas: First of all, the Calendar code compared to ResourceBundle:
  The ResourceBundle code is based in Locales. I created different properties files and I use the sufix strategy to load a localized set of terms. Despite the locale, one can figure out exactly what kind of resource bundle will be loaded just checking the information about country and language being used.
  The Calendar code is based in undocumented hard-coded IFs, so nobody can predict what Calendar will be loaded through the getInstance() method. Different from ResouceBundle, the behaviour of different Calendars are not only aesthetical, but completely different. A code designed to work in one type of Calendar can become a total disaster using a different calendar. Even if the code is running in Thailand or Japan, the type of the calendar also depends on the version of the JDK being used, so I guess the less unsafe way to load a Calendar for now is to call the constructor of the concrete class, like new GregorianCalendar()

  Alternatives: we can design several alternatives, but Java is supposed to be bacward compatible (aspect ignored in the calendar implementation), I am trying to imagine a good work around: Some of them:

  
  Deprecate the getInstance() method, forcing the developer to define a fixed Locale, or a fixed type of Calendar. Quite radical suggestion, but at least push us to the safe side.

  Adopt a similar strategy from ResourceBundle, creating an interface and forcing the calendar implementations to follow some kind of naming convention, like: CustomCalendar_pt_BR or LunarCalendar_tg. In this case, some strategy should be designed in order to help the developers to control the type of calendar being used in the application. GregorianCalendar could continue to be the default calendar.

  I have talking with two group of developer in this case: the ones that believe that Java Calendar is sound and it don't need any refactor, and the ones that hates any Java Date/Time API and never use Calendar (they adopt Joda or other API). The former seems to be too optimistic and the latter seems too pessimistic. I don't have a definitive suggestion to solve the calendar loading problems. But I appreciated the discussion and I would like to say thanks for all that contributed to enlight my view about this specific Java topic.
  

  Posted by: felipegaucho on July 24, 2007 at 11:54 PM

• The subject of a very wonderful and distinct
  I thank you for continuing excellence
  Thank you

  =========================================================================

  ليبيا
  شباب ليبيا
  libya
  منتديات
  منتديات ليبية
  غرائب وحقائق
  أحاديث شريفة
  برامج اسلامية للجوال
  مفاتيح الديجيتل
  الشيرنج
  الرسيفرات
  كتب إسلامية
  خلفيات للموبيل
  الشعر الشعبي
  الصحة والطب
  طب اسنان
  كتب طب اسنان مجانية
  برامج طبية
  تعلم الإنكليزية
  اللغة الفرنسية
  طب الإعشاب
  الخواطرالادبية
  الازياء والمكياج
  تعليم الطبخ
  الاثاث الحديث
  مقاطع كرة قدم
  المصارعه الحرة
  اهداف كوره
  الفوتوشوب
  اروع البرامج
  الدوري الليبي
  خلفيات رياضية
  المصارعة
  كورة عربية
  كرة قدم عالمية
  الدوري الإيطالي
  الدوري الاسباني
  الدوري الإنجليزي
  صور المشاهير
  انواع الحلويات
  افلام كوميدية
  احدث الافلام
  افلام
  التقنية
  تحميل افلام
  برامج
  اخر برامج الجوال
  kaspersky
  أفلام كرتون عربية
  برامج برامج كمبيوتر
  برامج حماية
  برامج اختراق
  برامج صوت
  برامج تحميل برامج احدث البرامج
  محادثة
  خلفيات الطبيعة
  برامج مبايل للتحميل
  اخبار الفن
  احدث الافلام للتحميل
  تحميل افلام رعب
  ترجمةأفلام
  الكامات
  برامج جوال
  برامج محاسبة
  برامج
  kasper
  games
  برامج
  برامج
  انترنت
  برامج صوتية
  شبكات الحاسوب
  خلفيات للويندوز
  تطويرالمواقع
  العاب
  العاب الفيديو
  games
  شفرات
  برامج مسنجر
  خلفيات شاشة
  صور ترحيبيه
  الفوتوشوب
  خلفيات طبيعة
  تطويرالمواقع
  الفوتوشوب
  مقاطع البلوتوت
  مسجات ليبية
  خلفيات
  الفلاش
  التصميم الثلاثي
  برامج الجوال
  العاب الجوال
  فيديو كليب
  مسجات
  ترددات ستالايت
  نغمات
  

  Posted by: libyan on May 30, 2008 at 02:22 PM




Only logged in users may post comments. Login Here.


This work is licensed under a Creative Commons License.



Powered by
Movable Type 3.01D