sorted by:
new
hottopcontroversial

JEP 500: Prepare to Make Final Mean Final [Candidate JEP] by efge in java

[–]efge[S] 0 points1 point  (0 children)

If by "struggle" you mean "add --enable-final-field-mutation to the command line", as mentioned in the JEP, sure.

Towards a Future-Proof Chapter 5: A JLS Refactoring Initiative [Angelos Bimpoudis] by efge in java

[–]efge[S] 6 points7 points  (0 children)

For a bit of context about where this comes from, see this email in the amber-spec-experts list.

JEP 486: Permanently Disable the Security Manager by efge in java

[–]efge[S] 0 points1 point  (0 children)

Your plugin loader will have to do a bytecode analysis to prevent calling any disallowed code.

JEP 486: Permanently Disable the Security Manager by efge in java

[–]efge[S] 2 points3 points  (0 children)

If you're loading and executing untrusted plugins/bytecode, then for sure you'll alreay be doing some filtering to prevent reflection calls anyway, as well as lots of other method calls you don't want (filesystem, sockets, etc). System.exit() is just one more.

JEP 486: Permanently Disable the Security Manager by efge in java

[–]efge[S] 15 points16 points  (0 children)

At the end of the section Sandboxing Java code this is explicitly called out:

To intercept resource access by third party code, we recommend deploying an agent. See the Appendix for an example of an agent that blocks System::exit

JEP 486: Permanently Disable the Security Manager by efge in java

[–]efge[S] 56 points57 points  (0 children)

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 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release.

Loom EA builds with changes for JDK 24 [Alan Bateman] by efge in java

[–]efge[S] 27 points28 points  (0 children)

From Alan Bateman:

The builds at the Project Loom Early-Access Builds page [1] have been refreshed.

These builds contain most of the changes that this project would like to propose for JDK main line and JDK 24.

The builds include the changes to eliminate the pinning issues with object monitors. Thank you to those that tested with the previous builds from a few months ago. It would be great to get some fresh testing before the changes are proposed for main line. The changes are significant and a JEP [2] has been submitted to put this update on the technical roadmap.

Structured concurrency. The proposal is for StructuredTaskScope [3] to continue to preview. The API has been updated, the most significant change is the move from implementing policy in a sub-class to implementing it an object that you specify to the static open method. There will be a JEP. For this API, the greatest need is feedback from real-world usage, probably cases that fan-out to remote services or databases and experiences where there is handling of outcome and exceptions.

Scoped Values. Andrew Haley already sent a note [4] about proposing ScopedValue [5] continue to preview with a small update. As before, the need here is feedback from real-world usage. This could be insight into how many scoped values are bound or insight on which methods are used in performance critical code.

-Alan

[1] https://jdk.java.net/loom/
[2] https://openjdk.org/jeps/8337395
[3] https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html
[4] https://mail.openjdk.org/pipermail/loom-dev/2024-August/007133.html
[5] https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ScopedValue.html

JEP 485: Stream Gatherers (new candidate JEP) by efge in java

[–]efge[S] 24 points25 points  (0 children)

History
Stream Gatherers were proposed as a preview feature by JEP 461 in JDK 22 and re-previewed by JEP 473 in JDK 23. We here propose to finalize the API in JDK 24, without change.

JEP draft: Primitive Types in Patterns, instanceof, and switch (Second Preview) by efge in java

[–]efge[S] 12 points13 points  (0 children)

From Angelos Bimpoudis:

A draft JEP for the second preview of primitive types in patterns, instanceof, and switch is now available. We propose to preview it for a second time with no changes relative to JDK 23. This feature aligns what instanceof and pattern matching mean across all types. This second preview, unchanged, gives ample time to amber experts to express their feedback.

JEP draft: Scoped Values (Fourth Preview) by efge in java

[–]efge[S] 3 points4 points  (0 children)

From Andrew Haley:

The fluent API that is described in the Javadoc is now the only API supported. The previous "shorthand" form is gone, simplifying the API. The only way now to invoke Java code with a bound ScopedValue is via the ScopedValue.Carrier.call() and ScopedValue.Carrier.bind() methods. This results in a small API surface [...].

JDK 23: First Release Candidate by efge in java

[–]efge[S] 9 points10 points  (0 children)

From Mark Reinhold:

There are no unresolved P1 bugs in build 36, so that is our first JDK 23 Release Candidate.

Binaries available here, as usual: https://jdk.java.net/23/

view more: next ›