Migrating Apps to Java 10

If you’re using Maven, set the compiler source/target version to 10 like the following:

<properties>
    <maven.compiler.source>10</maven.compiler.source>
    <maven.compiler.target>10</maven.compiler.target>
</properties>

You don’t need to expliclty add build plugin to configure the maven-compiler-plugin for jdk version.

if you’re coming from JDK 8, you might face this common exception.

Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) … 15 more

JAXB is moved into its own modulejava.xml.bind, you need to explicitly specify the dependencies.  You can use the command-line option --add-modules java.xml.bind to fix the issue.  Likewise, you might face ClassNotFound exception for javax/activation/DataSourceclass.

Since Java 9 deprecated the six Java EE API’s (JAXB is one of them), it’s better to add them as dependency (–add-modules probably will not work in Java 10).

<dependency>
    <groupId>javax.xml.bind</groupId>
    <artifactId>jaxb-api</artifactId>
    <version>2.2.8</version>
</dependency>
<dependency>
    <groupId>javax.activation</groupId>
    <artifactId>activation</artifactId>
    <version>1.1.1</version>
</dependency>

 

Refer: https://stackoverflow.com/questions/48204141/replacements-for-deprecated-jpms-modules-with-java-ee-apis/48204154#48204154

 

 

Maven Multi-Module Structure for Enterprise Java Projects (Best Practices)

Many times, I am trying to resolve several basic or complex Maven /  Java EE  project structure issues, on my day work. In order to provide the solutions,  I often end up experimenting with the project structure and it’s effectiveness.

It’s worth investing some time on application structure for big projects (especially Java EE). If not, it’s cannot be changed at the end.

It’s important to understand the application structure and the underlying build tools when you start working on a project.

Maven might be wise choice because it’s helps you build a better project quickly and effectively.

---

Maven helps in the following areas :

• Making the build process easy
• Providing a uniform build system
• Providing quality project information
• Providing guidelines for best practices development
• Allowing transparent migration to new features

Best practices (maven’s) for development

• Keeping your test source code in a separate, but parallel source tree
• Using test case naming conventions to locate and execute tests
• Have test cases setup their environment and don’t rely on customizing the build for test preparation.

Maven is designed to be flexible, but only to an extent. So, using maven in your project means, you need to reorganize your project (if not in good shape) and adhere to the maven’s conventions.

Random Quote :

“It is good to break conventions in your life and in your coding, but never with Maven.”

---

 Organizing Style

There are number of ways you can organize your project’s sub-modules.

• Single Bulk Module
• Module by Class Type
• Module by Functionality Area

1) All the modules can be grouped together as a single bulk project. But it’s not recommended anyway.

2) Module by class type : Project can be splitted into sub-projects/modules. And each module are used to group together all classes that comprise, but are not limited to, a layer in the project’s architecture. For example, a module could contain all classes that make up the project’s service or persistence layers or a module could contain all the model class (i.e., jpa or entity beans).

3) Modules by functionality area : Project’s sub-modules are organized by functional area (component based) i.e, vertical slice of the application including model beans, service layer, repositories etc..

Example for ‘Module by class type’:

• app-model
• app-utils
• app-repository
• app-services
• app-web
• app-ear

Example for ‘Module by functionality’:

• app-utils
• app-user
• app-audit
• app-auth
• app-integration
• app-web
• app-ear

It’s always necessary for each module to have it’s own unit tests.

Pros and Cons of Class Type :

+ Pretty maintainable in that you always known where to find stuff
+ Build order is very straight forward
– Circular dependencies
– Classes with totally different responsibilities are all mixed up together making it difficult to re-use functionality in other projects

Pros and Cons of Functionality Type :

+ Modules are highly decoupled
+ It’s far simpler to re-use a functional area of code in other projects
– Build order might be complex because of its dependencies

You may have noticed that both of them are not 100% perfect.

Also there are few modules which are repeated in both these types in the project. Because it’s always wise to keep the necessary things together i.e., creating a separate database module allows you to change your project’s database implementation fairly easily, which may make testing easier in some circumstances and likewise, having a separate web module allows you to re-skin your code easily.

At the end of the day, it really depends on the need of the project and it’s existing structure. And you can also mix-match both these types, if helps to solve your problem effectively.

Generating and Compiling Java Classes using Java Compiler API

Steps :

• Construct JavaFileObject from any source (i.e, here, from sourceCode String) and make it to iterable object
• Get the Java System Compiler
• Create a compiler task using Compiler.getTask(), (if required create the task with diagnostic collection to get compilation errors)
• Execute the Compiler Task (compile it).

Source Code :

import java.io.IOException;
import java.net.URI;
import java.util.Arrays;
import java.util.Locale;

import javax.tools.Diagnostic;
import javax.tools.DiagnosticCollector;
import javax.tools.JavaCompiler;
import javax.tools.JavaCompiler.CompilationTask;
import javax.tools.JavaFileObject;
import javax.tools.SimpleJavaFileObject;
import javax.tools.StandardJavaFileManager;
import javax.tools.ToolProvider;

public class CompileDynamicClasses {

static String sourceCode = "class DynamicClass{" + "public static void main (String args[]){"
+ "System.out.println (\"Hello, Dynamic Class!\");" + "}" + "}";

public static void main(String[] args) {

// Construct a JavaFileObject from source code
SimpleJavaFileObject fileObject = new DynamicJavaSourceCodeObject("DynamicClass",
sourceCode);