@som-snytt it seems likely we'll merge this. but by merge time we'll need a public-facing PR description explaining what this does and when it's needed. but I think it would actually be helpful if you provided that now, to help reviewers?

Another thought: do you intend to port this to Scala 3? We're always a bit reluctant to add things to Scala 2 unless the path to supporting them in 3 as well is clear. That's partly because the 3 folks aren't happy if they feel we are putting pressure on them to support things they don't want to support, and also partly because users can be annoyed or disappointed if the two versions seem gratuitously misaligned to them.

Do we know if the workaround suggested on the scala/bug ticket also works in Scala 3? Because if it does, that would ease the 2 vs 3 tension here a bit, since 3 users wouldn't be blocked.

-Yunsafe is a convenience to get a Scala 2 project to use--release, for a net gain in API safety without too much hassle.

A project that is cross-built probably has the machinery to build against the jar of its choice, ifUnsafe is part of its long-term strategy, so that would not be a use case supported by this private option.

Nice description — thank you.

Let's ponder the naming, prior to merge.-Yunsafe's broadness is a bit cryptic and threatening. Maybe something that makes it clear it's 1) a very specific/niche thing, and/or 2) a modifier to--release? like-Yrelease-include-unsafe or-Yopen-internal-packages something? thinking out loud

Instead ofrelease-notes the label should be--release notes.

I assUME thatNonFatal is adequate. I don't remember if I had noticed something thrown such as a LinkageError (to guess).

Maybe it should beallow-packages. I was thinking of modules. Edit:use-packages? oh,require-packages.

I'm almost ready to hit "approve" here, only remaining concerns are naming and doc

wdyt about the flag name -Yopen-packages?

@som-snytt what is the relationship between this new flag and--add-opens? I'm asking for my own understanding, and also because it could affect the naming, and also because it could affect what we put in the PR description

P.S. needs rebase!

Apparently,-Yunsafe was the right name all along. Who's been messing with DirectoryClassPath?

An interesting post-mortem would be rates of change to modules (classes and packages), as a measure of what was so complicated.

Thank you for this.
Will there a '-Yexport-packages' too？

This is just for considering packages on the real class path during compilation. Clearly it needs a better name

-Yrerelease? Because you use it when--release which hides the package and you want torelease it for use.-Yunrelease.

oh just--release:8,sun.misc because you're saying use release 8 of the API but include this extra package.

--release:8,sun.misc would be nice, but it also creates a cross-building burden, besides complicating help and parsing.

Instead, we get a companion option-Yrelease:sun.misc which allows look-ups in the named packages when--release is set by the user.

@mdedetrich ping, pekko/akka can make use of it in future

Yup, it has to be released in Scala 2.12/2.13/3.3.x for us to use it though

That could happen! I might need a reminder...

That could happen! I might need a reminder...

Ive been told I'm good at that, to the detriment of societies sanity

@som-snytt what is the relationship between this new flag and--add-opens? I'm asking for my own understanding, and also because it could affect the naming, and also because it could affect what we put in the PR description

What does the current workaround look like? Could someone point me to the relevant section of the Akka build or the Pekko build?

I think-Yrelease might be an okay name, but I'd like to understand this whole thing better.

@SethTisue this hasn't to do with modules, but with the--release mechanism, where the available platform API is defined by the ct.sym (and not by rt.jar). This just asks for a "backup" jrt class path that allows only the given package for look-up.

Practically, it's to support access tosun.misc.Unsafe, which is not a platform module but unsupported stuff. There is a JDK ticket to come up with replacements, but that is not yet the case even for projects willing to migrate.

Note to self: doesa.b.c also allow classes ofa anda.b?

What does the current workaround look like? Could someone point me to the relevant section of the Akka build or the Pekko build?

Still curious about this, if@mdedetrich or@He-Pin or somebody could answer.

@SethTisue This code origin from Akka too, some kind of this.
https://github.com/apache/incubator-pekko/blob/main/project/JdkOptions.scala#L69

Thanks@He-Pin — though I see now we already had this same exchange over atscala/bug#12643 😆