Details
P4 Description
The DatePicker component uses the Locale.Category enum in a number of places.
Unfortunately, this is not available in the Android API's. Locale is available though, which makes it hard to have Locale.Category in the compat.jar where we typically put missing classes (not inner classes).
On JavaFXPorts, I have a workaround for this by replacing all calls to
Locale.getDefault(Locale.Category.FORMAT) into
Locale.getDefault();
See https://bitbucket.org/javafxports/8u60-rt/commits/9dbd2f8dd8f3976996be3a4d1c64f3bd6313d59e for the patch.
This is a workaround, but it can also be "solved" using reflection: if Locale.Category exists, we use it. Otherwise, we fallback to the zero-args Locale.getDefault();
I can create a patch for this, unless it is decided not to have this, as it makes the code dirtier just for the sake of Android -- which I would understand.
Unfortunately, this is not available in the Android API's. Locale is available though, which makes it hard to have Locale.Category in the compat.jar where we typically put missing classes (not inner classes).
On JavaFXPorts, I have a workaround for this by replacing all calls to
Locale.getDefault(Locale.Category.FORMAT) into
Locale.getDefault();
See https://bitbucket.org/javafxports/8u60-rt/commits/9dbd2f8dd8f3976996be3a4d1c64f3bd6313d59e for the patch.
This is a workaround, but it can also be "solved" using reflection: if Locale.Category exists, we use it. Otherwise, we fallback to the zero-args Locale.getDefault();
I can create a patch for this, unless it is decided not to have this, as it makes the code dirtier just for the sake of Android -- which I would understand.