Java 9 and Project Jigsaw

What is modularity : as defination
  Designed with standardized units or dimensions, as for easy assembly and repair or flexible arrangement and use: modular furniture; modular homes.
  In Technial We can say develop independed modules which comunicate using standardised interface (separation of concerns,loose coupling)
  Modularity composed of standardized, self-contained units for easy construction and flexible use.
 


Packages vs module
 
   Package: It is bunch of class(.java) file which is separate by their function or their name. so it is also help for naming,A package is a namespace; it let's you handle naming conflicts.
  
   Module: Large applications are typically built in several parts, which are more tightly connected to each other than to the outside. Therefore, one would like to give these parts more access to each other than the outside world has. One might also want these parts reused at many points in the system without worrying about the synchronization of shared data. this part is called module in java. WAR,EAR jar etc are called module in java language.

Why is modularity required? 
Better encapsulation:  Currently, every public class/interface and every public method is published to the world.  If the intention is to only make a method or class available among more than one package within an application it cannot be encapsulated without carefully omitting said classes from whatever jars a library publishes to client applications.  With a proper module system, a package may be marked as internal to the module and its contents available throughout the module but not to the outside world.  This in turn imposes discipline and makes it much easier for developers to publish more compact APIs, since potentially only one package out of several internal packages could be made visible to the outside world.

• Versioning: Currently, Java developers much publish versions by hacking the manifest file within a Jar file.  This means there is no intrinsic support for publishing versions or making dependencies among modules clear.   With modularity, it becomes possible for module B to publish that it requires module A version 3 (or versions 3-4), and that any module A version lower than 2 will possibly break module B's functionality.  The lack of such a mechanism is one of the causes of "jar hell" experienced by Java developers.  There are ways around this, such as using the file system (ex a sub-directory of a package directory is the version identifier), but they're far less elegant than a proper module system.
• Compile-time and runtime symmetry:  Java compile time and runtime dependencies are orthogonal, which causes problems such as the potential for ClassDefNotFound errors.   A proper module system guarantees that compile time and runtime dependencies are satisfied atomically.
• Tooling:  IDEs should be able to more easily manage a project's dependencies.
• Deployment and module repositories:  Given the compile time and runtime symmetry above, it will be possible to publish modules within repositories, either on the web or internally on a company network.   This will eliminate a whole host of deployment issues as this mechanism is greatly superior to the currently one of managing jars and classpaths by hand (or within scrips), or any workaround involving an internal filesystem.   Caching of remote modules also becomes possible.
• Separate Release Schedules:  It should be possible for Oracle to release various libraries separately, according to their own schedules, instead of waiting for the window where the entirely next version of the JDK is deployed.   For example, a new version of a concurrency library with desirable improvements could be published between JDK releases.
• Quarantine of legacy APIs:  The JDK is currently a monolithic blob of unrelated functionality that's packaged together.  This means if all I want is to run a simple Java program, I need to download CORBA, Swing, the legacy Date/Time API, etc, (especially APIs that have been marked deprecated) even if I only use a subset of the functionality.   What's more, with every new version of the JDK, this functionality must be kept up to date and the commitment has been made to maintain all of these classes.  With modules, this legacy functionality can be quarantined from the rest of the JDK and put into strict maintenance mode, to be used only by those who need them and Oracle's backward compatibility burden could potentially be significantly reduced.

What is Jigsaw

 Java Platform Module System – commonly known as Project Jigsaw, or JSR 376 – is that it has been used to break apart the monolithic Java runtime into smaller modules.
 JEP 201: Modular Source Code


 Class loaders - Jigsaw will not use class loader; it's up to runtimes (such as application servers or OSGi) to work with modules and class loaders

Dependencies - Jigsaw will allow to specify dependency on modules by name but not at the package level

Dynamic Services - The runtime services model provided by OSGi will not be provided by Jigsaw
Jigsaw is not intended to replace and/or compete with any other runtime or build time module system (such as OSGi or Maven). In fact, it's the intention of Jigsaw to be interoperable (somehow) with both.

JEPs
200: The Modular JDK
Module summary
201: Modular Source Code
220: Modular Run-Time Images
260: Encapsulate Most Internal APIs
261: Module System
282: jlink: The Java Linker

http://openjdk.java.net/projects/jigsaw/

Download : https://jdk9.java.net/download/

 Referances :
   http://openjdk.java.net/projects/jigsaw/spec/sotms/
   http://openjdk.java.net/projects/jigsaw/spec/sotms/
   http://www.merriam-webster.com/dictionary/modular
   https://en.wikipedia.org/wiki/Modular_programming
   http://stackoverflow.com/questions/13157377/class-vs-package-vs-module-vs-component-vs-container-vs-service-vs-platform-in-j
   http://ldegruchy.blogspot.com/2014/09/java-9-modularity-is-enough.html