java.time.* from Java 1.8 is missing

[hrj]

Java 8 has number of convenient Date & Time classes modelled on Joda Time. Would be great to be supported in Scala-JS.

Examples:

java.time.LocalDate
java.time.Period

[sjrd]

This requires a huge amount of work to port a BSD- or MIT-licensed implementation of those to Scala. The core team doesn't have the manpower to work on this, but PRs are welcome!

[hrj]

Thanks for looking and keeping it open; I didn't expect an overnight solution to this. But I have an idea / doubt:

Is it possible to provide parts of the Java standard library as a separate Scala JS library? Will that help with the license restriction? (I am assuming there is some automated way to translate existing Java code / Java-byte-code to a Scala-JS compatible library).

[sjrd]

Oh yes, you can certainly provide parts of the JDK as separate Scala.js libraries. You just have to configure the build not to bundle the .class files into the .jars, but only the .sjsir files.

There is no automated way to translate Java to Scala.js per se. I know there are a few Java-to-Scala converters out there, but they are known to be imperfect at best. If the Scala code does not depend on other non-supported parts of the library, then they should work with Scala.js out-of-the-box.

[rparree]

@hrj you might be better of writing a scalajs interface to something like http://momentjs.com/ (or using it adhoc as js.Dynamic)

[hrj]

@rparree Thanks for the suggestion, but no, I want to share this code on server and client sides, so that I can be sure they are computing the same results, among other reasons.

[rparree]

Gotcha..i am in the same situation. At this point i am using JSR 310 on the server and momentjs (via some partial traits) on the client (so had to make different case classes for client and server for this feature)

[aryairani]

Joda-Time has an Apache license. Since Apache Harmony has a compatible license, does Joda-Time?

[gzm0]

Yes. Joda-Time would have a compatible license. But since it would probably be best to port it in a separate project anyway, this would not really matter.

[aryairani]

Maybe I misunderstood, but a separate project wouldn't help people using java.time — right?

[gzm0]

No. But someone could implement Joda-Time in a separate project. This would also allow people that still use JDK{6|7} to use it.

[aryairani]

Wait what? People who still use JDK{6|7} can just use Joda-Time directly. Plus, this ticket is about java.time.* support.

[mdedetrich]

As a side note, I am currently working on porting joda-time to Scala/Scala.js. Its already been entirely converted to Scala, I just need to split out the relevant sections and implement stuff like java.util.Locale (also waiting on implementations of java.util.Arrays and whatnot)

I used http://javatoscala.com/, but its definitely far from perfect, and a lot of code I have had to manually alter/rewrite. Also, there are a lot of constructs that Java has, which Scala doesn't have, which include

• labels/break to label
• high performant for loop (you can convert this to a while loop thankfully)
• break (there is scala.util.control.break._), need to verify this works correctly. Test cases should show this
• Nuances in super/constructor (joda-time makes heavy use of super and inheritance).

And joda-time uses Apache License

Regarding java.time.*, it would definitely be useful for Javascript client, and http://javatoscala.com/ goes a long way in regards to converting 70-80% of the code, but I imagine it would be a lot harder due to it being tied much closer to the JVM. joda-time doesn't appear to be too bad in this regard because it is a clean room implementation

[gzm0]

@mdedetrich Just a quick note: The Scala.js optimizer will inline foreach into while loops, so you don't have to change them yourself.

We can't port java.time.* using a converter due to licensing issues.

[mdedetrich]

@gzm0 Thanks for the heads up!

Also regard java.time.*, I assume a clean room implementation is perfectly fine? In which case, it would definitely be a lot of work.

Note that I am not a lawyer, but even if you do use converters, none of them will produce 100% correct Scala, so you will always end up heavily altering any converted code

[sjrd]

Clean room implementations are fine, of course. That's what we do all the time.

Even if you rework the code produced by a converter, it's not a clean room implementation, though. So yes it's a lot of work.

[mdedetrich]

Cool thanks for letting me know

[mdedetrich]

Hey guys, just letting you know that I have done an early release of Soda-Time, link is here https://github.com/mdedetrich/soda-time. Its still alpha quality, but since a lot of people were asking for it, I released it early

[niladic]

Nobody seems to have mentioned it, but maybe some of you guys know about it: most of the code from jsr310 is actually BSD licensed, it was GPLed after a lot of initial work for its inclusion into the openjdk. I guess the original BSD code can still be found, but what can be of special interest for people who want to take a stab at a Scala.js implementation is that the author of the joda time library took the original BSD code and created a backport for jdk6-7: https://github.com/ThreeTen/threetenbp. Also, by doing a very quick comparison, it seems the GPL code in openjdk is very close to the backport code, so there actually exists a good and robust BSD licensed java lib which implements parts of the jsr.

I am no expert in licenses but I think it is compatible with Scala.js, maybe someone can confirm that.

If this is the case, then it could help people who want to make or review PRs on this issue. For example I see that @ummels did not implement Duration.parse maybe because the parsing is tricky, but the regex used in the openjdk: https://github.com/openjdk-mirror/jdk/blob/jdk8u/jdk8u/master/src/share/classes/java/time/Duration.java#L151, is actually BSD licensed https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/Duration.java#L119, so I guess using it would not violate the Scala.js license (again I might be wrong, so a confirmation would be great, and an additional check should be done for regex since semantics change from java to js, though without unicode class this one seems fine).

[sjrd]

This is now addressed in a separate repo:
https://github.com/scala-js/scala-js-java-time

See also #2039 for an alternative implementation, which is still worth discussing.

[srp]

Anyone stumbling across this, scala-java-time currently seems to be one of the more compelling options. https://github.com/cquiroz/scala-java-time