Java 9 will have modules in addition to packages. Usually languages have one or the other. And most programmers perceive two terms as synonyms. Modules are built on top of packages, treating them as primitives. Composite pattern suggests to treat primitives and composites uniformly. Otherwise bad things will happen. For example, look at project Valhalla, where they try to retrofit common supertype for primitive (value) and reference types.

Are modules and packages represent semantically separate notions? Meaning it is sensible to have both for any language (separation of concerns). Or Java has to have both as a tribute to backward compatibility?

Why introduce new concept instead of augmenting existing one?


JSR 376: "Java platform module system" implemented within project Jigsaw.

According to SOTMS

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.

JLS carefully avoids defining what is a package. From Wikipedia:

A Java package is a technique for organizing Java classes into namespaces similar to the modules of Modula, providing modular programming in Java.

I know that quoting Wikipedia is a bad practice, but it reflects common understanding. From entry on modular programming:

The term package is sometimes used instead of module (as in Dart, Go, or Java). In other implementations, this is a distinct concept; in Python a package is a collection of modules, while in the upcoming Java 9 the introduction of the new module concept (a collection of packages with enhanced access control) is planned.

  • 3
    I think you're asking a lot of questions all together here? 1) Are modules and packages the same semantic idea? 2) (if not 1), are jigsaw-style modules just a technical improvement over packages? 3) (if not 1 and if 2), is Java simply (or seemingly) keeping both concepts for backward compatibility. Some of these questions are answerable, some are primarily opinion-oriented. I think an edit simplifying the clarification(s) sought is in order here. – Tersosauros Feb 28 '16 at 6:56
  • 1
    @Tersosauros You've classified "some" questions as off-topic, but did not label which one is which. I see it as only one question (1). Other will be resolved automatically. Backward compatibility for java is not a question. So either java introduced modules to patch packages design flaws or two notions are truly separate concerns. And confusion is due to bad naming. – user2418306 Feb 28 '16 at 11:42
  • 1
    I want to make question more clear. But I need to understand which part of it you think is unanswerable. When I think there is only one part. – user2418306 Feb 28 '16 at 11:44
  • Ahh, I understand the confusion. I think question #1 is answerable (that answer being "Yes, but no" - which is where #3 comes in). I agree about #3, obviously Java aren't about to change what a language keyword like package is/does/means, nor are they going to change to (let's face it, pretty horrible) classpath system(s) in the JRE. Question #2 I feel is primarily opinion-oriented (it's answerable, but my answer and someone else's may differ and neither of us would necessarily be wrong). – Tersosauros Feb 28 '16 at 12:05
  • 1
    Try asking a clear question up front, then supply the supporting material. – Jay Elston Mar 2 '16 at 0:18

The concept of a module is different from the instantiation of that concept.

Java has always had modules. A method is a module, so is a class and so is a package. A module is a unit of organisation in which internal details are hidden, and that communicates with other modules via agreed contracts. For example, a method is a module because it has hidden internals (the code and local variables) and a contract (the parameters and return type). Modules can be composed out of lower-level modules, e.g. classes contain methods.

What's missing in core Java (pre-9) is a deployable module. All the above kinds of module are not deployable units that can be copied around. Java does have a deployable artifact called a JAR file, but these are not modules because they have no encapsulation or contract: at runtime JAR files disappear, all merging together into a single "classpath".

OSGi addressed the lack of deployable modules in 1998 with the concept of a "bundle". These are physically JAR files and they contain packages, but OSGi defines additional metadata along with a runtime system to support encapsulation and contracts at that level.

Java 9 addresses the lack of deployable modules in a similar way to OSGi. Arguably this was completely unnecessary because OSGi exists and works, but that's a whole different discussion...

Unfortunately Java 9 muddies the waters by naming the new module concept just a "module". This does not mean that methods, classes and packages stop being modules! A J9 "module" is just another instantiation of the module concept. Like OSGi bundles, J9 modules are made out of packages and they are physical artifacts (usually JAR files again) that can be copied around. The runtime system understands and reifies them.

Summary: yes J9 modules and packages are semantically separate notions. Obviously Java has to retain its existing package concept for backwards compatibility. Note that the word "package" is used quite differently in Java than in other languages or in package management systems like RPM. The new J9 modules (and OSGi bundles) are much more like packages in RPM than Java packages ever were.

  • Package don't meet your meet your definition of a module. Due to weak encapsulation and lack of means to aggregate other packages and refine their visibility. Classes can contain nested classes or fields. Methods can contain closures or call other methods. Packages cannot "communicate" with other packages. – user2418306 Mar 24 '16 at 8:13
  • I disagree. Packages have information hiding (default access types, methods and fields, aka package-private). Packages certainly "communicate" because code within a package can invoke code in other packages. This is done against a contract, namely the public types and methods of the other package. – Neil Bartlett Mar 24 '16 at 9:49
  • Note that the ability to aggregate modular artifacts at the same level (e.g. methods containing closures, classes containing nested classes) does NOT form a part of my definition of a module. If you consider this to be a necessary part of the module definition, then "Java 9 modules" are not modules either. – Neil Bartlett Mar 24 '16 at 9:51
  • I don't deny that packages have information hiding. I said that it's not sufficient. import can couple packages. But there is no way to structure packages as first class citizens. Those shortcomings (and limitations of OSGi) are described in JSR 376. – user2418306 Mar 24 '16 at 10:45
  • Can you elaborate why Java 9 modules are not modules either? – user2418306 Mar 24 '16 at 10:48

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:

Dependency management:

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

  • 1
    Article is only 1 year old and yet already obsolete. It dwells how versioning is fundamental characteristic of a module. Jigsaw modules won't have version info. Nothing in realm of dependency managment will change for the end user. For build tools things will get much harder in fact. As they need to suport parallel realities of classpath and modulepath. And jump through hoops to support unit testing. Premise that two concepts are equivalent because they represent collection of things plus metadata is too bold for me accept. Plus middleway you've suddenly substituted jar for package. – user2418306 Feb 28 '16 at 21:07
  • I didn't say "two concepts are equivalent", I said they are "semantically the same thing" - which is what you asked about. Also, you've edited the question since I answered to specifically mention JSR-376, as oppose to jigsaw which is what was said earlier :-/ – Tersosauros Feb 29 '16 at 2:59
  • Jigsaw encompasses (implements) JSR-376. Question still links to both, so no harm was done. Dictionary defines equivalence as the quality or state of having the same meaning. And semantically - with regard to meaning. I'm sorry but you're being pedantic about wrong details here. You've said they are equivalent. But you did not provide any reasoning. Instead you refer to the article which exlaines how packages and jars fail to be modules. But upcoming modules fail to be modules from the article too. Claiming equivalence and then providing difference between the 2 (3) is self contradictory. – user2418306 Feb 29 '16 at 9:48
  • Answer to the question cannot be yes and no. Either two concepts semantically equivalent or not. Please don't lobotomize my comments and return to the original question. Does a language need both concepts or this is java legacy specific issue? If you need clarifications I'm glad to help. – user2418306 Feb 29 '16 at 10:01

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.