Support for java.time

[hohwille]

TeaVM does not seem to support java.time (JSR310). I get such errors:

[ERROR] Class java.time.Instant was not found
[ERROR] Class java.time.LocalDate was not found
[ERROR] Class java.time.LocalDateTime was not found
[ERROR] Class java.time.LocalTime was not found
[ERROR] Class java.time.OffsetDateTime was not found
[ERROR] Class java.time.OffsetTime was not found
[ERROR] Class java.time.ZonedDateTime was not found
[ERROR] Class java.time.LocalDateTime was not found
[ERROR] Class java.time.OffsetDateTime was not found
[ERROR] Class java.time.LocalDate was not found
[ERROR] Class java.time.OffsetTime was not found
[ERROR] Class java.time.LocalTime was not found
[ERROR] Class java.time.Instant was not found
[ERROR] Class java.time.ZonedDateTime was not found

[hohwille]

That would also be some area where I might assist. Looking at TDate this does not look like an easy task and java.time is huge and complex.

[hohwille]

I started working on this. Here are some general thoughts:

• support for non ISO chonology is IMHO overkill for a browser hence Japanese, Hijrah, Minguo, and ThaiBuddhist will not be supported (ever).
• java.time has advanced serialization build in (writeReplace, readObject, etc.). As standard java serialization does IMHO not make any sense in the browser this should also not be supported.
• ZoneId should be supported to some degree. At least UTC has to work so it makes any sense. However, also ZoneOffset would be nice to have. But region IDs would most probably be overkill again. They could be supported as containing any kind of string but not allowing to calculate with it as the offsets for all regions require a larger map of data.
• In general I would prefer an approach with compatibility rather than maximum performance.
• Tricky aspect is the DateTimeFormatter[Builder]
• In question is if TemporalQuery should actually be supported.
• Code from java.time is using java.lang.Math with methods addExact, multiplyExact, floorMod, and floorDiv that is not (yet) supported by TMath. I assume I would also add these methods to TMath within a PR for adding java.time. I am not quite sure if this is easy, complex or almost impossible. Do not yet even know how TeaVM emulates long as JS Number has less precision.

[hohwille]

When I write T* types for classlib I can use the regular java type as well as the T* type. From what I have seen in classlib I assume that using the T* types wherever possible is preferred. In cases like toString() that can not return TString the plain Java type is used. I hope my assumption is correct and I am going into the right direction. I am sometimes unsure whether I should use CharSequence or TCharSequence. Also I have issues with TList as I can not use it in for-each loops since it does not implement Iterable. Can I also just use List in T* code of classlib?

[konsoletyper]

ZoneId should be supported to some degree. At least UTC has to work so it makes any sense. However, also ZoneOffset would be nice to have. But region IDs would most probably be overkill again. They could be supported as containing any kind of string but not allowing to calculate with it as the offsets for all regions require a larger map of data.

Timezones are already supported in java.util.* package, with all larger map of data, so you can just use it.

Code from java.time is using java.lang.Math with methods addExact, multiplyExact, floorMod, and floorDiv that is not (yet) supported by TMath

So you are porting some code to TeaVM? Where did you get it?

Do not yet even know how TeaVM emulates long as JS Number has less precision.

TeaVM emulates long with object that contains two 32-bit integer fields

From what I have seen in classlib I assume that using the T* types wherever possible is preferred.

No, it was very old approach when I only had few emulated class. This approach let me ensure that all newly implemented classes have all the dependencies. I think that times I didn't even have support for tests, so it was the only option. Now you only need to name your classes with T prefix, but use other classes from java.* package directly.