Not worth it. How will package level access be affected? How can this be exploited? How will it affect security and signing when things from the same package aren’t *really* from the same package?
Now that the recommendation is to bundle a JRE with your application, that kind of backwards compatibility is becoming less critical. If necessary, deprecate java.util.Random. Make an interface for RNGs to implement and go with factories and a service provider pattern. Sometime down the line retire java.util.Random. Scott > On Jul 2, 2019, at 7:55 PM, Jacob Glickman <jhg...@bucknell.edu> wrote: > > Friendly reminder :) > ---------- Forwarded message --------- > From: Jacob Glickman <jhg...@bucknell.edu> > Date: Sat, Jun 22, 2019 at 4:42 PM > Subject: Mechanism to maintain backwards compatibility when moving classes > to different packages > To: <core-libs-dev@openjdk.java.net> > > > Yesterday, Mark Reinhold introduced the idea of a java.util.random > subpackage[1]. Obviously, moving java.util.Random into that subpackage is > not currently an option, as that would break backwards compatibility. > Assuming the subpackage is created, it would make sense to ultimately move > java.util.Random into it. For that reason, I propose a new language feature > that could make this possible: > > package java.util.random previously java.util; > > The syntax isn't important at the moment, but this mechanism should allow > for users to run previously-compiled code with newer versions of Java, even > if their code points to a class that has since been moved to a different > package. > > To eliminate potential bugs, users compiling new code shouldn't be allowed > to reference java.util.Random, even if java.util.random.Random states that > it previously resided in java.util. > > I'm curious what you all would think of this, as it is not just applicable > to this single example. There have been plenty of times that I've realized > that my packages were named badly, but I'm forced to stick with that naming > (unless I want my users to have to modify their code). > > Thanks, > > Jacob Glickman > > [1]: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-June/060995.html
