Develop Reference

Camel in Action published by Manning

I'm learning Camel by the book of Claus Ibsen and I would like to have your advise on this.
I have got the book and the code from the side.
In chapter1 it says run:
C:\camelinaction-master\chapter1\file-copy>mvn compile exec:java -Dexec.mainClass=camelinaction.FileCopierWithCamel
The error it produces is:
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1.1:java (default-cli) on project chapter1-file-copy: An exception occured while executing the Java class. null: InvocationTargetException: javax/xml/bind/annotation/XmlRootElement: javax.xml.bind.annotation.XmlRootElement -> [Help 1]
I'using
java 15.01 and
mavem 3.3.5
Since I got this issue at the very beginning of the book I thought before I start debugging the issue perhaps it is good to ask if the code from the book is still working or is it to old and not maintained? If that is not the case it is worth solving the issue otherwise is there newer learning material that you have used and good experience with?

The JAXB APIs are considered to be Java EE APIs and therefore are no longer contained on the default classpath in Java SE 9. In Java 11, they are completely removed from the JDK. (Quote from Java: How to resolve java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException )
Try using Java 8.

UPDATE: As Claus (one of the authors of the book) pointed out, there are branches for Camel 3.x versions in the book source code repository:
https://github.com/camelinaction/camelinaction2/tree/camel37
3.x supports Java LTS versions: 8, 11, or 14, but does not officially support the non LTS Java versions.
As Kristof advised, short answer is use Java 8.
In addition to that, the Camel in Action book (2nd ed.) uses Camel 2.x and it supports only Java 8 so otherwise the sample code doesn't work.
If you really want to use later Java versions (11 and higher) you should use Camel 3.x (the latest version as of now is 3.7.1). Since it's a major upgrade you'd need to go through some migration work in order to make the sample code run with Camel 3.x. See the following official migration/upgrade guides for what to do:
https://camel.apache.org/manual/latest/camel-3-migration-guide.html
https://camel.apache.org/manual/latest/camel-3x-upgrade-guide.html

Thank you Claus Ibsen.
With the link to the new source files I'm able to continue my study.
https://github.com/camelinaction/camelinaction2/tree/camel37

How can I resolve "sun.security.x509" is not visible when migrating from 1.8 to openJDK11?

I am migrating Java 1.8 to OpenJDK 11. Getting some dependency errors.
"sun.security.x509" is not visible.
BASE64Encoder error
How can I resolve these? I am using Apache Ant for build.

We can't tell you how to address the first problem since you haven't shown us the code where you are using classes in the sun.security.x509 package. A possible workaround might be to use --add-exports and/or --add-opens as described in this blog post:
All You Need To Know For Migrating To Java 11
However, that work-around is liable to stop working in the future. The solution would be to find a way to avoid depending on those classes.
The second problem can be used by rewriting your code to use the java.util.Base64 class (javadoc) that was introduced in Java 8.
I am using Apache Ant for build.
That is not directly relevant. The root cause of the problem is in the code you are building not the build tool you are using.

Migrating Java 8 project to Java 11

We have a repository built using Java 8. There are multiple rest services within the repository. We want to migrate to Java 11 and trying to figure out the best way of doing this. We are considering doing module by module. For example changing one service over to Java 11 while the remaining are still Java 8. We are unsure if Maven supports this?

Disclaimer: This is not an answer but just a partial report of my recent experience. Feel free to flag this answer if you feel that it doesn't meet the SO standards.
Does Maven supports this?
Yes, use the compiler plugin 3.8.0/3.8.1
However this migration requires addition care.
Recently we did something like this by migrating from ORACLE JDK 8 to OPENJDK 11. As we have houndreds of repositories with different missions, we faced all kind of problems. Just to cite some that I got here in my e-mail box tagged as [jdk11_migration]:
It is quite obvious but I'd like to highlight that in order to migrate from java 8 to 11 we have to meet the requirements from java 9 and 10 as well
Some maven plugins like cobertura do not support Java 11 and I guess they will never support it. In some cases, these plugins have reached the abandoned life cycle stage. The solution was looking for alternatives in a case to case manner. For example, we replaced cobertura by Jacoco.
rt.jar and tools.jar have been removed! Everything you have explicity refered from them will probably break.
some classes which we shouldn't use in java 9 or less now in java 11 no longer exist. I'm talking about to access classes in packages like sun.*, sun.misc etc. The solution is to look for a one-to-one replacement or refactor the code to avoid the usage.
Reflection usually is the last bullet to use and, for these cases, in java 9 and above we geta warning messages like:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by ...
WARNING: Please consider reporting this to the maintainers of ...
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Although it is not exactly a solution, there is a flag to get rid of this warning --illegal-access=permit . This is particulary important when using surefire maven plugin.
Java 9 introduced the module system then "now" we have the phenomena of clash of packages. For example, messages like "The package org.w3c.dom is accessible from more than one module: , java.xml" . The solution is to find the source of reduntant inclusion (notably duplicated maven dependences or dependences of dependences) and remove it.
Althought it wasn't a problem for us, I just noted that your repository consists in REST components in majority. Probable you will face ClassNotFound issues regarding some packages like javax.xml.bind which were basically dropped out of java standard edition. You can fix it by including they explictly in your pom.xml.
Luckly you may find good questions & anwswers for each issue you will find in your migration here in SO or over internet. There are some migration guides in the wild which are good start points. Specific issues, like obfuscation and IDE integration, can take a little bit of time, but, at least in my experience, this migration was painless than I have supposed.

My suggestion is to upgrade the entire project. Try to have some Java8 and some Java11 modules can be very difficult. As you already know, starting from Java9 module appears. The answer is very generic, so it's difficult to give a detailed response. I suppose:
Your project is managed with maven
You have many artefacts (jar)
You are using some library or framework (who said Spring?)
You are using a Source Version Control (Git or Subversion for example)
You have a multi-module project
The code you wrote works on Java8 and on Java11 platform
My suggested plan:
Create a branch on your SVC for Java11 project's version and start to work on it.
Create a parent module for common definitions
Upgrade maven plugin and all your library to the latest version. For Maven compiler set the Java11 target (the Java11 is supported only by the latest version of Maven Compiler Plugin).
For each module define the exported packages (and specify which packages are required)
If there are many modules, start with only a few of them and then include the remains.
If it can help you, let have a look at this simple project on github (It target Java11 and it's a multi-module Maven project).
Hope it helps.

Ekstasi error bundling a package throwing JVM error

I am trying to build a Cytoscape app using maven, and I am using EKZTAZI 5.0.1 . When I use Maven Package, it throws the following error :
Execution ekstazi of goal org.ekstazi:ekstazi-maven-plugin:5.0.1:select failed: Running with Java 9 requires -Djvm.options=jdk.attach.allowAttachSelf=true
I have tried searching on how to pass this option online but I am unsure on how to. Any help will be appreciated.

There is currently no Java 9 support available for the public release of Cytoscape, which is likely what is causing your issue.
The next major version release is in development and has Java 9 support (check the Cytoscape GitHub if you're interested in using this: https://github.com/cytoscape/cytoscape)

Why do I get this compilation warning in Netbeans?

I am working on a Java-EE project involving Glassfish 3.1.2.2 and the client component is running with Java 7 Update 21. The Swing-based client was formerly based on Java 6 Update 38 until we decided to migrate to the new Java 7 Update 21.
I get the following compilation warning in Netbeans 7.3:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source '1.7'
At this point, the compilation process hangs for about 1 minute.
Btw, we still have the javaee-api-6.0.jar referenced that is provided by the Netbeans platform (I think there's no javaee-api-7.0.jar available yet?)
Does somebody know the reason for this warning and how I can get rid of it ?
Any help highly appreciated - many thanks in advance.

It seems (I think) that the eclipseLink annotation processing for JPA is up-to-date until Java 6. You could make a Java 6 library with the JPA sources, and only there use eclipseLink annotation processing. Having a library never hurts, and later you may upgrade to Java 7 independantly.
Can't image using much Java 7 functionality in the JPA sources.

Java version 7 has more features as compared to Java 6. In netbeans, go to Tools-->Java Platforms and check whether your netbeans ponts to the latest version of JAVA.

I thing You have added unwanted library,first, you have to check your library of your project and delete the unwanted files there. On the other hand, you can retry it by copying only the JFrames and Main Classes into a new Project. But One thing, You have to replace the name of package as the new name.