[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213817#comment-16213817
]
Tibor Digana commented on SUREFIRE-1424:
----------------------------------------
[~alanb]
[~AlanBateman]
Again, however I understand class loading issue, the Oracle did not do what
they planned to initially to do. They wanted JDK/JRE to simply extend by adding
jar modules. Current status in Java 9 is a precedence and anything can be
changed so that you would not tell that it would be Java in few years. Java was
built on fact that it was stable and not removed.
So Oracle should rely on initial idea that {{javax}} packages and
{{java.transaction}} are extensions and should go to separate jar file files
and User would download them from Oracle's {{downloads.html}} and/or
installation on Windows will interactively download it in to JRE 9 and
reconstruct what people rely on. The bad is that Oracle {{unplugged}} modules
and {{removed}} classes without giving ability to get it back to previous
status preventing from happened precedence.
Instead your arguments are {{because of EE classes}}, but it is not entirely
truth because {{Java Activation}} and {{JAXB}} are pure static utilities and
annotations which have nothing to do with container managed app. You can easily
run the utilities in {{public static void main()}}.
Oracle could make it so dynamic that application without {{module-info}} would
behave as before and all modules are on classpath as it was in Java 8, and
opposite in modular app is recognized. {{Now Surefire substitutes this behavior
and I think this is what Users want}}. But no, Oracle {{dictated}} something in
the world and we have the problem, we have to do your job! This is the problem.
> javax.transaction.TransactionManager not visible with Java9
> -----------------------------------------------------------
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
> Reporter: Stephane Nicoll
> Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
