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
Add ClassValueCompat
to support systems without java.lang.ClassValue
(such as Android)
#9752
Conversation
16fa232
to
e18202b
Compare
Nice! FWIW, I've also opened an issue against Android about the lack of ClassValue, but it's not clear to me if they're interested in fixing it: https://issuetracker.google.com/issues/196063118 (maybe someone with some twitter clout could try bringing attention to this?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that contribution, the approach LGTM!
c5a9d09
to
272907f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the rewrite of ModuleSerializationProxy
in Scala looks good, but it's certainly not trivial to think of all the possible consequences.
|
||
import scala.util.Try | ||
|
||
private[scala] abstract class ClassValueCompat[T] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to bring this to discussion again, but do we really want to add this class to the scala
package? Even if it's package private it will show up in some places way too prominently. For example when editing a Java file in a mixed project, scala.ClassValueCompat
will be a public class.
I'd rather keep it in scala.runtime
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree; I argued (at least somewhat) against scala.compat
, but I think scala
is an even worse choice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issues and fixes mentioned below and here got applied to the latest commit
I looked at the rewrite of
|
c312f37
to
b55334e
Compare
On runtime systems where `java.lang.ClassValue` is not available `ClassValueCompat` re-computes the value on each `get` invocation. Co-authored-by: nwk37011 <nwk37011@gmail.com>
b55334e
to
6c9dd4d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebased and squashed.
Thank you, @nwk37011!
def remove(cls: Class[_]): Unit | ||
} | ||
|
||
private val classValueAvailable: Boolean = try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it in any way be beneficial to make it lazy val
? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, the field is only initialized when the enclosing object is first accessed.
on JDK 17 we're seeing (at https://app.travis-ci.com/github/scala/scala/jobs/542786102):
PR with fix: #9785 |
ClassValueCompat
to support systems without java.lang.ClassValue
ClassValueCompat
to support systems without java.lang.ClassValue
ClassValueCompat
to support systems without java.lang.ClassValue
(such as Android)
I have a question related to this PR, so I thought I would just beg for attention here. Let me know if this is inappropriate: https://stackoverflow.com/questions/73042201/why-a-scala-2-13-app-is-trying-to-use-javaclassvalue-on-android-if-it-is-not-a |
The goal of this commit is to enable systems without java.lang.ClassValue to fall back to other method which does not utilize java.lang.ClassValue while keeping its current behavior as how it is for systems with java.lang.ClassValue. Use of java.lang.ClassValue seems mainly for caching as #7879 introduced, so I ran a related benchmark from one of the commits and got following results
For cases where systems lacking java.lang.ClassValue, I earned the following result which seems obviously slower than the above two but still it enables such systems to actually utilize classes such as ClassTag instead of throwing ClassNotFoundException
This commit combined with #9739 will open Scala 2.13.x to wider range of systems including Android as discussed and demonstrated at https://users.scala-lang.org/t/scala-2-13-on-android/7235/24