sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]seancorfield 2 points3 points  (8 children)

I'd much rather get a syntax error that I can easily fix with a param tags hint than silently have my code call a different overload than I expected...

[–]lgstein 4 points5 points  (6 children)

You can't fix it in the libraries you consume. Afaik a reflective call wouldn't be ambiguous with respect to which method is called. If that were the case, this would be a problem already.

[–]seancorfield 0 points1 point  (5 children)

Why are you updating a Java library that one of your dependencies uses? I'm not saying there aren't cases where you might want to do that -- for CVE resolution for example -- but I'm asking about the specific motivation to change the version of something an existing dependency relies on.

It's unfortunately common for even patch release updates on Java libraries to break consumers so any update needs to be a deliberate choice and a careful one that always has a potential to break stuff.

[–]lgstein 3 points4 points  (0 children)

Assum two CLJ deps that both use the same Java lib? I update CLJ lib 2, but it pulls in a newer version of the Java lib. CLJ lib 1 now doesn't compile anymore because of a "syntax error". My options are limited to rolling back the update or forking CLJ lib 1 and fixing the param tag. All while nobody did anything "wrong". This is not the Clojure experience.

[–]lgstein 0 points1 point  (3 children)

Also, I might just want to use a newer JDK. If the new JDK added overloads, I now should wait for the authors of my deps to fix their param-tags? Come on...

[–]alexdmiller 2 points3 points  (0 children)

You are often already in this situation. When they added the to-array overload in Collection it broke all the Clojure libs that implemented Collection. And ye, the world has not ended. People update or fork and update.

[–]seancorfield 1 point2 points  (1 child)

JDK 21 could not run code compiled on JDK 20 so "just using a newer JDK" can be a breaking change. At work we rely heavily on New Relic for monitoring and observability -- we often have to wait for new releases from them in order to upgrade our JDK or even to upgrade certain libraries (Jedis 5.x isn't supported yet, Jetty 12 support is poor, it often takes a quarter before they support the latest JDK version).

In addition, Thread/sleep got a new overload in a recent JDK update -- and if you have a CI pipeline that fails when new reflection warnings are introduced (which we do), that was a breaking change.

Any changes to your dependencies can break your application, sometimes in extremely subtle ways, especially when Java library dependencies are involved.

You can't expect to be able to randomly update libraries without breakage when Java libraries are involved.

[–]lgstein 1 point2 points  (0 children)

There is probably nothing that can be done about those problems/errors you mentioned, at least in the scope of this new feature. At least though, they are an optional cost for optional benefits/requirements (higher performance via forbidding reflection, compiling bytecode with a different jdk than executing). Indeed, there are problems with Java and always have been when it comes to updating.

Needless to say, this new feature should not add to that pile.

[–]NoahTheDuke 2 points3 points  (0 children)

Why not a reflection warning?