Java and its "patterns"
Java is champion in misrepresenting patterns, for better or for worse.
When Hibernate popularized Orms in Java, the JPA standard was created. Its adoption occurred gradually and to some extent the API is better done (I prefer) than the Hibernate API. But the default has never been and will never match frameworks, as it does not predict all situations and often you need to use extensions that are not portable.
When Joda-Time was being very successful, being the reference of how to implement routines involving date, time and all sorts of bugs related to calendars, Java 8 introduced the API java.time. Again, the scope is more limited and the adoption is being very gradual, after all most frameworks (even in JEE) still work with java.util.Date and many people don’t even know that there is a java.time.LocalDateTime.
When Spring dominated Ioc and other popular alternatives like Google Guice emerged, behold Java introduced CDI.
When functional programming in Java was done using Google Guava, some other specific library, here was created the API java.util.stream.
In all cases, adoption is extremely gradual. Many people don’t even know what’s new, others are used to some API and don’t migrate, they simply can’t migrate a complex system, see no advantage or are still prevented by some limitation of the API that has barely come out and already promises to have such and such features added in the next version.
Jigsaw vs. Osgi
Osgi is the standard as it has been around for over a decade. Unfortunately, it is also well complex and difficult to adopt. Also, for most applications, gains from using Osgi would be lower than the cost or simply it adds nothing of value.
On the other hand, it seems the modules as proposed by the Jigsaw project are simpler to understand, at least in the most common use, and the easiest implementation.
I won’t do a feature comparison because I’m not an expert on both, but overall it seems that Jigsaw has a more limited scope in its first version.
It is impossible to predict, but in this specific case I believe that the adoption of the use of modules will be more accelerated for the following reasons:
- Few people use Osgi
- Who uses Osgi is not always happy and does not need all the resources
- Modules are easier to understand
- Modules will be available on all platforms, while Osgi needs a framework and all components compatible with this framework
Who uses Osgi
I don’t have many examples, but Eclipse is the best and best known. All the IDE modules and their plugins are Osgi modules. This allows, most of the time, install and uninstall plugins at runtime.
Then you ask me: Why then does it ask to restart? Well, the reason is that things in practice almost never work as well as promised in theory (and this should generate great caution in all developers when reading articles talking about the wonders of modularity).
Another good example is the system I am currently working on, JIRA. Atlassian, which has been developing the product for more than a decade, has in its platform a plugin manager that is able to install and uninstall Osgi plugins dynamically (works better than Eclipse, to tell the truth). This manager is also used in other products like Confluence and Bamboo.
To facilitate the development of Osgi plugins for Atlassian products, the plugin manager and the SDK of Atlassian get rid of most of the complicated Osgi details. The extension points of your plugin are in an XML called atlassian-plugin.xml. Of course, XML is not the best thing in the world, but it is better to deal directly with the Osgi manifestos.
The use of plugins here is very intense and entire products like JIRA Portfolio, JIRA Software and JIRA Service Desk are built as plugins on top of JIRA Core.
About Intellij, I couldn’t find reliable sources, but I don’t think his modules are Osgi.
A module is a collection of codes and data that has a name. It’s not the same as package, JAR or WAR, but basically it’s like you take some classes and isolate them from the rest of the world.
The idea is that you can develop your application in one or more modules that explicitly make use of other modules, ie their dependencies. Java itself will be modularized.
Before that, there was really no division between the classes, except a manual control via Class Loaders. But in general, all classes of all Jars in a folder would be loaded in memory without any difference.
Packages have only a very basic modularity, which is the visibility default, but does not really isolate code or data, nor allows defining dependencies between packages.
Now, you can explicitly tell which part of the code depends on which and the benefits include:
- Identify in advance the lack of dependencies
- Allow different modules to explicitly implement the API of a particular module
- Avoid class conflicts with package names and names, even different versions of a library
- Avoid the Classloader Hell, where you have duplicates, conflicts, circular dependencies and other problems between classes loaded by different Class Loaders. In fact, the modules will also be implemented using Class Loaders, but at least it will be using a pattern and not the chaos that occurs today.
All this declaring a module like this example:
module com.foo.bar {
requires com.foo.baz;
exports com.foo.bar.alpha;
exports com.foo.bar.beta;
}
Like everything in Java, the module is compiled for a file .class and is at the root of the package.
It doesn’t even need an explanation, but basically requires is like a higher level of import and the exports is analogous to public.
For a module to implement an API of another module, there is the provides, as in following example:
module com.mysql.jdbc {
requires java.sql;
requires org.slf4j;
exports com.mysql.jdbc;
provides java.sql.Driver with com.mysql.jdbc.Driver;
}
This allows you to find SPI implementations more easily and efficiently.
And another module makes use of the implementation with uses, thus:
module java.sql {
requires public java.logging;
requires public java.xml;
exports java.sql;
exports javax.sql;
exports javax.transaction.xa;
uses java.sql.Driver;
}
To understand the operation without going into detail about the implementation, read further from the Quick Start (in English) is highly recommended.
Very interesting. I had never associated plugins with modules. I also didn’t know about the
provides. It seems very useful! Thank you very much for the clarification. :)– Pablo Almeida