jaxws-ri 3.x are vulnerable

[aagrawal3]

This is with reference to vulnerabilities present in 3.x version of https://mvnrepository.com/artifact/com.sun.xml.ws/jaxws-ri
Is there a plan to provide patch release on top of 3.0.2 to address the vulnerable packages? If yes, please help us with a timeline.

There is an option to switch to 4.x but these are only compatible with JDK11.

[arjantijms]

There is an option to switch to 4.x but these are only compatible with JDK11.

I think they are compatible with the current JDK 17 as well, so there's no need to avoid it?

[aagrawal3]

Perhaps yes. I haven't checked the compatibility with JDK17.
3.x is compatible with JDK8 while 4.x is not. Switching to 4.x would require upgrade in JDK version which is highly inconvenient.

[lukasj]

it's safe to use newer version of woodstox 6.5.1, which is an external dependency

[aagrawal3]

it's safe to use newer version of woodstox 6.5.1, which is an external dependency

We are doing it as a workaround. Excluding woodstox-core from jaxws-ri:3.0.2 and compiling our build higher version of woodstox-core. We were worried about breaking something (unintentionally). It would be nicer to have an official 3.x patch release (with updated woodstox-core) on maven central.

[arjantijms]

Switching to 4.x would require upgrade in JDK version which is highly inconvenient.

The trick, in general, is to not perceive upgrading JDK versions as inconvenient, and specifically not as highly inconvenient.

I know it's very general advice, but when you keep updating to every JDK version every time a new one comes out, you will often safe yourself a lot of trouble.

[aagrawal3]

I know it’s very general advice, but when you keep updating to every JDK version every time a new one comes out, you will often safe yourself a lot of trouble.

Yes, I agree it is a good practice. Unfortunately for us, it is not a feasible option in near future. We need to make sure that we are not breaking backward compatibility in our products until we provide users enough time to migrate. Since JDK8 is in support till 2030 and in use by a large codebase, moving away from JDK8 creates a very big technical debt. Thats why I used the term inconvenient.

[arjantijms]

I hear you, though one additionally thing to comment on:

moving away from JDK8 creates a very big technical debt.

Moving away from JDK8 solves a very big technical debt, since JDK8 (in your case, but many other cases I assume too), IS the technical debt. The fact that you for some reason or the other MUST stay on an ancient version and are prevented from updating to even an old version (let alone a recent version) is the very definition of technical debt ;)