0

My Gradle WSLD Java source generation plugin still uses com.sun.xml.ws:jaxws-tools of v2.3.2-1. There is v4.0.0 too:

https://mvnrepository.com/artifact/com.sun.xml.ws/jaxws-tools

but there is no jaxws-tools artifact under new Jakarta umbrella:

https://mvnrepository.com/artifact/jakarta.xml.ws

I'm highly confused: Why transition to Jakarta / Eclipse led only to partial Maven coordinates changes, most of the EE XML/SOAP stuff still under the old com.sun.xml...

Seems that parent POM leads to:

mvn dependency:copy -Dartifact=com.sun.xml.ws:project:4.0.0:pom -DoutputDirectory=libs


<scm>
  <connection>scm:git:git@github.com:eclipse-ee4j/metro-jax-ws.git</connection>
  <developerConnection>scm:git:git@github.com:eclipse-ee4j/metro-jax-ws.git</developerConnection>
  <url>https://github.com/eclipse-ee4j/metro-jax-ws</url>
  <tag>HEAD</tag>
</scm>
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
gavenkoa
  • 45,285
  • 19
  • 251
  • 303

1 Answers1

1

jakarta.* package represents the interface (API).

com.sun.* package represents the implementation.

This way, when you import/reference only the classes of the jakarta.* package in your program, then you can effortlessly change the implementation without rewriting your program. E.g. switching the JAX-WS implementation from Eclipse Metro to Apache CXF which in turn uses org.apache.* instead of com.sun.*.

This is the Abstract Factory Pattern and it's essentially the same concept as how JDBC drivers work.

Might you find your program using implementation-specific classes directly, i.e. your source code has compile time dependencies on com.sun.*, then your program is tight-coupled and unportable across other servers/impls and you might want to fix this tech debt by looking for proper replacements in the jakarta.* namespace.

See also:

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555