The module system

Modularity changes that are introduced to the SDK and runtime environment affect structure, content, and operation. Compatibility problems might exist for applications that rely on the runtime structure or content of earlier releases, or on the unsupported but exploited use of internal APIs.

The Java™ module system is described in an overview at The State of the Module System, and in more detail by the following Oracle JDK Enhancement Proposals (JEPS):
Modularity changes are summarized in the following list:
Internal APIs are restricted
Although internal APIs are private and not intended for use, many were accessible to applications. By default in Java 11, access to internal APIs is allowed at run time for packages that were present in Java 8, although a warning is printed the first time an access occurs. However, most internal APIs are not accessible at compile time.
As a temporary workaround you can use the --add-exports option on the command line to break encapsulation. For accessing an internal API by using reflection, use the --add-opens option. For more information about these options, see the Oracle documentation for the java command.
The structure of the runtime image is changed.
Modularity removes the concept of a developer kit and a Java Runtime Environment as distinct entities. A modular runtime image is simply built to contain the components that are needed, which might include a subset of tools. One consequence of this design is the removal of the /jre directory. Issues are likely to arise if existing applications depend on the current structure of runtime images.
Configuration files, such as java.security and logging.properties, are now located in a new directory, /conf, and its subdirectories.
The endorsed-standards override mechanism is removed.
This mechanism, which involves placing JAR files on the jre/lib/endorsed path, is used in Java 8 to implement newer versions of standards that are maintained outside of the Java Community Process. Endorsed standards will be supported only in a modular form with the new concept of upgradeable modules. The java.endorsed.dirs system property is no longer defined. Code that assumes a non-null value for this system property might fail.
The extensions mechanism is removed.
The extensions mechanism can be used to install additional APIs into a runtime image, by placing jar files into an extensions directory, lib/ext. The ext directory no longer exists in a modular image and applications that rely on this mechanism will fail. The java.ext.dir system property is no longer defined. Code that assumes a non-null value for this system property might fail.
The rt.jar, tools.jar, and dt.jar files are removed.
JAR files are replaced by modules in the new system. Code that depends on finding these JAR files will fail. As an alternative, consider using the jrt: file system, intended for modular class files, as described in JEP 220, New URI scheme for naming stored modules, classes, and resources, item (3). More information is also available in the Oracle migration documentation.
The bootstrap class path option is removed.
The default bootstrap class path can no longer be overridden, nor can you prepend the path with files and directories. If you attempt to use this option at runtime, the option is ignored. Note that -Xbootclasspath/a continues to be supported for appending to the end of the bootstrap class path.
New class loader implementations
The application class loader is now an instance of an internal class.
The extension class loader is now renamed to the platform class loader. It is also an instance of an internal class.

The following quick start guide provides some examples that show how to develop applications with the module system, http://openjdk.java.net/projects/jigsaw/quick-start.