6
JADEx Update v0.49: Improved IntelliJ Plugin Stability and Responsiveness (github.com)
submitted 8 months ago by to c/programming@programming.dev
2 comments fedilink hide all child comments
 

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

GitHub: https://github.com/nieuwmijnleven/JADEx

This release focuses on improving JADEx IntelliJ Plugin stability and responsiveness

Key Improvements

  • Lexer Stability Fix

    • Resolved a crash in JADExLexerAdapter caused by discontinuous token offsets.
    • Ensures continuous token start/end offsets, preventing editor and indexing issues in IntelliJ.

  • Improved Code Completion

    • JADExCompletionContributor refactored to provide smoother and more reliable completion suggestions with better IDE integration.

  • Enhanced Reference Resolution

    • JADExPsiReference resolve logic updated for more dependable symbol resolution in the editor.

  • Parser Performance Optimization

    • Internal trigger logic related to executing the JADEx Processor has been optimized to reduce latency and speed up code editing.

Impact

  • Safer and more stable editing: Files can now be opened and indexed without lexer crashes.
  • Faster and more responsive IDE experience: Code completion and parsing are more efficient.
  • Reliable symbol resolution: References resolve correctly even in complex JADEx codebases.

The IntelliJ Plugin for JADEx v0.49 is now available on the JetBrains Marketplace.

We highly welcome your feedback on JADEx.

Thank you.

all 2 comments

sorted by: hot top controversial new old
[–] -2 points 8 months ago (1 child)

So it's the best bits of Kotlin in normal Java? Looks nice. Will give it a play.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • 8 comments in c/opensource@programming.dev view that post
    [–] 4 points 8 months ago (3 children)

    Mit as well use Kotlin at that point

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •
  • [–] [S] 2 points 8 months ago (2 children)

    JADEx enhances Java with null-safety and readonly (final-by-default) semantics without requiring developers to switch languages. Existing Java developers can adopt these safety features with virtually no learning curve.

    Compared to migrating to Kotlin, JADEx provides a significantly more cost-effective way to improve the reliability of large legacy Java codebases that many organizations still rely on.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 8 months ago* (1 child)

    I have an excruciatingly hard time believing anyone who maintains a legacy codebase is going to look at a brand-new Java extension and say "Yup, that's the basket we want to put all our eggs in" – compared to a robust, well-tested adjacent language that has vastly more benefits. If an organization is already extensively changing their legacy codebase to comport with some fledgling Java extension, they may as well just port to Kotlin.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 8 months ago

    I think there may be a bit of misunderstanding about what JADEx actually is.

    JADEx is designed as a Java safety layer, not a new programming language. It behaves more like a tool that sits on top of Java and strengthens null-safety while keeping full compatibility with the existing Java ecosystem.

    The workflow is essentially:

    Java (input) -> JADEx tool -> null-safe Java (output)

    In other words, developers still work within the Java ecosystem, and the final output is standard Java source code that can be compiled with the regular Java compiler.

    The key idea is that existing Java code does not need to be rewritten. You can gradually apply JADEx to strengthen null-safety in legacy codebases without migrating the language itself.

    Migrating a large legacy codebase to Kotlin, on the other hand, is closer to a language migration project. It typically requires substantial effort: rewriting parts of the codebase, updating tooling, and spending significant time validating and testing the migrated code.

    Because of that, the cost and risk profile are very different.

    JADEx aims to provide a lower-friction path to improve safety in existing Java systems, especially for teams that must remain in the Java ecosystem.

    Kotlin is a great language and an excellent choice for many projects.

    In fact, a very reasonable approach could be:

    • strengthen existing legacy Java systems with JADEx
    • write new components in Kotlin if the team prefers it

    Those two approaches are not mutually exclusive and they simply solve different problems.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 2 points 8 months ago (1 child)

    OP, your documentation on your GitHub is unreadably sprawling, and despite that, you only have one tiny section addressing Kotlin, the most blatantly obvious answer imaginable to nearly everything you've created here (the response reads like it was generated by an LLM, just saying):

    Q: Is JADEx trying to replace Kotlin or Java?

    A: No.

    • Kotlin : a separate JVM language, designed independently
    • JADEx : a Java language extension, enhancing Java with null-safety and type expressiveness

    Key Point:

    JADEx does not aim to replace Java; it simply extends Java, making it safer and more expressive while staying fully compatible with existing Java code.

    This really addresses absolutely nothing about why someone would use JADEx over Kotlin when they're already willing to use non-default Java. IntelliJ can convert existing Java code to Kotlin code. I agree constant by default is nice, but it's hard to imagine, weighed against Kotlin's benefits, that it would get someone to stay on Java (especially some fledgling extension of it) if they really want null safety.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 8 months ago

    The key point about JADEx is that it’s not intended to compete with Kotlin or replace it.

    Kotlin is a separate JVM language with its own ecosystem, compiler, and language model. Migrating a large legacy Java codebase to Kotlin is essentially a language migration project. Even though IntelliJ can automatically convert a lot of Java code, in practice teams still need to review the generated code, adapt APIs, update tooling, and spend time validating the behavior of the migrated system.

    JADEx tries to address a different scenario: teams that must stay within the Java ecosystem but still want stronger null-safety guarantees.

    Rather than introducing a new runtime or replacing the language, JADEx works as a source-level safety layer:

    Java source → JADEx analysis & operators → null-safe Java source

    The output is still ordinary, human-readable Java that compiles with the standard Java compiler and works with existing Java libraries and tooling.

    Because of that, the adoption model is different from Kotlin. Instead of migrating the entire codebase, teams can apply JADEx gradually to specific parts of an existing Java project to strengthen null-safety.

    Kotlin is a great choice for many projects, especially for new development. JADEx is mainly aimed at improving safety in large existing Java codebases where a language migration is not practical.

    I’ll restructure the README so that the core idea of the project is easier to grasp and expand the Kotlin comparison section in the documentation, since it’s clearly one of the first questions people have when they see the project.

    Thank you for your feedback.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 1 point 8 months ago (1 child)

    Or why not just use Kotlin

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 2 points 8 months ago

    JADEx enhances Java with null-safety and readonly (final-by-default) semantics without requiring developers to switch languages. Existing Java developers can adopt these safety features with virtually no learning curve.

    Compared to migrating to Kotlin, JADEx provides a significantly more cost-effective way to improve the reliability of large legacy Java codebases that many organizations still rely on.

  • permalink
  • fedilink
  • source
  • parent
    • 2 comments in c/programming@programming.dev view that post
    [–] 3 points 7 months ago* (1 child)

    I think null safety is an important step into software security. I like any approaches in that direction. But personally, I would just use kotlin. Kotlin and Java are so good with Interoperability that the transition is quite smooth and easy. Furthermore you get a better and more modern programming language without decades of technical dept.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 7 months ago

    JADEx is a solution designed to enhance null-safety in Java. Its key advantage is that existing Java developers can gain null-safety and final-by-default semantics without any learning curve. As a result, compared to migrating to Kotlin, JADEx offers a much more cost-effective way to significantly improve the stability of the legacy Java codebases that many companies continue to operate.

  • permalink
  • fedilink
  • source
  • parent