Clojurians Log v2
ring
Looks like commons-fileupload2-core upgrade from 2.0.0-M1 to 2.0.0-M2 in ring-core 1.13.1 broke Java 8 support. Was that known? Should it be documented on the changelog or somewhere?
Execution error (UnsupportedClassVersionError) at java.lang.ClassLoader/defineClass1 (ClassLoader.java:-2).
org/apache/commons/fileupload2/core/AbstractFileUpload has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Jetty 11 required Java 11, so Ring has required version 11 for a while. In fact, Jetty 12 requires Java 17. That said, it is something we can easily note on the Changelog.
Aha, the core lib doesn't depend on the jetty libs and Reitit probably runs tests without http server or with other servers.
Very likely so.
Ring doesn't depend on a great many Java libraries, but those it does do don't have much of an interest in maintaining compatibility with Java 8.
It seems like 11 is the new minimum.
A note on the changelog or readme would be nice
No problem, I'll get on that. I didn't realise that 2.0.0-M2 required Java 11, as Ring tests with 11 as a minimum since that's what Jetty required.
Done.
Great, thanks!
hi, James! congratulations on the release of Ring 1.4! i’m excited that ring/ring-jetty-adapter started supporting Jetty 12 so that we can reap all the benefits that come with it and Java 21 (performance improvements, virtual threads, etc.).
i noticed that, unlike info.sunng/ring-jetty9-adapter, ring/ring-jetty-adapter depends on the Jakarta EE Servlet API. i’m curious if this a deliberate decision or a transitory choice with a future plan to decouple the official adapter from the Jakarta EE Servlet API and implement it using only the Jetty Handler API. i figure since Ring and even Jetty itself are mostly used in an embedded fashion, the Jakarta EE Servlet API dependency wouldn’t be necessary, no? can you please share your thoughts on that?
Initially it was a transitory choice. Updating the adapter to Jetty 12 via the Servlet API just involved changing artifacts and packages, so a relatively straightforward job. I was going to investigate using Jetty's native classes in their place. My guess is that this would be a lot of work. However, it's been pointed out to me that the Servlet API is more compatible with tools like New Relic than native Jetty, so there may be benefits to keeping the current design. If rj9a continues with the native classes approach, it may be better to retain the Servlet approach for Ring, so developers have a choice.
ah, i see. that makes sense. a very pragmatic decision indeed. 👍 thanks!