scala-native icon indicating copy to clipboard operation
scala-native copied to clipboard

Port String methods introduced in JDK 11 and 15 from Scala.js

Open WojciechMazur opened this issue 2 years ago • 3 comments

This PR ports String methods added to JDK 11+:

  • repeat
  • strip
  • stripLeading
  • stripTrailing
  • indent
  • stripIndent
  • translateEscapes
  • transform

Fixes #1681 Fixes #2155

WojciechMazur avatar Jul 05 '22 14:07 WojciechMazur

As I commented in the original issue, a year or more ago, I believe that a clear decision rule should be given to SN users and developers about what is and what is not in the javalib.

I understand that times change. It is only fair to let direct users know what is in the soup. At one point, the decision rule was Java 8 methods only. This was enforced by some tricky stuff in the SN build. The user documentation was systematically vague about which Java version SN applications were expected to use. It was kinda "If it works, go for it".

If Java N methods are going to be added, I strongly recommend that at they very least they be documented for end users. Can contributors add Java N methods? Can they use Java N methods in code they contribute to Scala Native. What is the goal N for Javalib? Are the barn doors open?

This may seem like a PITA comment, but I believe addressing some of these issues will help the current PR harvest the happiness it intends.

PS: Yes, I am happy to see these routines and hope for more. I personally would like to go to Java 17, at least for execution, and be done with it for a year or so.

LeeTibbert avatar Jul 07 '22 14:07 LeeTibbert

See Issues #2473 & #2445. If the "Java 8" only guidance is made obsolete by this PR those are the kind of things which could benefit from new guidance. Are they now acceptable/possible?

LeeTibbert avatar Jul 07 '22 15:07 LeeTibbert

Until Java 11 was released as a Long Term Support (LTS) and then the same for Java 17, Java 8 only made sense even though normal Scala has been making modifications since Java 9 was released. Because Java 11 and 17 are out in the wild we need to support them especially where it causes breakage or downstream libraries need to change code to "workaround" like I have done in sconfig. Having the additional methods does not cause a problem if you stay on Java 8 and remember that we link against the JVM methods in the compiler so it doesn't cause problems. Not sure if this helps but...

Scala is basically a JVM language so both Scala Native and Scala.js need to follow along. I am pretty sure if your use the new methods then you are forcing a minimum version of Java just like on the JVM. I am seeing Java 8 being dropped in the Java world - it is very old.

ekrich avatar Jul 07 '22 15:07 ekrich