Does ICU-Project.org library works on Android sufficiently?

Question

I'm trying to use ICU-Project.org Library (ICU4J v55.1) in my android app which had a wonderful alternatives to Java Calendar such as Japanese and Islamic Calendars, but the jar file always cause a crash in eclipse or my app

i can't using it in my android app, but it's works 100% fine in a normal Java Project, so i don't know what it is the problem

first time, i copy the jar file to my lib folder then right click > add to build path

when i run the app in Android emulator, this method cause killing to IDE with below message:

Unable to execute dex: Java heap space
Java heap space

although I've increased the heap space as shown below, but nothing solved:

--launcher.XXMaxPermSize
2048M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
2048m
--launcher.defaultAction
openFile
--launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Xms2048m
-Xmx2048m

second time: I've removed the jar file, and adding it from (right click on MyApp > properties > Java Build Path > Libraries tab > add external jars

in Order and Export tab, the jar is unchecked

now when i run Android Emulator, it's works but my app crashes with below error:

08-27 18:46:06.635: I/dalvikvm(295): Could not find method com.ibm.icu.util.Calendar.getInstance, referenced from method com.c.cx.Main.onCreate
08-27 18:46:06.635: W/dalvikvm(295): VFY: unable to resolve static method 13898: Lcom/ibm/icu/util/Calendar;.getInstance ()Lcom/ibm/icu/util/Calendar;
08-27 18:46:06.665: D/dalvikvm(295): VFY: replacing opcode 0x71 at 0x0009
08-27 18:46:06.665: D/dalvikvm(295): VFY: dead code 0x000c-002b in Lcom/c/cx/Main;.onCreate (Landroid/os/Bundle;)V
08-27 18:46:06.805: D/AndroidRuntime(295): Shutting down VM
08-27 18:46:06.805: W/dalvikvm(295): threadid=1: thread exiting with uncaught exception (group=0x4001d800)
08-27 18:46:06.815: E/AndroidRuntime(295): FATAL EXCEPTION: main
08-27 18:46:06.815: E/AndroidRuntime(295): java.lang.NoClassDefFoundError: com.ibm.icu.util.Calendar
08-27 18:46:06.815: E/AndroidRuntime(295):  at com.c.cx.Main.onCreate(Main.java:15)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2627)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2679)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.ActivityThread.access$2300(ActivityThread.java:125)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2033)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.os.Handler.dispatchMessage(Handler.java:99)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.os.Looper.loop(Looper.java:123)
08-27 18:46:06.815: E/AndroidRuntime(295):  at android.app.ActivityThread.main(ActivityThread.java:4627)
08-27 18:46:06.815: E/AndroidRuntime(295):  at java.lang.reflect.Method.invokeNative(Native Method)
08-27 18:46:06.815: E/AndroidRuntime(295):  at java.lang.reflect.Method.invoke(Method.java:521)
08-27 18:46:06.815: E/AndroidRuntime(295):  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
08-27 18:46:06.815: E/AndroidRuntime(295):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
08-27 18:46:06.815: E/AndroidRuntime(295):  at dalvik.system.NativeStart.main(Native Method)

my usage of the lib:

package com.c.cx;

import com.ibm.icu.util.Calendar;
import android.app.Activity;
import android.os.Bundle;
import android.widget.Toast;

public class Main extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        Calendar cal = Calendar.getInstance();      
        Toast.makeText(getApplicationContext(), ""+cal.get(Calendar.YEAR), Toast.LENGTH_SHORT).show();

    }

}

my JDK version: 1.6, I've changed it to 1.7, nothing solved.

please try it before you judge.

Answer 1

Well, ICU is not primarily designed for Android. Especially two items make me worrying:

• The jar size is very big (10.7 MB), also the count of methods.
• The class loader and service loader architecture for loading i18n- and calendar resources don't cooperate well with Dalvik VM (probably directly related to your problem).

I am also not sure if using class loaders for loading resources inside jars is an efficient mechanism at all on the Android platform. Other libraries have observed performance issues related to this topic - for example Joda-Time-Android (especially the section "Why This Library?") or Threeten-ABP. It was reason enough for me to make a clone of my own library named Time4J/A and to rearchitect it as optimized aar-library, too, using asset-files as resources.

About your note that the islamic calendar of ICU is "wonderful". I dare to have a different opinion. Like in Joda-Time, the islamic variant of ICU is only an algorithmic approximation, but cannot replace a sighting-based variant like the umalqura-calendar of Saudi-Arabia.

Correction: Now I see that ICU also claims to support Umalqura starting with version v52 (had only known the older versions). So ICU-support for islamic calendar is indeed better than in most other libraries.

Update from 2015-08-31:

Now the positive part of my answer (whose first part was rather negative - sorry). Today I have released Time4A-v3.6-2015f. It incorporates a Hijri-calendar covering all variants supported by ICU4J. Example:

PlainDate today = SystemClock.inLocalView().today();
System.out.println(today); // 2015-08-31

HijriCalendar hijri = // conversion on local timeline at noon
  today.transform(HijriCalendar.class, HijriCalendar.VARIANT_ICU4J);
System.out.println(hijri); // AH-1436-11-17[islamic-icu4j]

And the reverse conversion to a gregorian date is simple:

System.out.println(hijri.transform(PlainDate.class));

Note, Umalqura would display 1436-11-16. The ICU calendar types are mapped as follows:

HijriCalendar.VARIANT_ICU4J => IslamicCalendar.CalculationType.ISLAMIC

HijriCalendar.VARIANT_UMALQURA => IslamicCalendar.CalculationType.ISLAMIC_UMALQURA

HijriAlgorithm.WEST_ISLAMIC_CIVIL => IslamicCalendar.CalculationType.ISLAMIC_CIVIL

HijriAlgorithm.WEST_ISLAMIC_ASTRO => IslamicCalendar.CalculationType.ISLAMIC_TBLA

The underlying data of the astronomical ICU-Simulation using ISLAMIC were not recalculated in Time4J but just overtaken using a simple transfer code tool (based on ICU4j) like:

IslamicCalendar cal = new IslamicCalendar(TimeZone.GMT, Locale.ROOT);
cal.clear();
cal.setCalculationType(IslamicCalendar.CalculationType.ISLAMIC);

for (int hyear = 1; hyear <= 1600; hyear++) {[
  cal.set(Calendar.YEAR, hyear);
  // here writing the islamic year in a data-file
  for (int hmonth = 1; hmonth <= 12; hmonth++) {
    cal.set(Calendar.MONTH, hmonth - 1); // zero-based-index
    cal.set(Calendar.DAY_OF_MONTH, 1);
    int len = cal.getActualMaximum(Calendar.DAY_OF_MONTH);
    if (hmonth > 1) {
      // write a space into the file
    }
    // write the length of month in days
  }
}

This code ensures that Time4J manages exactly the same data as ICU4J in the year range 1-1600. So you should be able to replace ICU4J by Time4A (AAR-library of about 724kB). I have tested it on Android Studio emulator. You do not really need to be afraid of loosing i18n-capabilities. Time4A supports 45 languages including the names of islamic era and islamic months in Arabic, Farsi etc. (based on CLDR-26). A formatting example is shown in the online-javadoc.