Restlet Framework 2.4.4 released and new plan for version 2.5!

[jlouvel]

Hi Restlet users,

Since we ported the project's website to GitHub Pages, moved its build to Talend's infrastructure and released Restlet Framework version 2.4.3 back in 2020, it's been pretty quiet... but we finally found the time and the motivation to make headway again!

First, we just released version 2.4.4 which should be the ultimate security fix on the 2.4 branch:

• All dependent libraries have been upgraded, including important CVE fixes,
• Minimum requirement is still Java 8,
• Exension org.restlet.ext.platform has been marked as deprecated, but its Introspector class will be retained in version 2.5 and moved into the Swagger extension where it is required,
• It is essential for you to upgrade to this version if you are using any 2.4 version, for security reason first, and also to help you migrate later to version 2.5, identifying deprecated extensions and working around any impact on your applications.
  https://restlet.talend.com/downloads/current/

In addition, we have been working on the branch 2.5 with a significant departure from the initial 2.5.0 M1 version released in 2020. Our new goal for branch 2.5 is to simplify the long term maintenance of Restlet Framework first and foremost, to facilitate contributions from the community at all levels and their processing, and nothing else:

• Complicated Ant build and manual management of dependent libraries has been replaced by a regular Maven build,
• Source code preprocessing macros are being removed all over the code base,
• Concept of multi-editions is been reduced to apply mostly at runtime, with a goal to remove it altogether in the future,
• All artifacts will be published to Maven Central and only there,
• As a consequence, https://maven.restlet.talend.com/ will not host 2.5 artifacts and will eventually be removed,
• Minimum requirement remains Java 8 (as opposed to Java 11 required by 2.5.0 M1),
• One Restlet API, one Restlet Engine, and one set of Restlet Extensions remains after merge from the previous editions, except for GWT,
• Client-side GWT keeps its own copy of the code base maintained in a dedicated folder, but server-side GWT extension is packaged with all others,
• Extensions deprecated in 2.4.4 have been removed: EMF, JavaMail, JAX-RS, JiBX, Lucene, NIO, OAuth, OpenID, Platform, RAML, Simple, WADL,
• Additional extensions have been marked 'deprecated' in 2.5, with a goal to remove them in the next major release: GAE, Guice, GWT (server-side), OData, OSGi, RDF,
• Swagger extension has also been marked as 'deprecated' but should be replaced with an equivalent extension for OAS 3.0 down the road,
• Once released, branch 2.5 will become the only Long Term Support version, where security fixes will be applied and dependencies upgraded.

We are trying to lower the bar as much as possible so that everyone actively using Restlet Framework in production can easily upgrade to the 2.5 branch. Please share with us any feedback on our plan promptly, so we can make any necessary adjustments, release M2 promptly and move towards a final 2.5.0 version this Summer. We would like to thank Tim Peierls, a long-time contributor of the project, for his valuable feedback on an earlier draft of this plan that we took carefully into account and to Cyprien Quilici and Yurii Serhiichuk for their significant contributions to Mavenify the build.
https://github.com/restlet/restlet-framework-java/tree/2.5

Beyond 2.5, we plan to resume work on the 3.0 branch, with a goal to refocus the framework on its core capabilities, in a cloud native environment where microservices and service meshes are becoming common place, innovating again based on latest Java LTS 21 version, taking advantage of native Java compilation with GraalVM, virtual threads, HTTP 3.0 and more. Eventually this should lead us to creating a whole new community web site once we are able to remove some legacy complexities related to multi-editions and custom distributions.

But before we get there, let's ensure we produce a solid and stable 2.5.0 release. We look forward to your feedback!

Best regards,
Jerome Louvel
Thierry Boileau

[flauschie]

Nice to read that there's still a bit of life left in Restlet.

I hope that javax-to-jakarta migration is coming soon to these shores as well ...

[flauschie]

Yeah, we also updated Restlet Servlet to Jakarta locally. It wasn't overly difficult, really.

The biggest "headache" is/was org.apache.commons.fileupload2.jakarta.JakartaServletFileUpload.
At this point, Apache Commons FileUpload Jakarta is only a milestone release (2.0.0-M1), and the limitations are somewhat unclear.

A feature that's urgently missing is non-blocking IO, which has been mainstream for ages in other frameworks.
And a refresh of the authentication methods.

[jlouvel]

Hi @etcoyvindf @flauschie Thanks for the feedback and guidance to transition to Jakarta Servlet 6.0.

@flauschie Could you explain what is your use case for NIO support in the framework. The current thinking is to stay on BIO for the Restlet API at the application level combined with usage of virtual threads, while taking advantage of NIO as the Restlet Engine level, via the Jetty connector essentially.

[flauschie]

@jlouvel

Regarding NIO, customers can execute long-running reports or external calls on our platform. Thus, the servlet threads are basically waiting for the DB queries/connectors to return. We had a few occasions where this led to an out-of-worker-threads situation - this was the error message back then (JBoss 7 with Tomcat(?) underneath, I think):

"Maximum number of threads (128) created for connector with address /0.0.0.0 and port 8080"

However, we haven't seen this anymore after upgrading to Wildfly/SpringBoot (Undertow Servlet engine). Whether this is a coincidence, about a different configuration of the servlet engine, or architectural changes that we made - I don't know.

[Tembrel]

The current thinking is to stay on BIO for the Restlet API at the application level combined with usage of virtual threads, while taking advantage of NIO as the Restlet Engine level, via the Jetty connector essentially.

@jlouvel - So this would transparently deal with the problem of running out of OS threads without the user needing to code differently? I guess it would only be available for fairly recent Java releases and compatible containers, since JEP 444 itself is very recent. (I haven't looked into whether virtual threads have the same safety properties that OS threads do.)

[jlouvel]

@Tembrel Yes, that is the idea and the promise of virtual threads. We need to do some tests to confirm this and understand thread safety implications indeed. This blog post and associated Jetty posts are quite insightful: https://webtide.com/jetty-12-virtual-threads-support/

@flauschie I think the virtual threads approach would be a good solution to your use case, without requiring your whole application to become async/reactive end to end which can be quite hard, beside the limitations of Restlet Framework.