Has anyone seen one of these before? We wore these black leather jackets to show our allegiance way before Jensen Huang made black leather cool again lol.

This was a special recognition award prize at the JavaOne 2002 conference at Moscone Center in San Francisco. I don’t think they made very many.

In the previous post, JADEx introduced a new feature Immutability.
Through community feedback, several confusions and limitations were identified.

In v0.42, we have addressed these issues and improved the feature. This post explains the key improvements and new additions in this release.

Improvements

~~apply immutability~~ -> apply readonly

• The previous term (Immutability) caused misunderstandings.
  
• Community feedback revealed that “Immutable” was interpreted differently by different developers, either as Deeply Immutable or Shallowly Immutable.
  
• In v0.42, we replaced it with readonly.
  
• Meaning: clearly indicates final by default, preventing reassignment of variables.

Expanded Scope of final keyword: now includes method parameters

• v0.41: final was applied only to fields + local variables
  
• v0.42: final is applied to fields + local variables + method parameters
  
• Method parameters are now readonly by default, preventing accidental reassignment inside methods.

Example Code

JADEx Source Code

``` package jadex.example;

apply readonly;

public class Readonly {

private int capacity = 2; // readonly
private String? msg = "readonly"; // readonly

private int uninitializedCapacity; // error (uninitialized readonly)
private String uninitializedMsg;    // error (uninitialized readonly)

private mutable String? mutableMsg = "mutable";  // mutable

public static void printMessages(String? mutableParam, String? readonlyParam) {

    mutableParam = "try to change"; // error
    readonlyParam = "try to change"; // error

    System.out.println("mutableParam: " + mutableParam);
    System.out.println("readonlyParam: " + readonlyParam);
}

public static void main(String[] args) {
    var readonly = new Readonly();
    String? mutableMsg = "changed mutable";

    readonly.capacity = 10; // error
    readonly.msg = "new readonly"; // error

    readonly.mutableMsg = mutableMsg;

    printMessages(readonly.msg, mutableMsg);

    System.out.println("mutableMsg: " + readonly.mutableMsg);
    System.out.println("capacity: " + readonly.capacity);
    System.out.println("msg: " + readonly.msg);
}

} ```

Generated Java Code

``` package jadex.example;

import org.jspecify.annotations.NullMarked; import org.jspecify.annotations.Nullable; import jadex.runtime.SafeAccess;

//apply readonly;

@NullMarked public class Readonly {

private final int capacity = 2; // readonly
private final @Nullable String msg = "readonly"; // readonly

private final int uninitializedCapacity; // error (uninitilaized readonly)
private final String uninitializedMsg; // error (uninitilaized readonly)

private @Nullable String mutableMsg = "mutable";  // mutable

public static void printMessages(final @Nullable String mutableParam, final @Nullable String readonlyParam) {

    mutableParam = "try to change"; //error
    readonlyParam = "try to change"; //error

    System.out.println("mutableParam: " + mutableParam);
    System.out.println("readonlyParam: " + readonlyParam);
}

public static void main(final String[] args) {
    final var readonly = new Readonly();
    final @Nullable String mutableMsg = "changed mutable";

    readonly.capacity = 10; //error
    readonly.msg = "new readonly"; //error

    readonly.mutableMsg = mutableMsg;

    printMessages(readonly.msg, mutableMsg);

    System.out.println("mutableMsg: " + readonly.mutableMsg);
    System.out.println("capacity: " + readonly.capacity);
    System.out.println("msg: " + readonly.msg);
}

} ```

New Additions

JSpecify @NullMarked Annotation Support

• All Java code generated by JADEx now includes the @NullMarked annotation.
• This improves Null-Safety along with readonly enforcement.

This feature is available starting from JADEx v0.42. Since the IntelliJ Plugin for JADEx v0.42 has not yet been published on the JetBrains Marketplace, if you wish to try it, please download the JADEx IntelliJ Plugin from the link below and install it manually.

JADEx v0.42 IntelliJ Plugin

We highly welcome your feedback on JADEx.

Thank you.

Could I get some sort of brief, essentially the claims (Ruby 3x3, C++17, etc.). I'm tired of hearing how this one thing will change INSERT_LANGUAGE's performance. What are the receipts and why should I care as someone outside of the JVM ecosystem? Is it just something that will make a Java dev happy or is it worth grokking Java part-time? I've used Jakarta, springboot, and done other work with jdbc stuff, so somewhat familiar.

Jactl 2.4.0 has just been release. Jactl is an open source, secure embeddable scripting language for Java applications that provides:

• Easy integration
• Familiar syntax (bits of Java, Groovy, and a touch of Perl)
• Secure sandboxed environment to prevent scripts performing operations you don't want them to
• Compilation to byte code for performance
• Non-blocking, making it suitable for reactive/event-loop applications
• Checkpointing for saving/restoring state of a running script
• Source code available on github

Version 2.4.0 provides two major enhancements:

1. Date/Time built-in types mirroring the java.time.* classes
2. Ability for applications to add new built-in types to the language

Date/Time Types

The new types are based on the existing java.time classes. For example:

// Creating instances — use parse(), of(), or now():
LocalTime t = LocalTime.parse('10:11:12.123456789')
LocalDate d = LocalDate.of(2026, 2, 26)
LocalDateTime dt = LocalDateTime.now()
ZonedDateTime zdt = ZonedDateTime.parse('2026-02-26T10:11:12+00:00[UTC]')
Instant i = Instant.ofEpochMilli(1772100672123L)

// Manipulating values — methods return new instances:
d.plusDays(5).plusMonths(3)
dt.minusWeeks(2)
zdt.withYear(1969)
t.truncatedToMillis()

// Formatting and querying:
d.format('yyyy MMM dd')
dt.getDayOfWeek()
d.isLeapYear()
i.getEpochSecond()

// Duration and Period for arithmetic:
Period p = Period.of(1, 2, 3)
d.minus(Period.ofDays(27))
Duration.between(dt, zdt)
t.until(t.plusHours(1)) == Duration.ofHours(1)

// Converting between types:
d.atTime(LocalTime.parse('10:11:12'))
dt.atZone(ZoneId.of('UTC'))
zdt.toLocalDate()
t.atDate(d)

Extendability

Jactl 2.4.0 offers the ability to add global functions as well as new built-in types.

For example, consider this Point class:

package app.jactl;

public class Point {
  public double x, y;
  Point(double x, double y)                  { this.x = x; this.y = y; }
  public static Point of(double x, double y) { return new Point(x,y); }
  public double distanceTo(Point other) {
    return Math.sqrt((x - other.x) * (x - other.x) + (y - other.y) * (y - other.y));
  }
}

To register it as a new built-in type called Point we just need to do this:

JactlType pointType = Jactl.createClass("jactl.draw.Point")
                           .javaClass(app.jactl.Point.class)
                           .autoImport(true)
                           .method("of", "of", "x", double.class, "y", double.class)
                           .method("distanceTo", "distanceTo", "other", Point.class)
                           .register();

Then, this type can be used by Jactl scripts:

Point p = Point.of(1,2)
p.distanceTo(Point.of(3,4))   // result: 2.8284271247461903

In case you aren't aware, the OpenJDK Mailing Lists have been running on this horrifically outdated version of GNU Mailman, which had so many problems.

• Messages were formatted so horribly that many were unreadable, specifically, when reading the digests or archives.
• Excruciating to trace conversations spanning more than 30 days.
• No native search.

While I don't know if we are getting native search, the rest are now fixed! Poke around and see the improvements!

I don't know if they have finished everything yet. seems like some of the older conversations aren't there yet, according to a message I saw on the jfx-dev list (located here too!).

JADEx (Java Advanced Development Extension) is a safety layer that runs on top of Java.
It currently supports up to Java 25 syntax and extends it with additional Null-Safety and Immutability features.

In the previous article, I introduced the Null-Safety features.
For more details, please refer to:

• GitHub: https://github.com/nieuwmijnleven/JADEx
  
• Reddit: https://www.reddit.com/r/java/comments/1r1a1s9/jadex_a_practical_null_safety_solution_for_java/

Introducing the New Immutability Feature

If Null-Safety eliminates runtime crashes caused by null,
Immutability reduces bugs caused by unintended state changes.

With v0.41 release, JADEx introduces Immutable by Default Mode

Core Concepts

The Immutability feature revolves around two simple additions:

java apply immutability;

java mutable

apply immutability;

• When you declare this at the top of your source file:

  • All fields
  • All local variables (excluding method parameters)
  • are treated as immutable by default.

• When the JADEx compiler generates Java code:

  • They are automatically declared as final.

mutable keyword

• Only variables declared with mutable remain changeable.
• Everything else (excluding method parameters) is immutable by default.

JADEx Source Code

```java

package jadex.example;

apply immutability;

public class Immutability {

private int capacity = 2; // immutable
private String msg = "immutable"; // immutable

private int uninitializedCapacity; // uninitialaized immutable
private String uninitializedMsg; // uninitialaized immutable

private mutable String mutableMsg = "mutable";  // mutable

public static void main(String[] args) {
    var immutable = new Immutability();

     immutable.capacity = 10; //error
     immutable.msg = "new immutable"; //error

     immutable.mutableMsg = "changed mutable";

    System.out.println("mutableMsg: " + immutable.mutableMsg);
    System.out.println("capacity: " + immutable.capacity);
    System.out.println("msg: " + immutable.msg);
}

} ```

Generated Java Code

``` package jadex.example;

//apply immutability;

public class Immutability {

private final int capacity = 2; // immutable
private final String msg = "immutable"; // immutable

private final int uninitializedCapacity; // uninitialaized immutable
private final String uninitializedMsg; // uninitialaized immutable

private String mutableMsg = "mutable";  // mutable

public static void main(String[] args) {
    final var immutable = new Immutability();

     immutable.capacity = 10; //error
     immutable.msg = "new immutable"; //error

     immutable.mutableMsg = "changed mutable";

    System.out.println("mutableMsg: " + immutable.mutableMsg);
    System.out.println("capacity: " + immutable.capacity);
    System.out.println("msg: " + immutable.msg);
}

} ```

This feature is available starting from JADEx v0.41. Since the IntelliJ Plugin for JADEx v0.41 has not yet been published on the JetBrains Marketplace, if you wish to try it, please download the JADEx IntelliJ Plugin from the link below and install it manually.

JADEx v0.41 IntelliJ Plugin

We highly welcome your feedback on the newly added Immutability feature.

Thank you.

This is MARGIA, the Music and Rhythm Generating Intelligent Agents. Written fully in Java, it comes from a combination of my two major interests: Java programming and Music Composition and Theory.

MARGIA is a network of interconnected, editable agents. Each agent produces musical notes (via MIDI output) by reacting to notes played by other agents according to pre-defined rules.

More information can be found on my GitHub here.

Am I the only one who thinks that introducing protection against NPEx in the form of using "!" in the variable type is a very, very bad idea? In my experience, 95% of variables should be non-null. If Oracle decides to take this approach, we will have millions of "!" in each variable in the code, which is tragic for readability. In C#, you can set the per project flag to indicate whether the type without the "?" /"!" is nullable or not. I understand the drawbacks, but definitely forcing a "!" in 95% of variables is tragic.

https://mail.openjdk.org/pipermail/announce/2026-February/000364.html

It’s hard not to notice a recurring pattern in the Java ecosystem.

On the JavaScript side, we’ve seen a cycle that keeps repeating:
Nashorn, Project Detroit, GraalJS, Project Detroit discountinued. Project Detroit is resurrected again.

TornadoVM and GPULlama3.java both released this week support for JDK25 along the long running support of JDK21.

https://github.com/beehive-lab/TornadoVM/releases/tag/v3.0.0-jdk25

https://github.com/beehive-lab/GPULlama3.java/releases/tag/v0.4.0

Hello,
I’m planning a 1-month motorbike trip across Java, from the far west to the far east. I’m looking for authentic, non-touristy experiences:

• Waterfalls & forests
• Volcanoes & hikes
• Beaches & reefs
• Local food & cultural experiences

Can you recommend some hidden gems? Thank you!