Fixing error “The package org.xml.sax is accessible from more than one module: , java.xml”

Leave a reply

After upgrading a dependency on Apache POI from version 4.2.0 to 5.0, my Java 11 Spring Boot application failed to start with error “The package org.xml.sax is accessible from more than one module: , java.xml”.

This issue is not specific to Apache POI, it was introduced with JAVA 9 modules. Here, the problem comes from the java.xml module, which is included by default with JAVA 11, and conflicts with the one included with Apache POI for compatibility with JAVA <= 8.

Thie first thing you need to do in such a cas, is to identify where the conflict comes from, which is done using Maven Dependency tree command: 

mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Bartleby 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:3.1.2:tree (default-cli) @ bartleby ---
[INFO] com.riousset.bartleby:bartleby:war:0.0.1-SNAPSHOT
[INFO] +- org.springframework.boot:spring-boot-starter-data-jpa:jar:2.4.4:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-aop:jar:2.4.4:compile
[INFO] |  |  \- org.aspectj:aspectjweaver:jar:1.9.6:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-jdbc:jar:2.4.4:compile
[INFO] |  |  +- com.zaxxer:HikariCP:jar:3.4.5:compile
[INFO] |  |  \- org.springframework:spring-jdbc:jar:5.3.5:compile
[INFO] |  +- jakarta.transaction:jakarta.transaction-api:jar:1.3.3:compile
[INFO] |  +- jakarta.persistence:jakarta.persistence-api:jar:2.2.3:compile
[INFO] |  +- org.hibernate:hibernate-core:jar:5.4.29.Final:compile
....

Once identified the problematic dependency, you have 3 options to fix the conflict :
A. upgrade the libraries to a Java 11 compatible version without transitive dependencies,
B. exclude the conflict explicitly in POM dependencyManagement, or
C. avoid the conflict by only importing the classes needed and do not use wildcards (*) in import statements.

I chose the 3 option, and excluded the xml-apis dependency for poi-ooxml :

		<!-- https://mvnrepository.com/artifact/org.apache.poi/poi-ooxml -->
		<dependency>
			<groupId>org.apache.poi</groupId>
			<artifactId>poi-ooxml</artifactId>
			<version>5.0.0</version>
			<exclusions>
				<exclusion>
					<artifactId>xml-apis</artifactId>
					<groupId>xml-apis</groupId>
				</exclusion>
			</exclusions>
		</dependency>

mvn dependency:tree

Measuring JUnit CodeCoverage with Jacoco

Leave a reply

Once you start working with unit tests, and that you understand how to use and write them, it’s impossible to go back. They help you decouple code, gain confidence in the behaviour you’re implementing, makes you faster by avoiding to start, and restart, a whole application.

Yet, one thing I never used up to now was code coverage. I just never took the time to dig the topic, even though that’s clearly useful. It helps maintain a team effort to ensure all new code is tested, and it gives you an idea of the risk you’re taking when chaging a line of code. Because the number of tests doesn’t give you any idea about the coverage, they may be focused on one part of the application only, or at the opposite cover a little bit every part, but not completely.

It appeared that adding code coverage measurement to a maven Java project using JUnit was as simple as adding the JaCoCo plugin to the POM file. As usual, Baeldung is your reference, but in brief : 

            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.2</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

The JaCoCo plugin will output a jacoco.exec binary file, which can be consumed by some third party tools, like SonarQube. However, you can generate a more human friendly report using the repot goal :

mvn clean jacoco:prepare-agent install jacoco:report

You’ll then have a target\site\jacoco\index.html report detailing your code coverage :

Using interfaces in Typescript and Angular

Leave a reply

One of TypeScript’s core principles is that type-checking focuses on the shape that values have. Basically, as long as an object has the properties required by a function, it’s good to go. It can be a pain in the ass, especially when you come from strictly typed languages.

Introduced in Typescript 2.1, interfaces are your solution to work this issue around. They allow you to define contracts, and to enforce that these contracts are respected. They allow static type checking, and so your IDE can detect errors at compile time, while preserving runtime efficiency since interfaces do not appear in the generated javascript code !

Hence, interfaces solve a common typescript issue when working with objects which have been dynamically casted, and hence may have all properties from the target class, but no the methods. This is a frequent with JSON objects returned by an HTTP call to a REST API and then casted to a different type. Working with interfaces will help you avoid the “method undefined” error.

you define you interface similarly to how you define a class

export interface Book {
  name: string;
  description?: string;
}

Notice the ‘?’ suffix, which indicates that these properties are not mandatory. This will help with initialization of instances of your interface without requiring to initialize all properties :

const myBook: Book = { name: "My new book" };

So, once we know why we must use interfaces, next question is when we should rather use classes. The Mozilla Developper Network gives a quite straightforward answer :

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript’s existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.

How to run a MariaDB local docker container ?

Leave a reply

I’m developing on Windows software solutions targeting debian servers, and relying on MariaDB databases, whose versions vary a lot.

Docker is great to reproduce a production environment, and eliminate common issues related to versioning, or OS specificities (yes, I’m think about case sensitivity in table names on linux, which doesn’t occur on Windows).

So, here is a simple docker command to start a mariadb 10.3 container available on local port 3310 (as explained in details by the MariaDB team here):

docker run -p 3310:3306 --name mariadb -e MYSQL_ROOT_PASSWORD=myRootPassword -d mariadb/server:10.3