Hi,
I work for Kestra, a data orchestrator: https://www.kestra.io.
Kestra handles workflows made of tasks and triggers, both of which are
plugins. We provide more than 500 plugins, but users can also bring their
own plugins in the form of JARs they put in a specific directory.
Our plugin mechani
Nice, we still get to use Java 23 ;) I listened to one of Brian's
talks recently, it sounds like you're solving some long term structural
issues with Java.
Looking forward to a Jep for removal of Java serialization. Note we use
constructor based deserialization, with a single common defined
We are aiming to do this in 24, but nothing is official until the JEP is
targeted to a specific release.
--Sean
On 10/3/24 6:28 AM, Peter Firmstone wrote:
Which release does this target?
I've been waiting to learn the affected Java release, so we can document
which versions of Java our softw
Which release does this target?
I've been waiting to learn the affected Java release, so we can document
which versions of Java our software can and cannot support.
We'll continue to use Java beyond this release, but will need to
maintain our own fork, as it's not possible to build an Authori
On 26/09/2024 15:04, Lothar Kimmeringer wrote:
:
When looking for this the past couple of years since this topic
came up, I haven't found any concept for a replacement for canExit
and only "use some feature on the OS-level the application runs on"
as replacement for canExec. The latter would des
Am 26.09.2024 um 13:50 schrieb Mark Reinhold:
it has rarely been used
to secure server-side code, and it is costly to maintain.
We're one of these "rare" users and are using SecurityManager to prevent
unallowed parts of a server-application to start sub processes
(sm.canExec) and to sh
// Correcting Sean’s e-mail address
https://openjdk.org/jeps/486
Summary: The Security Manager has not been the primary means of
securing client-side Java code for many years, it has rarely been used
to secure server-side code, and it is costly to maintain. We therefore
deprecated it for
https://openjdk.org/jeps/486
Summary: The Security Manager has not been the primary means of
securing client-side Java code for many years, it has rarely been used
to secure server-side code, and it is costly to maintain. We therefore
deprecated it for removal in Java 17 via JEP 411 (20
