I know there isn't such a thing as conditional compilation as in C/C++ but I wonder if it is possible to produce a java program conditionally based on requirements. For example, there could be a public version which contains some features and private version which contains more features.
Am I right to believe that the only way to achieve this is with the help of something like plugins, i.e. the different features are found dynamically if they are present in the classpath?
I would have multiple modules for your application and multiple jars. I would have all the "private" features in a jar by itself and the rest in one or more jars.
Your application would then use the features which are available in the jars distributed (there are any number of ways to do this)
A library which you might find useful is Reflections This library allows you to find all the class which implement interface or have an annotation. So you could have a Feature interface and ask it to give you all the class which are Features
It is not unusual to separate a java package into using interfaces and implementations of those interfaces.
At package time you can filter out/in the implementations based upon conditions by using Ant or Maven. Like a different and more feature rich implementation for private versions.
Checking the classpath is ok, but a better bet is to use JNDI and let separate parts of your application find each other by registering them self into a shared JDNI context.
You can easily achieve that in a OOPS way.
Organize the features as following
Interface Feature
Class BaseFeature
Class BasicFeature1
Class BasicFeature2
Class SpecialFeature1
Class SpecialFeature2
Class PremiumFeature1
...
Then load the features centrally by having some sort of FeaturesManager
class FeatureManager {
String[] globalFeatureClasses = new String[]{--list all of them here, or load an external list etc--};
for each feature in globalFeaturesList {
if (class.forName(feature) != null) { // class is available
// this feature available
} else {
// this feature is not available
}
}
}
The features will implement other interfaces to provide behaviour etc.
You can then build distribution packages containing just the basic features, basic + advanced features or premium version containing all features including premium ones. Because the application will automatically detect available features, you can ship them later as well in jars which just need to be placed on classpath along others.
Ofcourse this design needs to be developed further to be effectively used, but you get the idea.
Related
I expected it's possible to use i.e. Guava-19 in myModuleA and guava-20 in myModuleB, since jigsaw modules have their own classpath.
Let's say myModuleA uses Iterators.emptyIterator(); - which is removed in guava-20 and myModuleB uses the new static method FluentIterable.of(); - which wasn't available in guava-19. Unfortunately, my test is negative. At compile-time, it looks fine. In contrast to runtime the result is a NoSuchMethodError. Means that, the class which was the first on the classloader decides which one fails.
The encapsulation with the underlying coupling? I found a reason for myself. It couldn't be supported because of transitive dependencies would have the same problem as before. If a guava class which has version conflicts occurred in the signature in ModuleA and ModuleB depends on it. Which class should be used?
But why all over the internet we can read "jigsaw - the module system stops the classpath hell"? We have now multiple smaller "similar-to-classpaths" with the same problems. It's more an uncertainty than a question.
Version Conflicts
First a correction: You say that modules have their own class path, which is not correct. The application's class path remains as it is. Parallel to it the module path was introduced but it essentially works in the same way. Particularly, all application classes are loaded by the same class loader (by default at least).
That there is only a single class loader for all application classes also explains why there can't be two versions of the same class: The entire class loading infrastructure is built on the assumption that a fully qualified class name suffices to identify a class with a class loader.
This also opens the path to the solution for multiple versions. Like before you can achieve that by using different class loaders. The module system native way to do that would be to create additional layers (each layer has its own loader).
Module Hell?
So does the module system replace class path hell with module hell? Well, multiple versions of the same library are still not possible without creating new class loaders, so this fundamental problem remains.
On the other hand, now you at least get an error at compile or launch due to split packages. This prevents the program from subtly misbehaving, which is not that bad, either.
Theoretically it is possible to use different versions of the same library within your application. The concept that enables this: layering!
When you study Jigsaw under the hood you find a whole section dedicated to this topic.
The idea is basically that you can further group modules using these layers. Layers are constructed at runtime; and they have their own classloader. Meaning: it should be absolutely possible to use modules in different versions within one application - they just need to go into different layers. And as shown - this kind of "multiple version support" is actively discussed by the people working on java/jigsaw. It is not an obscure feature - it is meant to support different module versions under one hood.
The only disclaimer at this point: unfortunately there are no "complete" source code examples out there (of which I know), thus I can only link to that Oracle presentation.
In other words: there is some sort of solution to this versioning problem on the horizon - but it will take more time until to make experiences in real world code with this new idea. And to be precise: you can have different layers that are isolated by different class loaders. There is no support that would allow you that "the same object" uses modV1 and modV2 at the same time. You can only have two objects, one using modV1 and the other modV2.
( German readers might want to have a look here - that publication contain another introduction to the topic of layers ).
Java 9 doesn't solve such problems. In a nutshell what was done in java 9 is to extend classic access modifiers (public, protected, package-private, private) to the jar levels.
Prior to java 9, if a module A depends on module B, then all public classes from B will be visible for A.
With Java 9, visibility could be configured, so it could be limited only to a subset of classes, each module could define which packages exports and which packages requires.
Most of those checks are done by the compiler.
From a run time perspective(classloader architecture), there is no big change, all application modules are loaded by the same classloader, so it's not possible to have the same class with different versions in the same jvm unless you use a modular framework like OSGI or manipulate classloaders by yourself.
As others have hinted, JPMS layers can help with that. You can use them just manually, but Layrry might be helpful to you, which is a fluent API and configuration-based launcher for running layered applications. It allows you to define the layer structure by means of configuration and it will fire up the layer graph for you. It also supports the dynamic addition/removal of layers at runtime.
Disclaimer: I'm the initial creator of Layrry
Is there a maven plugin that makes mvn verify of an aggregating project fail when its submodules or their transitive dependencies depend on things they oughtn't.
I'd like to be able to restrict uses of public APIs to express policies like
Only classes or packages on a whitelist can invoke this public constructor/method.
This public setter that was produced by a code generator should not be called -- it should really have been package-private.
Motivation & Caveats
I realize that there are ways to work around these requirements using reflection and deserialization. My end goal is to allow system-architects & tech-leads to set a policy like
All uses of security-critical APIs should be in modules reviewed by security. Contact them if you need the whitelist expanded.
These deprecated APIs are banned in favor of new ones. There's a whitelist for grandfathered code which should shrink over time.
The system architect treats trusts application developers but we want naive policy violations flagged with useful error messages, and we want developers who hack around the policy to not be able to plausibly deny that they did so.
Tricks like reflection and deserialization fall into that not-plausibly-deniable hacking.
This is kind of like some of the aims of Jigsaw, where a module (group of packages) can declare that its public interface is limited to just some packages, but jigsaw isn't widely available.
This question differs from "Make Java methods visible to only specific classes" because I'm not asking about ways to do this from within the Java language.
You can use checkstyle to perform such checks, for your use case you could use import control:
It seems that this doesn't support fully-qualified imports, based on following answers:
Checkstyle rule to limit interactions between root packages (with ImportControl?)
How to prevent fully qualified names in Java code
As the second answer suggest you could work around that by forbidding fully qualified imports by using another tool - PMD.
As for JSPs, these are usually compiled in the servlet container, nevertheless there is a way to pre-compile these as well, using maven plugin.
I'm trying to do something clever. I am creating a weather application in which we can replace the weather API with another weather API without affecting the code base. So I started with a Maven project with multiple modules.
I have a Base module that contains the Interface class and the Base class. The Interface class contains the calls to the APIs (all calls are similar, if not exact) and the Base class contains the properties to the APIs (again, all properties are similar, if not exact).
I have a module for each of the two weather APIs we are testing with plans to create more modules for new weather APIs as we grow the application.
Finally, I have created a Core module (includes main) to implement the specific module class for the weather API I want to test.
Now, I know the simplest way to do this would be to use a switch statement and enumeration. But I want to know if there is a more clever way to do this. Maybe using a Pattern? Any suggestions?
Here is a picture of the structure I have just described:
Here is the UML representation:
This is a learning process for me. I want to discover how a real Java Guru would implement the appropriate module and class based on a specified configuration.
Thank you for your suggestions.
I'm trying to do something clever. I am creating a weather application
in which we can replace the weather API with another weather API
without affecting the code base.
Without reading further down, this first statement makes me think about a plugin architecture design, but in the process of software design, decisions must not be rushed, the more you delay, the more information you have and a better informed decision can be made, for now is just an idea to keep in mind.
I have a Base module that contains the Interface class and the Base
class. The Interface class contains the calls to the APIs (all calls
are similar, if not exact) and the Base class contains the properties
to the APIs (again, all properties are similar, if not exact).
When different modules share behaviour/state, it is a good idea to refactor them and produce base abstract classes and interfaces, so you are on the right track, but, if there are differences, those shouldn't be refactored into the base module. The reason behind that is simple, maintainability. If you start adding if clauses or switches to deal with these differences, you just introduced coupling between modules, and you'll be always having to make changes in the base module, whenever you add/modify other modules, and this is not desirable at all.
This is reflected by the Open/Closed principle form the SOLID principles, which states that a class should be open for extension but closed for modifications.
So after you've refactored the common behaviour into the base modules, then each new API should extend the base module, as you did.
Finally, I have created a Core module (includes main) to implement the
specific module class for the weather API I want to test.
Now, I know the simplest way to do this would be to use a switch
statement and enumeration. But I want to know if there is a more
clever way to do this. Maybe using a Pattern? Any suggestions?
Indeed, making use of a switch, makes it work, but its not a clean design at all, for the same reason as before, when adding, modifying or removing modules, would require to modify this module aswell, and also this code can potentially break.
One possible solution, would be to delegate this responsability on a new component and make use of a creational design pattern like the Abstract Factory, which will provide a interface to instantiate components without specifying its classes.
As for the architecture, so far, the plugin architecture still makes sense, but what if the different modules extend the base contract adding more features? One option is to use the Facade pattern to adapt the module calls and provide an output that implements an interface that clients expect.
But then again, with the provided details, this is the solution I'd suggest, but the scenario should be studied carefully and in greater detail, in order to be able to assure that these are the right tools for the job, and commit to them.
In addition to Salvador Juan Martinez's answer...
To implement a plugin architecture Java's Jar File Specification provides support for service provider interfaces (SPI) and how they are looked up.
As of Java 1.6. you can use the ServiceLoader to lookup service providers. For Java 1.5. and less you must do it on your own or use a library. E.g. commons-discovery.
The usage is quiet simple. In your case put a META-INF/services/com.a2i.weatherbase.IWeather file in each plugin module.
In the Weather Forecast IO module the file should contain only one line
com.a2i.weatherforecastio.ForecastIO
The line must be the full quallified name of an IWeather implementation class.
Do the same for the other module and you can load the implementations via ServiceLoader.
ServiceLoader<IWeather> weatherServicesLoader = ServiceLoader.load(IWeather.class);
Iterator<IWeather> weatherServices = weatherServicesLoader.iterator();
Now it depends on your runtime classpath how many services will be found. Try to add and remove module jar archives from the classpath and run your application.
EDIT
I wrote a blog about a pluggable architecture with standard java. See http://www.link-intersystems.com/blog/2016/01/02/a-plug-in-architecture-implemented-with-java/
Source code is also available at https://github.com/link-intersystems/blog/tree/master/java-plugin-architecture
One solution is you have to define the common interface with all the identified common operations. The extensions/plugins need to implement that interface and have to provide the implementation to common operations.
You can use an abstract factory design pattern to hook up the exact implementation at runtime based on the input parameters.
Interfaces and abstract classes are always good in such scenarios, Thanks.
I have a gwt project that acts as a semantic engine for other projects.
I recently realized very very little of the code is specific to gwt. Its almost all pretty basic java. In fact, the only things specific to gwt is retrieving files.
So what I would like to do is to separate out the gwt completely so I can use the same basic code for other Java projects - such as Android or Processing apps.
So, "Semantic Core" project could be inherited by GWT,Android and Processing apps and I wont have to maintain separate versions for each.
To do this, however, I need some way for other projects to "give" the Semantic Core project their own file-handleing methods.
My current idea how to do this;
One method I thought how to do this was to have SemanticCore define a Interface for FileManager with a method like;
getFile(String,MyErrorHandler,MySuccessHandler)
And then have the class's for MyErrorHandler and MySuccessHandler defined also in the SemanticCore project, effectively being runnables that take a string as a parameter.
With this Interface defined, other projects (GWT,Android etc) have to define their own class that implements it
eg, GWTFileHandler implements FileManager
Then create a object of this class, and pass it to the SemanticCore;
SemanticCore.setFileManager(new GWTFileHandler());
The semantic core can then use it at its leisure to retrieve files in a way suitable for the platform its on.
Question;
Is this a good way to do it? It seems wrong to me I am creating a new object, when I'll only be using static methods from that class.
Alternatives?
I hope my description is clear. As this all has to be GWT compatible in the "SemanticCore" project, any use of reflections is ruled out.
Thanks,
The recommended approach IMO is to use Deferred Binding to pick the GWT compatible version of your FileHandler or other GWT specific implementations. Extract the common interface for all versions and in your GWT module file you point to correct GWT implementation.
You can then instantiate your specific implemenation using GWT.create :
MyInterface implemenation = GWT.create(MyInterface.class);
more in depth info on the gwtproject site.
Deferred Binding is a technique used by the GWT compiler to create and
select a specific implementation of a class based on a set of
parameters. In essence, deferred binding is the GWT answer to Java
reflection. It allows the GWT developer to produce several variations
of their applications custom to each browser environment and have only
one of them actually downloaded and executed in the browser.
Our software currently has many features. I've been asked to make a free trial version which consist of a lightweight version of the full software. Only a few specific features would be available in the trial. And since a jar file isn't encrypted, I was relunctant to release a full version with hardcoded restrictions. I want to be able to have 2 jars : 1 containing the basic features and 1 with the advanced features.
The features are in different menus. It would be nice it the code would try to load the jar with the extra features at start up and display a message (like : this feature is unvailable in the trial) when the non-paying user selects an advanced menu. On the other hand, a paying user with access to the advanced features jar wouldn't know the difference (I'm talking about the difference between now, 1 jar, and the new method, 2 separate jars).
Any tip on how to proceed ?
Any warning on common mistakes to avoid ?
Any better strategy than the separate jars ?
Edit : The best suggestion so far describes how to do my crippleware, but also warns me not to do a crippleware. So what do should I do ?
As you mentioned, you would probably have 2 jars:
1 with the basic features and stubs for the advanced features.
1 with the actual advanced features.
You could use a factory class with a config setting to determine whether to create the stub classes or the real classes - e.g. "FancyFeatureClass" or "FancyFeatureClassStub". "FancyFeatureClassStub" would be included in the "lite" distribution, but "FancyFeatureClass" would only be in the advanced features jar.
If they tried to change the config setting to create the real class without having the jar with the real classes, they would just end up getting class not found errors.
When upgrading, add advanced features jar to the classpath and change the config setting to tell the factory class to create the real classes instead of the stubs. Assuming your app could be split up that way, it should work fine.
As for common mistakes - I think you've already made one - probably not your fault though :)
"Crippleware" is a bad way to evaluate a product. Better to release a full featured version with an expiration or a nag screen than to release a crippled product. Not having those advanced features would probably make it difficult for someone to really evaluate the product.
Many technologies allow pluggable features (called plugins or addons usually).
The idea is that your core code (or framework) declares some interfaces (a well-thought API is ideal). Plugins can provide new implementations of an interface, and register it to the framework.
In its boot sequence, your framework will look (through some convention, in a file for example) if there are plugins, and give them a chance to execute their own boot sequence, consisting of the registration.
After the boot phase, a runtime example (for menus) : The framework looks it the registry where he stores the menus. The registry contains the menus the framework himself declared, plus any additionals provided by plugins... It displays all of them.
If you want specifically the behavior you asked for, I would implement this as follow :
menus available in all cases are declared and implemented in the framework
menus available only in the expanded edition are implemented twice :
in the framework, the implementation would simply display a message
(like : this feature is unvailable in the trial
in the plugin (= paid edition), it would override the previous implementation with the real one, that does the real job.
That way, you paying users have all normal functionality, with the trial version shows the warnings.
Many technologies exist to implement this, the best choice depends on what you already know/use/feel confortable with :
interface implementation is plain java, a string in the manifest of your plugin jar can mention the class to start.
Eclipse RCP has full implementation of menus that way (so you would have nothing to code, only configuration)
Spring is also pretty good when you use interfaces ...
Using a separate Jar which implements the paid for features (and a separate lite front end that displays a suitable message like 'not available' if it gets a ClassNotFoundException) would be the simplest way to do it.
There are many frameworks, up to and including Eclipse RCP for distributing UI applications in a modular form - but this will be overkill for your needs.
In fact, you don't even need two Jars, as long as your build process has the option to compile/package a sub-set of the Java classes in the Jar that you build as part of the distribution process. Just don't include the paid for features.