Remember the problem that Jack had with his BubbleSortUtil class? It was a Java class he wrote with the intention of it being private to his library. However, even though it started out as a private internal class, it ended up being a public class because other developers just decided to use it.
That was just a small library. Now, think about a library as big and as widely used as the Java runtime. The Java runtime obviously bundles in internal classes that are required for its functioning and aren't meant to be used by application developers. However, considering the magnitude of its usage, it isn't surprising that some of the internal classes are inadvertently used by developers anyway.
A classic example of this is a class called Unsafe in the sun.misc package. This ominous sounding class has been a part of every major JDK release for a while now. Can you guess what it does? It contains a collection of methods that perform, according to the author of the class, low-level unsafe operations. Yes, it actually says that in the comments in the class! For instance, it has a method that gets a value from a memory address. Not a typical day's work for a Java application developer! You wouldn't, and ideally shouldn't, do something like that as an application developer. This is why the class has been marked as an internal API. Want to look up its Javadoc to use it? You won't find it in there. Want to create a new instance of the class? Its constructors are marked as private. If you do somehow use it and compile your code, every Java compiler since Java 6 will give you a nasty warning, discouraging the usage of the class. And, if you still need more reasons to avoid using it, you'd be best served to just look at the name of the class!
You must have guessed what's coming by now. The sun.misc.Unsafe class has now been used in multiple projects by many developers to perform those very low-level operations, in spite of all those preventive measures that the Java runtime authors have put in place. One could argue that it implements functionality that isn't commonly available elsewhere, and for a developer who needs to do something like that, nothing beats just picking it up while it's available in the classpath and ready to use. Unsafe isn't the only internal API that is being used this way, of course. There are a few more internal classes, many in the sun.* packages, that developers have used over the years even though they shouldn't. Moreover, as long as developers continue to use these APIs, it becomes harder to remove them from the runtime. This has ended up continuing the existence of these classes in subsequent versions of the runtime, thereby allowing more developers to use them!
These limitations of the Java runtime and library system have been felt for a while now. All the problems I've outlined so far exist because of the lack of ability to create modular units of code in Java. Such a construct simply hasn't existed in the language so far. The need for it has been strongly felt in the community.
Multiple proposals for a module system for Java have been made over the years, including JSR-277 way back in 2005 (https://jcp.org/en/jsr/detail?id=277) and JSR-294 (https://jcp.org/en/jsr/detail?id=294) in 2006. After facing several hurdles, modularity is finally coming to Java with the 2017 release of Java 9 with JSR-376 (https://jcp.org/en/jsr/detail?id=376), the spec titled Java Platform Module System, as well as Project Jigsaw.
JCP: The Java language specification has, for a long time, been a community-owned asset. There is no one central authority that has complete control and the decision-making power in how the language evolves. Each of us, as Java developers, can have a say in how we want the language to change and grow. The Java Community Process (JCP) is a mechanism, introduced in 1998, that allows anyone interested in the future of the language specification to register, provide input, and take part in the technical specifications process. Go to https://jcp.org to learn more.
JSR: Let's say you are a part of the Java Community Process, and you have a great idea for a change in the language specification. What you do is create a Java Specification Request (JSR)--a formal document that describes the proposed changes. JSRs are reviewed and voted upon as a part of the community process before they become final. Once a JSR does become final, it is worked on and eventually becomes a part of the language specification.
Fun fact: The Java Community Process itself is an important part of the language, and so changes to it are also handled just like any other changes to the language--by submitting a Java Specification Request for it. Yes, there's the JSR that describes the JCP!