RecordBuilder Enhancer

[Randgalt]

FOR YOUR CONSIDERATION

This is an idea that I've had for a while: being able to inject null checks and defensive copying into Java Record default constructors. While working on the idea I was able to generalize it into something that can be customizable as part of a normal build process.

See the README for complete details.

I haven't decided on whether or not to release this yet. If people find it useful I will. Use <version>34-SNAPSHOT</version> to test it.

THANK YOU

[frankbenoit]

Hi Jordan,

I gave it a try and I really think that this is a really good enhancement to Java records. In my project we are now switching to Java 17 LTS, hence first real contact with records. We make heavy use of Eclipse JDT null annotations.

By not using the standard dir layout, i configured maven as described. When running the maven build and starting the java from command line this works as expected.

Problem: However, running from withing eclipse, this is not yet working. For annotation processors, Eclipse only offers to configure key/value pair for the "-A" compiler options. No way AFAIK for the -Xplugin... Could there be an alternative way to support configuring the output dir over -A...?

Further idea: In Eclipse we use the JDT annotations @NonNullByDefault, @NonNull, @Nullable. Normally we assume that everything is non-null and then mark the exceptions with @Nullable. Would be nice if the builtin Enhancers also allow the default nonnull and only to mark those nullable.

Frank

[Randgalt]

Eclipse only offers to configure key/value pair for the "-A" compiler options. No way AFAIK for the -Xplugin... Could there be an alternative way to support configuring the output dir over -A...?

Thanks for the feedback @frankbenoit.

I'd be very surprised if Eclipse didn't have a way to set javac options. I found this on SO. Can you give it a try? I'll also try to download Eclipse when I get a chance.

https://stackoverflow.com/a/9483388/2048051

I did some research. I guess Eclipse uses their own javac compiler (which seems insane to me 🤷🏻). Therefore I don't think Enhancer will work with it unless they support plugins somehow. I'm looking into it.

[Randgalt]

Further idea: In Eclipse we use the JDT annotations @NonNullByDefault, @NonNull, @Nullable. Normally we assume that everything is non-null and then mark the exceptions with @Nullable. Would be nice if the builtin Enhancers also allow the default nonnull and only to mark those nullable.

If I understand, this is an inverse of NotNullAnnotations right? Maybe a separate enhancer that treats everything as non-null unless annotated to denote that it's nullable.

[Bananeweizen]

This will not work in Eclipse, AFAIK. Eclipse supports the Java 5 Annotation Processor Tooling interface (which is what @frankbenoit was talking about), but not the javac plugin interface that is used here. Eclipse has its own Java compiler ecj, and the source of that doesn't have a single occurrence of the package used by the javac plugin interface. To my understanding the 2 mechanisms are also very different: javac plugins emit binary code for the class file, annotation processors generate additional source files that are then compiled as before. (And if you think of Lombok producing byte code via APT, it actually includes itself into the compiler via some hacks and is then able to manipulate bytecode, but the APT interface was never meant for that).

[Randgalt]

Yes, I agree with @Bananeweizen - this will not work directly in Eclipse. I haven't used Eclipse in maybe 15 years. I just did a quick test with Eclipse and you can add a Maven configuration to do a build that will use the real javac. That would be my suggestion: use Eclipse for your day-to-day work and then do the real build with Maven.

[Randgalt]

wow - I didn't realize VS Code uses Eclipse under the hood too. This javac plugin might be a problem. For the life of me, I don't understand why this was done this way but it seems I need to come up with an alternate. VS Code supports the Errorprone compiler somehow. Maybe this can be done via a similar approach?

[GavinRay97]

There is also a second extension for Java in VS Code, which is the extension that Oracle/GraalVM/Micronaut developers recommend, using the Netbeans language server:

• https://www.graalvm.org/22.1/tools/vscode/graalvm-extension-pack/#extensions-included
• https://marketplace.visualstudio.com/items?itemName=asf.apache-netbeans-java

It's actually quite decent. Though at ~30k downloads, it's nowhere near the 17 million that the Redhat one has 😅

I think this proposal is exciting and would be very useful =)

[toolforger]

@Randgalt can you make this a separate tool? Bytecode enhancement does have its drawbacks and I'd prefer to stick with a APT-only solution. Of course this would likely be an opt-in feature, but when advocating using record-builder in the team, I'd prefer to not have to explain that (I have to explain various things that don't match existing coding policies already, each additional point makes it harder to justify introducing it).

[Randgalt]

I won't be merging this. Too many problems and tools like Eclipse/VSCode that don't use the standard javac compiler.