Why are there breaking changes and silent critical behavior changes on the smallest version upgrades?

[ogrammer]

I just updated from 4.0.6 to 4.0.13 and now my MVC controller methods which use any of the @____Param annotations are broken and have changed behavior. Please don't do breaking changes when only changing the smallest version part, I think it is pretty unexpected.

This was a whole silent (from coding perspective) behavior and name change, now my @PathParam are broken, but even worse my @QueryParam("param-name") String paramName have (without any compilation errors) CHANGED behavior from that being the name to that now being a "default value"! I find this so, so unexpected. There is no indication, no error, no signature change or whatever. Why was an existing annotation field changed name and then SAME name was used for a new functionality?

Please, I need to ask why was the new functionality not named defaultValue which is much clearer and would not do a silent behavior change of all existing uses of these annotations which had a given string, in a version upgrade which just incremented the smallest part of the version.

As a user of this library I have no right to demand anything from you, but I ask you to be more careful of these kinds of changes and use the version string's parts to aid. Also in my opinion this change should be reverted ASAP and the "default value" functionality can be made using a new annotation field/method defaultValue=... or even a new @DefaultValue annotation really.

[jknack]

You're probably are right about the minor upgrade. It was something that I missed before releasing 4.0.0 but I wanted to included (just forget to do it at the right time).

The issue was opened on August: #3761. I could argue that you MUST read/check release notes too, after all that is why I took the time to write them down, but again you are probably right about the minor upgrade.

I'm not going to revert what I did, bc I consider it read lot better now and has better usability as I try to explained in: #3761. Revert the change for me means removing a new feature (previously requested by the community) while fixing this for you is just a search/replace session.

I'm happy to having you as user, but jooby is what it is.

[ogrammer]

Hi @jknack, thank you for your replying.

It is a matter of taste whether the unnamed / value-named annotation field should be used for the name or for a default value, of course.

My opinion is that to match for example:

• Jooby <4.0.7 (value() for name)
• Spring (@RequestParam has value()/name() for name, defaultValue() for default value)
• Micronaut (@QueryValue has value() for name, defaultValue() for default value)
• Helidon (@Http.QueryParam has value() for name)

Yes, the change is not massive to perform on my end and sure I do check release notes sometimes but not for 0.0.x versions which there is no reason to discuss, because you agree with me on the version number concern.

But the biggest issue here in my opinion is that the behavior of an existing @QueryParam completely changed with no indication. This means all old programs, all documentation, all examples, (for people who use AI "programming" ) all generated code, everything is now wrong. And I only noticed this because @PathParam lost its value() completely, so I got a compilation error for that. But QueryParam & friends like FormParam are now completely different while accepting any old source code as "valid".

Regarding reversion, my thought was mostly to revert value() to represent name, not to remove the default value feature but give it the name defaultValue which is consistent with other frameworks and more readable/understandable from glancing on source code but it is your choice what to name it.

And also just want to repeat that I do not make demands, that is not my right as an open source user. Thank you for jooby framework.

[agentgt]

@jknack I deeply respect you and Jooby but the @ogrammer is right that the changes have gotten out of hand to the point that I am not sure I can recommend the framework to most for serious long term applications in the mean time.

I think by making such changes in I assume an effort to make it easier to use? you are making it actually harder given today's AI usage. Like if I were to go ask ChatGPT or whatever to stub out some Jooby code it will likely get it wrong. This is a shame because Java is known for incredible backward compatibility. It is why it is often picked.

Also the last several releases notes have been "TODO" at first and I'm not sure github promulgates updates to release notes.

Finally perhaps for version "5" you just drop the extra decimal like Avaje projects so that there is not confusion that this project uses semver (even if semver is flawed it does have some merits). e.g. 5.0 and not 5.0.0.

p.s. I agree with @ogrammer that the default value annotation should be switched back.

[jknack]

You guys make a whole of literally nothing. There isn't company here, no one pay for using it, it just a guy who like to write code and created a very small community (which I'm proud of it).

I will say it again: I forgot to do it when releasing 4.0.0 and do it seven minor version later that's all.

From my experience, there is a very small set of user who where using the default value for putting a none java valid name, only those user are affected by the change. This is NOT Spring and I don't care what Spring or any other Spring-Like framework does. I always tried to keep annotation at minimum that is why @QueryParam("20") int page read better than any other crap like @QueryParam("page") @QueryDefaultValue("20") int page. I deal almost every week with breaking changes while updating dependencies in modules and I'm not complaining to each of them about it, just fix when I can and move on.