Mechanism to maintain backwards compatibility when moving classes to different packages

Scott Palmer swpalmer at
Wed Jul 3 00:10:45 UTC 2019

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. 


> On Jul 2, 2019, at 7:55 PM, Jacob Glickman <jhg023 at> wrote:
> Friendly reminder :)
> ---------- Forwarded message ---------
> From: Jacob Glickman <jhg023 at>
> 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 at>
> 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]:

More information about the core-libs-dev mailing list