Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate scala-java8-compat in the standard library ? #11408

Open
smarter opened this Issue Sep 7, 2018 · 12 comments

Comments

Projects
None yet
10 participants
@NthPortal

This comment has been minimized.

Copy link

NthPortal commented Sep 7, 2018

I don't know of the migration cost, but I think it would make sense to migrate them from scala.compat.java8 to scala.compat.java (and scala.concurrent.java8 to scala.concurrent.compat.java or maybe just scala.compat.java as well? I'm not sure), since there's no reason for the package to be exclusive to Java 8 things.

@martijnhoekstra

This comment has been minimized.

Copy link

martijnhoekstra commented Sep 10, 2018

From the opposite perspective, should narrow(er) integration with OpenJDK be in the stdlib at all (which means required re-implementation of those OpenJDK parts that it has close interop with for scala-js and scala-native), or should stuff like JavaConversions be moved out of the stdlib to compat libraries to reduce pressure on scala-js and scala-native to implement interfaces that only exist to be hidden by a compat package?

@sjrd

This comment has been minimized.

Copy link
Member

sjrd commented Sep 14, 2018

Indeed. Please let's try not to put more stuff related only to interop with Java in the stdlib. We should have less of those, not more.

@hrhino

This comment has been minimized.

Copy link
Member

hrhino commented Sep 15, 2018

Agreed on both scala.compat.java and on moving more compat stuff in.

Most of the Scala programmers I know handle Java APIs with great care as it is, and adding another library (especially if it's as stable as I hope it can be) is a negligible cost compared to the cost of referencing more JRE classes in the stdlib.

@SethTisue

This comment has been minimized.

Copy link
Member

SethTisue commented Sep 15, 2018

there ought to be a "Java interop guide" on https://docs.scala-lang.org. I've just made a ticket on that at scala/docs.scala-lang#1146 . among other things, it would call people's attention to scala-java8-compat's existence

@smarter

This comment has been minimized.

Copy link
Author

smarter commented Sep 19, 2018

A concrete example where the lack of modern Java interop in the standard library is hurting us: JDK 11 adds String#lines, this takes precedence over Scala's StringLike#lines, the former returns a Stream thus breaking everyone's codebase. If we had something built-in to handle streams this wouldn't be too bad, but I doubt every library is going to start depending on scala-java8-compat just for this. (A better solution would be to useStringLike#linesIterator, unfortunately it's deprecated so not an option if you like -Xfatal-warnings).

@dwijnand

This comment has been minimized.

Copy link
Member

dwijnand commented Sep 19, 2018

JFYI that example is tracked and in discussion at #11125.

@szeiger

This comment has been minimized.

Copy link

szeiger commented Nov 5, 2018

Another option is the reintroduction of an aggregated standard library like the now defunct scala-library-all. scala-java8-compat could become a separate library module in the standard scala repository and be part of a new scala-library-all which would be the recommended library on the JVM.

@lrytz suggests a scala-library-core without excessive JVM compatibility stuff (like JavaConverters) and having scala-library be the aggregated version. I'd prefer this approach, too, but I'm worried about tooling compatibility (e.g. sbt expecting an actual scala-library JAR).

@SethTisue

This comment has been minimized.

Copy link
Member

SethTisue commented Nov 5, 2018

discussed at team meeting just now. tentative consensus:

  • reintegrate: yes
  • scala-library-all: no
  • scala-library-core: not explicitly discussed, but probably not?

key arguments:

  • discoverability of external libraries remains poor (Scala Platform hasn't happened, easier pulling of additional JARs into the REPL hasn't happened)
  • JavaConverters is already in and the distinction between Java 8+ and Java 8- no longer applies
  • scala-java8-compat is tightly integrated with collections internals, is isn't in fact independent code

hopefully the reintegration can be done in a manner that only causes minor inconvenience for e.g. Scala.js

@SethTisue

This comment has been minimized.

Copy link
Member

SethTisue commented Nov 5, 2018

@lrytz will assess the stuff that isn't about collections

@SethTisue SethTisue transferred this issue from scala/scala-dev Feb 20, 2019

@SethTisue SethTisue added this to the 2.13.0-RC1 milestone Feb 20, 2019

@SethTisue

This comment has been minimized.

Copy link
Member

SethTisue commented Feb 20, 2019

@Ichoran

This comment has been minimized.

Copy link

Ichoran commented Feb 20, 2019

I've been working only on the integrated version, not on the separate repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.