4 ms·

> That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Ja

by cesarb 4y ago

> That's perfectly understandable, and users who are bothered by this are welcome to stop trusting the libraries that have chosen to do that to them. But the Java ecosystem is decentralised and Oracle has no control over third-party libraries. The libraries which did the namespace change are things like JAXB and JAX-RS and JAX-WS, which have been part of Java since Java 6. It's not some random third-party library, and Oracle did have control over them, until one day they decided they didn't want them anymore. As a part of Java, users did expect them to keep working (other than small changes like adding or removing a couple of methods, which became even less of a risk of breakage once Java 8 introduced default methods). The use of these libraries is pervasive all over the Java ecosystem, which leads to the complaint mentioned in the comment above: by first removing them on Java 11, and then forcing their new maintainer to rename the packages (instead of grandfathering them as an exception, or even better, providing an aliasing mechanism so that the renaming wouldn't break binary compatibility), Oracle broke some of the faith people had on Java's stability and backwards compatibility.

pron 4y ago
> and then forcing their new maintainer to rename the packages Their new maintainers were not forced to rename the package; they chose to do it. That the java/javax namespaces are governed by the JCP (which will turn 25 years old this year), is well-known to anyone familiar with Java's governance, and I can't see a reason why an exception would be warranted if the maintainers had the choice of staying in the JCP; they weren't compelled to leave -- they wanted to leave. Why would a standards body lend its seal of approval to someone who no longer wishes to work in that standards body? "I don't want to follow the rule" is not a good reason to grant an exception from a rule.
- redeeman 4y ago
  we should probably also not blow this "problem" out of proportion. If you actively maintain your things, you can probably handle swapping a few strings out that are garantueed to give buildtime errors. If you dont maintain your application and run on antiquated runtimes? well good news, it keeps totally unchanged... edit: okay, i guess if you do some funky stuff like reflection or having stuff in various config files, it might not give compiletime errors.. still though, recursive search and you'll find the spots in practically all cases
  - cesarb 4y ago
    It's more involved than just "swapping a few strings". You also need to make sure that all the libraries you depend on are on the same side of the divide, that is, you have to "swap a few strings" and update all your dependencies at the same time (and these updates could bring unrelated breaking changes with them). And some of these dependency changes might be unexpected; you might not expect a general-purpose logging library to depend on that, yet one popular logging library has to be upgraded from 1.3.x to 1.4.x when changing the namespace from javax to jakarta. It's even worse when your software can load plugins written by third parties, and your API allows these plugins to expose servlets or similar. You'd have to not only "swap a few strings" and update the dependencies in your software, but also make all these third parties update all plugins at the same time, with no chance of a gradual transition. It's a large amount of pain, for a completely unnecessary naming change.
    - pron 4y ago
      I guess Jakarta thought that leaving the JCP and changing the name was necessary, but that's something only they can explain.
    - redeeman 4y ago
      well sure, I have been through this myself, but I have exercised some restraint in my dependency chain, and so should everyone else. Dependencies can be wonderful, or they can be liabilities. nevertheless, I stand by my point, sure, you may have a little bit of a crappy time, but thats it. If you dont maintain your application? well you're every bit as fine as before. If you do maintain it? well then you had better be updating dependencies at some point, and sure, you might have chosen a dependency that breaks compat and such stuff, but then you have this problem ANYWAY, and are probably running old code with at best just irellevant bugs, but more likely various security implications (as the dependencies are probably not trivial, right? and those bugs might be like the insanity going on in a certain popular logging library...)

by cesarb 4y ago

pron 4y ago

> and then forcing their new maintainer to rename the packages Their new maintainers were not forced to rename the package; they chose to do it. That the java/javax namespaces are governed by the JCP (which will turn 25 years old this year), is well-known to anyone familiar with Java's governance, and I can't see a reason why an exception would be warranted if the maintainers had the choice of staying in the JCP; they weren't compelled to leave -- they wanted to leave. Why would a standards body lend its seal of approval to someone who no longer wishes to work in that standards body? "I don't want to follow the rule" is not a good reason to grant an exception from a rule.

redeeman 4y ago
we should probably also not blow this "problem" out of proportion. If you actively maintain your things, you can probably handle swapping a few strings out that are garantueed to give buildtime errors. If you dont maintain your application and run on antiquated runtimes? well good news, it keeps totally unchanged... edit: okay, i guess if you do some funky stuff like reflection or having stuff in various config files, it might not give compiletime errors.. still though, recursive search and you'll find the spots in practically all cases
- cesarb 4y ago
  It's more involved than just "swapping a few strings". You also need to make sure that all the libraries you depend on are on the same side of the divide, that is, you have to "swap a few strings" and update all your dependencies at the same time (and these updates could bring unrelated breaking changes with them). And some of these dependency changes might be unexpected; you might not expect a general-purpose logging library to depend on that, yet one popular logging library has to be upgraded from 1.3.x to 1.4.x when changing the namespace from javax to jakarta. It's even worse when your software can load plugins written by third parties, and your API allows these plugins to expose servlets or similar. You'd have to not only "swap a few strings" and update the dependencies in your software, but also make all these third parties update all plugins at the same time, with no chance of a gradual transition. It's a large amount of pain, for a completely unnecessary naming change.
  - pron 4y ago
    I guess Jakarta thought that leaving the JCP and changing the name was necessary, but that's something only they can explain.
  - redeeman 4y ago
    well sure, I have been through this myself, but I have exercised some restraint in my dependency chain, and so should everyone else. Dependencies can be wonderful, or they can be liabilities. nevertheless, I stand by my point, sure, you may have a little bit of a crappy time, but thats it. If you dont maintain your application? well you're every bit as fine as before. If you do maintain it? well then you had better be updating dependencies at some point, and sure, you might have chosen a dependency that breaks compat and such stuff, but then you have this problem ANYWAY, and are probably running old code with at best just irellevant bugs, but more likely various security implications (as the dependencies are probably not trivial, right? and those bugs might be like the insanity going on in a certain popular logging library...)