We Keep Coding

How to get name from Java enum in Kotlin

I have a project that is written with both Java and Kotlin languages and recently I faced next issue.
Let's say we have MyMonth enum:
public enum MyMonth {
JAN("January"),
FEB("February");
private final String name;
MyMonth(final String name) {
this.name = name;
}
public String getName() {
return name;
}
}
Then in Kotlin when we print the name of the month:
fun main() {
val month = MyMonth.JAN
println(month.name)
}
we get:
JAN
which is what is described in the documentation https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-enum/name.html, however actually the name should be January.
Is there a way to get a name in Kotlin that is specified in Java enum?
UPD: My Kotlin version is 1.3.30-release-170
UPD2: IDEA even shows me that name is coming from the getName() method defined in Java:
UPD3: When we explicitly use .getName() it works, however it looks kind of weird

You can call the getter directly instead of using the property syntax:
fun main() {
val name = MyMonth.JAN.getName()
println(name)
}

Your Java API has name as a private field. Nothing can access it, not in Java nor Kotlin.
If you want to access it, add e.g. the following to the Java API:
public String getMonthName() { return name; }
...and then access it from Kotlin as
val month = MyMonth.JAN.monthName

enum is now low usage. You can use IntDef instead of enums.
#IntDef(MyMonth.JAN, MyMonth.FEB)
#Retention(AnnotationRetention.SOURCE)
annotation class MyMonth {
companion object {
const val JAN = 0
const val FEB = 1
fun getDisplayString(toDoFilterTypes: Int): String {
return when (toDoFilterTypes) {
JAN -> "All"
FEB -> "Job"
else -> "N/A"
}
}
}
}

Missing functionality between Accept-Language header and ResourceBundle

Google foo failed me. I want to find out if there is a standard "by the book" way of transforming the input locales from Accept-Language header to correct ResourceBundle.
ResourceBundle::getBundle() method(s) accepts a single locale but Accept-Language can have multiple locales weighted by index, eg: de;q=1.0, sl;q=0.9.
Current code:
#Context
private HttpServletRequest request;
public String getString(String key) {
ResourceBundle i18n = ResourceBundle.getBundle("locale/strings", this.request.getLocale());
return i18n.getString(key);
}
The problem is that getLocale() returns the preferred locale, in this case de. If available resource bundles are sl and en, this will try to find de and then fallback to en, but the actual expected result by the client is sl!
My question is basically, do I have to implement a custom fallback code that iterates over HttpServletRequest.getLocales() (I don't want to reinvent the wheel..) or is there a more standard and straightforward way of doing this? I'd also settle for some 3rd party lib that fills this gap.
Custom solution so far:
#RequestScoped
public class Localization {
#Context
private HttpServletRequest request;
private ResourceBundle i18n;
#PostConstruct
void postConstruct() {
//List of locales from Accept-Language header
List<Locale> locales = Collections.list(request.getLocales());
if (locales.isEmpty()) {
//Fall back to default locale
locales.add(request.getLocale());
}
for (Locale locale : locales) {
try {
i18n = ResourceBundle.getBundle("bundles/translations", locale);
if (!languageEquals(i18n.getLocale(), locale)) {
//Default fallback detected
//The resource bundle that was returned has different language than the one requested, continue
//Only language tag is checked, no support for detecting different regions in this sample
continue;
}
break;
}
catch (MissingResourceException ignore) {
}
}
}
private boolean languageEquals(Locale first, Locale second) {
return getISO2Language(first).equalsIgnoreCase(getISO2Language(second));
}
private String languageGetISO2(Locale locale) {
String[] localeStrings = (locale.getLanguage().split("[-_]+"));
return localeStrings[0];
}
public ResourceBundle i18n() {
return this.i18n;
}
}

I would write an Interceptor, there you can set the language you want and apply the logic you want into a ThreadLocal or pass it down.
i.e you check against the available languages and define an order or set a default.
If you use Spring, you could then set LocaleContextHolder manualy or use the LocaleContextResolver instead of writing a own interceptor.

How can I save UTF-8 strings in an ObjectDB JPA database?

I'm trying to save some UTF-8 strings in the ObjectDB database with the following code:
ResourceBundle entries = Utf8ClassLoader.getBundle("localization/language", "fa-IR"); // fa-IR is a UTF-8 and RTL language
Enumeration<String> keys = entries.getKeys();
for (String key = keys.nextElement(); keys.hasMoreElements(); key = keys.nextElement()) {
ResourceEntity entity = new ResourceEntity();
entity.setId(new ResourceEntity.PKC(key, locale));
entity.setValue(entries.getObject(key));
resourceDAO.persistOrUpdate(entity);
}
The model:
#Entity
public class ResourceEntity {
#EmbeddedId
private PKC id;
private Object value;
// Getters and setters omitted
#Embeddable
public static class PKC {
String key;
String locale;
public PKC() {}
public PKC(String key, String locale) {
this.key = key;
this.locale = locale;
}
// Getters and setters omitted
}
}
localization/language_fa_IR.properties exists and opens properly.
The DAO's persistOrUpdate method is nothing more than an EntityManager.persist function within a transaction. (and does EntityManager.merge If the key exists)
But when I open the ObjectDBViewer, I see this:
How can I save the strings without changing characters?

ObjectDB as an object database just retrieves the objects with their content, including string fields, as you store them. So usually the encoding is not relevant for using ObjectDB, as it just preserves the state of your strings in memory.
It may, however, affect your ability to view special characters in the Explorer. For this you may also try setting an encoding in the Explorer using Tools > Options > General > Encoding.

There was no problem with the ObjectDB actually, the ResourceBundle was returning a not-UTF string. I solved it with this line:
entity.setValue(new String(entries.getString(key).getBytes("ISO-8859-1"), "UTF-8"));

Spring MVC: how to display formatted date values in JSP EL

Here's a simple value bean annotated with Spring's new (as of 3.0) convenience #DateTimeFormat annotation (which as I understand replaces the pre-3.0 need for custom PropertyEditors as per this SO question):
import java.time.LocalDate;
import org.springframework.format.annotation.DateTimeFormat;
public class Widget {
private String name;
#DateTimeFormat(pattern = "MM/dd/yyyy")
private LocalDate created;
// getters/setters excluded
}
When biding the values from a form submission to this widget, the date format works flawlessly. That is, only date strings in the MM/dd/yyyy format will convert successfully to actual LocalDate objects. Great, we're halfway there.
However, I would also like to be able to also display the created LocalDate property in a JSP view in the same MM/dd/yyyy format using JSP EL like so (assuming my spring controller added a widget attribute to the model):
${widget.created}
Unfortunately, this will only display the default toString format of LocalDate (in yyyy-MM-dd format). I understand that if I use spring's form tags the date displays as desired:
<form:form commandName="widget">
Widget created: <form:input path="created"/>
</form:form>
But I'd like to simply display the formatted date string without using the spring form tags. Or even JSTL's fmt:formatDate tag.
Coming from Struts2, the HttpServletRequest was wrapped in a StrutsRequestWrapper which enabled EL expressions like this to actually interrogate the OGNL value stack. So I'm wondering if spring provide something similar to this for allowing converters to execute?
EDIT
I also realize that when using spring's eval tag the date will display according the pattern defined in the #DateTimeFormat annotation:
<%# taglib prefix="spring" uri="http://www.springframework.org/tags" %>
<spring:eval expression="widget.created"/>
Interestingly, when using a custom PropertyEditor to format the date, this tag does NOT invoke that PropertyEditor's getAsText method and therefore defaults to the DateFormat.SHORT as described in the docs. In any event, I'd still like to know if there is a way to achieve the date formatting without having to use a tag--only using standard JSP EL.

You may use the tag to provide you these kind of formattings, such as money, data, time, and many others.
You may add on you JSP the reference:
<%# taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
And use the formatting as:
<fmt:formatDate pattern="yyyy-MM-dd" value="${now}" />
Follows below a reference:
http://www.tutorialspoint.com/jsp/jstl_format_formatdate_tag.htm

To precise Eduardo answer:
<%# taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
<fmt:formatDate pattern="MM/dd/yyyy" value="${widget.created}" />

I also prefer to not do any formatting via tags. I realise this may not be the solution you are looking for and are looking for a way to do this via spring annotations. Nevertheless, In the past I've used the following work around:
Create a new getter with the following signature:
public String getCreatedDateDisplay
(You can alter the name of the getter if you prefer.)
Within the getter, format the created date attribute as desired using a formatter such as SimpleDateFormat.
Then you can call the following from your JSP
${widget.createDateDisplay}

I was dispirited to learn that spring developers have decided not to integrate Unified EL (the expression language used in JSP 2.1+) with Spring EL stating:
neither JSP nor JSF have a strong position in terms of our development focus anymore.
But taking inspiration from the JIRA ticket cited, I created a custom ELResolver which, if the resolved value is a java.time.LocalDate or java.time.LocalDateTime, will attempt to pull the #DateTimeFormat pattern value in order to format the returned String value.
Here's the ELResolver (along with the ServletContextListener used to bootstrap it):
public class DateTimeFormatAwareElResolver extends ELResolver implements ServletContextListener {
private final ThreadLocal<Boolean> isGetValueInProgress = new ThreadLocal<>();
#Override
public void contextInitialized(ServletContextEvent event) {
JspFactory.getDefaultFactory().getJspApplicationContext(event.getServletContext()).addELResolver(this);
}
#Override
public void contextDestroyed(ServletContextEvent sce) {}
#Override
public Object getValue(ELContext context, Object base, Object property) {
try {
if (Boolean.TRUE.equals(isGetValueInProgress.get())) {
return null;
}
isGetValueInProgress.set(Boolean.TRUE);
Object value = context.getELResolver().getValue(context, base, property);
if (value != null && isFormattableDate(value)) {
String pattern = getDateTimeFormatPatternOrNull(base, property.toString());
if (pattern != null) {
return format(value, DateTimeFormatter.ofPattern(pattern));
}
}
return value;
}
finally {
isGetValueInProgress.remove();
}
}
private boolean isFormattableDate(Object value) {
return value instanceof LocalDate || value instanceof LocalDateTime;
}
private String format(Object localDateOrLocalDateTime, DateTimeFormatter formatter) {
if (localDateOrLocalDateTime instanceof LocalDate) {
return ((LocalDate)localDateOrLocalDateTime).format(formatter);
}
return ((LocalDateTime)localDateOrLocalDateTime).format(formatter);
}
private String getDateTimeFormatPatternOrNull(Object base, String property) {
DateTimeFormat dateTimeFormat = getDateTimeFormatAnnotation(base, property);
if (dateTimeFormat != null) {
return dateTimeFormat.pattern();
}
return null;
}
private DateTimeFormat getDateTimeFormatAnnotation(Object base, String property) {
DateTimeFormat dtf = getDateTimeFormatFieldAnnotation(base, property);
return dtf != null ? dtf : getDateTimeFormatMethodAnnotation(base, property);
}
private DateTimeFormat getDateTimeFormatFieldAnnotation(Object base, String property) {
try {
if (base != null && property != null) {
Field field = base.getClass().getDeclaredField(property);
return field.getAnnotation(DateTimeFormat.class);
}
}
catch (NoSuchFieldException | SecurityException ignore) {
}
return null;
}
private DateTimeFormat getDateTimeFormatMethodAnnotation(Object base, String property) {
try {
if (base != null && property != null) {
Method method = base.getClass().getMethod("get" + StringUtils.capitalize(property));
return method.getAnnotation(DateTimeFormat.class);
}
}
catch (NoSuchMethodException ignore) {
}
return null;
}
#Override
public Class<?> getType(ELContext context, Object base, Object property) {
return null;
}
#Override
public void setValue(ELContext context, Object base, Object property, Object value) {
}
#Override
public boolean isReadOnly(ELContext context, Object base, Object property) {
return true;
}
#Override
public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context, Object base) {
return null;
}
#Override
public Class<?> getCommonPropertyType(ELContext context, Object base) {
return null;
}
}
Register the ELResolver in web.xml:
<listener>
<listener-class>com.company.el.DateTimeFormatAwareElResolver</listener-class>
</listener>
And now when I have ${widget.created} in my jsp, the value displayed will be formatted according to the #DateTimeFormat annotation!
Additionally, if the LocalDate or LocalDateTime object is needed by the jsp (and not just the formatted String representation), you can still access the object itself using direct method invocation like: ${widget.getCreated()}

Something basic about Java pointers and changing locale in JSF application

I just tried to implement JSF Internationalization based on this article - "Internationalization in JSF with UTF-8 encoded properties files" and found something weird. Is it right way to change locale by using code in this bean?
#ManagedBean
#SessionScoped
public class LocaleBean {
private Locale locale = FacesContext.getCurrentInstance().getViewRoot().getLocale();
public Locale getLocale() {
return locale;
}
public String getLanguage() {
return locale.getLanguage();
}
public void setLanguage(String language) {
this.locale = new Locale(language);
}
}
As I understand Java private Locale locale must be pointer to actual Locale object from viewRoot object but this method didn't work at me. Instead, when I changed setLanguage(String language) method to this
public void setLanguage(String language) {
FacesContext.getCurrentInstance().getViewRoot().setLocale(new Locale(language));
}
it began to work. Now I wonder where is mistake? What's wrong with #BulusC code? Maybe I did something wrong, maybe I forget something?
When I debugged I seen that private Locale locale and locale object from viewRoot are different objects.

Indeed, the code was missing the line you've posted. From this question: Localization in JSF, how to remember selected locale per session instead of per request/view, answered by BalusC, you can check the code for setLanguage (code taken from BalusC's answer, not mine):
public void setLanguage(String language) {
locale = new Locale(language);
//this is the line you added
FacesContext.getCurrentInstance().getViewRoot().setLocale(locale);
}