Let me hazard at an answer, though much of it may be assumptions/splitting hairs/ranting, etc.
Are they the same thing? Well, yes and no
From this JavaWorld article about "Modularity in Java 9":
Packages as a modular solution
Packages attempt to add a level of abstraction to the Java programming landscape. They provide facilities for unique coding namespaces and configuration contexts. Sadly, though, package conventions are easily circumvented, frequently leading to an environment of dangerous compile-time couplings.
As @user2418306 (OP) hinted, "modules are packages done right". Modules and packages in Java (as of Java 9, obviously) are (as OP asks) semantically the same thing. That is, they are collections of pre-compiled JVM bytecode, with other metadata - essentially, they are libraries.
Well what's the difference?
However, the difference is in the metadata inside each of them. Java
package manifests, or JAR manifests, aren't often maintained by library developers, nor do they provide any sure contract as to what the JAR/package provides. As explained here (JavaWorld article again):
Aren't JAR files modular enough?
JAR files and the deployment environment in which they operate greatly improve on the many legacy deployment conventions otherwise available. But JAR files have no intrinsic uniqueness, apart from a rarely used version number, which is hidden in a .jar manifest. The JAR file and the optional manifest are not used as modularity conventions within the Java runtime environment. So the package names of classes in the file and their participation in a classpath are the only parts of the JAR structure that lend modularity to the runtime environment.
A rant about other languages/environments, etc
Another area discussed in that article are systems such as Maven, which manage dependencies for you as part of the build process. From this page on the Apache Maven site:
Maven encourages the use of a central repository of JARs and other dependencies. Maven comes with a mechanism that your project's clients can use to download any JARs required for building your project from a central JAR repository much like Perl's CPAN. This allows users of Maven to reuse JARs across projects and encourages communication between projects to ensure that backward compatibility issues are dealt with.
Now to talk about the future as if I've been there
As that page mentioned, other languages (such as Perl), have package repositories (like CPAN). This is an increasing trend (I say because I feel like it, with no emphatic proof whatsoever), over the last ~decade or so. Tools such as Ruby's gems, Python's PyPi, and the Node package manager (
npm) build upon this to provide a consistent way of configuring an environment (either development, build, test, or runtime, etc) with the right stuff (packages, modules, gems, gizmo's, etc). An idea (I feel) was "borrowed" from Linux® distribution systems such as Debian's apt, RedHat's
rpm, etc. (Although, obviously, has evolved at least one generation, and made these things all nicer.)
Java modules, although they don't necessarily add anything you cannot do already, make tooling for dependencies/package management and automated build environments all MUCH easier. Whether that makes modules "better", I decline to say. :P