Using Aspose.Email for Java 5.6.0 under Oracle Java 8

Aspose.Email Product Family
1

We have been using Aspose.Email 5.6.0 under IBM Java 7 in Windows without any problem. However, when we perform same operation in Oracle Java 8 in Redhat Linux, we encountered the following error:

class com.aspose.email.system.exceptions.InvalidOperationException: Operation is not valid due to the current state of the object.
com.aspose.email.system.collections.SortedList.a(Unknown Source)
com.aspose.email.system.collections.SortedList.addItem(Unknown Source)
com.aspose.email.yd.a(SourceFile:52)
com.aspose.email.mc.c(SourceFile:455)
com.aspose.email.mc.a(SourceFile:109)
com.aspose.email.mc.(SourceFile:70)
com.aspose.email.MapiMessageReader.(SourceFile:65)
com.aspose.email.MailMessage.b(SourceFile:1229)
com.aspose.email.MailMessage.a(SourceFile:1353)
com.aspose.email.MailMessage.load(SourceFile:1359)

Should we use the newest version of Aspose.Email for Java 8?

2

@tywchan,

You are using a pretty older version of API. Can you please try using latest Aspose.Email for Java 20.6 as its for sure supported with latest JDKs. If you still face issue then you can share the source files and used sample code reproducing the issue on your end.

3

Hi, it is ok to get rid of this error when using Aspose.Email 20.5.
In addition, we have used isLicense method before but it was deprecated already and need to use setLicense as suggested by this link. However, we encountered the below error when using setLicense method

class com.aspose.email.system.exceptions.InvalidOperationException: Failed to set license. Details: Culture Name: en-HK is not a supported culture

It only works if we saved the default locale (en-HK) first and set the locale to en-US before calling setLicense and restore to default upon completion such as below:

java.util.Locale backup = java.util.Locale.getDefault();
java.util.Locale locale = new java.util.Locale(“en”, “US”);
java.util.Locale.setDefault(locale);
:
license.setLicense(…)
:
java.util.Locale.setDefault(backup);

However, Locale.setDefault is not thread-safe and there would be problem if we run the above code under multi-thread environment. en-HK is our default locale and cannot be changed. Any suggestion if we need to use setLicense but keeping en-HK as default locale?

4

@tywchan,

We have implemented new helper class CurrentThreadSettings. It is an auxiliary class that allows to define default Locale for current thread.

Methods :
Returns default Locale for current thread.

public static Locale getLocale()

Sets default Locale for current thread.

public static void setLocale(Locale locale)
public static void setLocale(String localeName)

We can use CurrentThreadSettings.setLocale in case of unrecognized default locale
and set most appropriate locale for Aspose Email lib

Code sample:

Locale defaultLocale = Locale.getDefault();
try {
    // set incorrect default Locale
    Locale.setDefault(new Locale("en", "RU"));
    // set Current Thread Locale for Aspose Email lib
    CurrentThreadSettings.setLocale("en-US");
    // or
    //CurrentThreadSettings.setLocale(new Locale("en", "US"));

    PersonalStorage.create("test.pst", FileFormatVersion.Unicode);
} finally {
    Locale.setDefault(defaultLocale);
}

Set license

// set default Java locale to en-HK
java.util.Locale.setDefault(new java.util.Locale("en", "HK"));
// Aspose.Email API helper
// set locale for Aspose.Email lib in current thread
CurrentThreadSettings.setLocale(new java.util.Locale("zh", "HK"));

// print Java defaul locale en-HK
System.out.println(java.util.Locale.getDefault());

License license = new License();
license.setLicense(getDefaultLicense());
5

Hi mudassir,

Thanks for your information and your suggestion works. However, I have a question about CurrentThreadSettings. We observed that for a particular thread, say thread x, running with below code:

Locale.getLocale(); // Our default locale is en-HK
CurrentThreadSettings.getLocale(); // this line will throw exception about en-HK is not a supported culture
CurrentThreadSettings.setLocale(“en-US”);

If we comment 2nd line after first execution and using the same thread to execute (I won’t give too much details here, we can have a way to modify the code and use the same thread to execute), we can successfully run CurrentThreadSettings.setLocale(“en-US”). Then we uncomment the 2nd line and run using the same thread again, it can execute CurrentThreadSettings.getLocale().

My question is for CurrentThreadSettings.setLocale, this special implementation somehow uses ThreadLocal to store locale information per thread level?

6

@tywchan,

Yes method CurrentThreadSettings.setLocale set locale information per thread level.