We Keep Coding

What is the difference between modules and JAR files?

I am learning about Java 9 from What's New in Java9 and one of the hot topics in the discussion is The Modular JDK.
Are JAR files modules?
How is a module different from a JAR file?

Module: A new language feature introduced in Java 9 (similar to class, interface, package, etc.) that consists of a collection of packages, similar to how a package consists of a collection of types.
JAR: An archive file format that bundles code and resources and which can be loaded by the JVM.
More specifically, a module is defined as follows:
In order to provide reliable configuration and strong encapsulation in a way that is both approachable to developers and supportable by existing tool chains we treat modules as a fundamental new kind of Java program component. A module is a named, self-describing collection of code and data. Its code is organized as a set of packages containing types, i.e., Java classes and interfaces; its data includes resources and other kinds of static information.
...
A module’s self-description is expressed in its module declaration, a new construct of the Java programming language.
...
A module declaration is compiled, by convention, into a file named module-info.class, placed similarly in the class-file output directory.
A module can be compiled into a Jar file, in which case the Jar file is labelled a modular Jar file:
Existing tools can already create, manipulate, and consume JAR files, so for ease of adoption and migration we define modular JAR files. A modular JAR file is like an ordinary JAR file in all possible ways, except that it also includes a module-info.class file in its root directory.
Some other differences between a module and a JAR:
Modules can require other modules in order to allow accessing dependent classes by the requiring module. A Jar has no such dependency concept.
A module can decide which classes and interfaces to export to other modules that require it. A Jar has no such encapsulation mechanism.
A module can be compiled into a modular Jar file, but some modules (e.g. JDK modules) are compiled into another format called JMOD.
The name of a JAR can be changed. As long as the JVM classloader finds the needed class on the classpath (which can be composed of a single JAR, multiple JARs, or a mix between directories or JARs), the name of the JAR file can be anything. However, the name of a module can be explicitly referenced in the declaration of other modules, and such the name defines it and cannot be changed freely.

Strictly speaking, a module is a run-time concept. As others have quoted from The State of the Module system:
A module is a named, self-describing collection of code and data. Its code is organized as a set of packages containing types, i.e., Java classes and interfaces; its data includes resources and other kinds of static information.
This is very similar to JARs, but...
JARs have no meaningful representation at run time
JARs are not "self-describing", which in this case means they do not have a name that the JVM cares about, can not express dependencies or define a proper API
This leaves the question, where do modules come from? There are various ways but the most prominent one for developers is the modular JAR. A modular JAR is just like a plain JAR, but it contains a module descriptor, a file module-info.class that was compiled from a module-info.java. It is that file that defines a module's name, dependencies, and APIs.
So there is a strong connection between JARs and modules: JARs are the containers from which the module system creates modules and (at the moment) each JAR can only contain a single module. It is important to note that even on Java 9 JARs do not have to be modular - plain JARs are totally fine.

Are JAR files Modules? How Module is different from JAR file?
No, a Java Archive is not a Module.
Just for an example, while classes of the same package could have been spread across JARs, the same package now can not be read from multiple modules.
A JAR is a file format that enables you to bundle multiple files
into a single archive file. Typically this contains the class files
and auxiliary resources associated with applets and applications.
on the other hand (I'd tried describing this here ~> java-module as well)
A module is a named, self-describing collection of code and data. Its
code is organized as a set of packages containing types, i.e., Java
classes and interfaces; its data includes resources and other kinds of
static information.
This also consists of the module declaration as specified with the help of module-info.java.
Each module definition is either
A module artifact, i.e., a modular JAR file or a JMOD file containing a compiled module definition, or else
An exploded-module directory whose name is, by convention, the module's name and whose content is an "exploded" directory tree corresponding to a package hierarchy.
As introduced with the module system, a modular image is composed of modules rather than JAR files.
Modularity is foreseen for with dynamic configuration in terms of Modular WAR file as well.
But for the ease of adoption of Modules a Modular JAR file, was introduced in JDK9, such that lets say for a module consisting of a module-info.java such that
module com.foo.bar { }
and other java classes as
com/foo/bar/alpha/AlphaFactory.java
com/foo/bar/alpha/Alpha.java
Existing tools can already create, manipulate, and consume JAR files. A modular JAR file is like an ordinary JAR file in all
possible ways, except that it also includes a module-info.class file
in its root directory. A modular JAR file for the above com.foo.bar
module, e.g., might have the content:
META-INF/
META-INF/MANIFEST.MF
module-info.class
com/foo/bar/alpha/AlphaFactory.class
com/foo/bar/alpha/Alpha.class
...
A modular JAR file can be used as a module, in which case its module-info.class file is taken to contain the module’s declaration.
It can, alternatively, be placed on the ordinary class path, in which
case its module-info.class file is ignored.

What is the relationship between package and jar file in java?

What is the relationship between package and jar file in java? Do you get one jar file for each package?

A package logically organizes your classes. For example, you can declare package com.stackoverflow in each of the source files to keep the all files in the same directory.
A JAR file lets you physically organize your classes. You can take any Java files and store them in a JAR file.
A JAR file may contain multiple packages, and multiple JAR files may contain files that belong to the same package. So, a JAR file is largely a way to store multiple class files in a single physical file.

Package consist of classes..
Jar : collection of packages and classes...

A package is a way of organizing Java types into groups of related types, and is part of the Java language. It doesn't exist as a resource or artifact, rather as a namespace, which means it's part of the type name.
A JAR is not part of the Java language but a file in a ZIP format. It contains loadable forms of Java types, i.e., class files, plus other files needed to deploy an application. Its purpose is to provide a deployment mechanism for Java code and resources.
It's like the difference between a chapter of a novel and a ZIP file containing a file representation of the novel. One is an abstraction, the other a file.

How to monkeypatch a .class file in a jar

I have a jar file that cannot be modified, but I want to use a different .class file in place of one of the members of the jar. How can I tell Java to use the external .class file when the code within the jar attempts to load it?

You could compile another jar file with replacement classes with exactly the same name and put it ahead of the jar file in the class path. For example, this is what the various slf4j bridge jars do to replace calls to log4j or Jakarta Commons Logging in library code with cognate slf4j code; one need not maintain two sets of logging systems and configurations that way.
If you want to override a java... class, you can use some of the command line options to change the boot class path. Look at the -Xbootclasspath options in http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html. Heed the warnings.
There is also the lib/endorsed directory if you need to upgrade a third-party jar that Sun uses. Oracle uses other organizations' XML and CORBA libraries; if they release a new version and you need to adopt it, you can.
You can use AspectJ to instrument the code and possibly replace it. An around advice can call the original code if it wants.
You could see if you really need to replace the original code. Some systems provide customization hooks.

You need to make sure the external .class file is loaded first. If a class is already loaded by the class loader then it will not be reloaded. If you are using an application server, then there are ways to configure the preferences for loading classes for class loader. But if you are using a standalone application then you may need to extend the class loader to load the files in the order you want to.

Public class outside a jar file containing multiple packages

So, I have a Java project containing several packages (like com.myapp.a , com.myapp.b, com.myapp.c) for better readability and I want to build a jar to use as a library in another project.
But I just want to expose only some classes and interfaces from this jar. The problem is that if I don't declare these classes public then they can't be seen inside the jar file between the packages (for example I have a class A in com.myapp.a package that is used in com.myapp.b package).
So how can I expose just what I want outside of the jar when I have multiple packages defined inside?

Currently Java does not address this problem directly.
OSGi adresses this problem by explicitly defining the exported package list.
Also hopefully this will be addressed with the Java 8 Modularity system as well.
So one option is to use OSGi, but this option does not work if the jar file is used directly rather than as an OSGi bundle.
Another option is to use code obfuscation (like Proguard), to obfuscate the packages you do not want to expose.

Eclipse "solved" this problem by making all classes available, but classes that were not intended to be used by clients were placed in packages whose name contains "internal". For example, that might mean that you have packages named "com.myapp.b" and "com.myapp.internal.b". It's made clear to users of the classes that internal classes are not guaranteed to be upwardly compatible or even present in later releases.

Is a Java package the equivalent of a .Net assembly?

I am a .Net developer starting Java development for Android and would like to know if it's correct to think of Java packages like .Net assemblies.

No.
The best comparison would be with a Java ARchive (Jar) file. Java uses packages to control the namespace, and is very similar to C#'s Namespaces.
Here is how I'd compare the environments
Java .Net
==== ====
Class Class
Package Namespace
Jar Assembly

No, I think a Java package would be more similar to a namespace
And an assembly would be more like a jar (I'm not so sure about this, as I'm much more familiar with Java than .Net... correct me if I'm wrong)

A Java package is like a namespace in .NET.
The equivalent to an assembly in Java is jar file.

A package in Java usually means just a namespaces for classes and interfaces, which in reality means a specific directory structure. Sometimes a .jar file is also referred to as a package. This is probably the closest you get to an assembly. A .jar file can also contain other data like images, or basically an kind of file since it is just a zip again with some specific content structure.
In any case: Usually when you read "package" in relation to "Java", some kind of namespaces (via folder structure, e.g.: com.mycompany.myproject) is meant. It doesn't help that some build tools refer to the process of building .jar file as "packaging" ;-)

Bear in mind that I'm far from a Java expert, but anyway, there it goes my take on this:
As pointed out by other answers, a package is not the equivalent to an Assembly. However, I don't fully agree with the idea of a .jar being the equivalent to an Assembly.
To me, a Java class (contained in a .class file) is closer to an Assembly than a .jar is. I'm saying this cause while the load unit for the CLR is the Assembly (which means all classes contained in that Assembly get loaded), the load unit for the JVM is a class (when the JVM needs a class, the ClassLoader does not load all the classes in the container jar, it just loads that specific needed class).
You can read more about java class loading here:
When does the JVM load classes?
and here:
http://www.lansa.com/support/notes/p0294.htm