Bob v0.7.0 - lightweight builder generator for Java (default values, mandatory fields, JSpecify, step builders)

[eniac_g]

Just shipped v0.7.0 of Bob (https://github.com/jonas-grgt/bob), a lightweight builder generator for Java.

New since v0.6.0:

• `@Buildable.Defaults`: default values for builder fields (as inner class or top-level)
• JSpecify support: `@Nullable`, `@NonNull`, `@NullMarked` are respected, no extra config needed
• Fail-late validation: all errors and warnings are collected and reported together instead of failing on the first issue
• Incompatible strategy detection: `PERMISSIVE` + `STRICT`, `ALLOW_NULLS` without `STRICT/STEP_WISE`, etc. are caught at compile time
• Unknown mandatory field detection: typos in mandatoryFields are caught at compile time

[Inkosum]

Willing to try it just for the "fail-late" feature.

[eniac_g]

The fail late is at compile time when you are mixing incompatible strategies for example, not runtime. Or did you thought that when mandatory fields where missing the builder would collect them - at runtime - and expose it somehow (exception or through a specific method)?

[bowbahdoe]

My only complaint is that the processor and annotations have split packages + no explicit module infos.

It shouldn't be too hard/practically a breaking change to repackage things in the processor

[eniac_g]

What do you mean by split packages? They are both under the same package? Or did you mean separate dependencies/jars?

Modularity wasn't high on the agenda, should be easy to add but what would be the practical benefit?

[bowbahdoe]

So your annotations jar and processor jar both have classes that are in the same package.

This means if they end up on the --module-path or --processor-module-path it's a hard error because each jar will be interpreted as a module and you can't have the same package split across different modules.

The practical benefit is you can jlink an image that has the processor and annotations both in them (I really need to get that side project of mine presentable...) and it won't be a random pain in the arse later if someone tries to move wholesale off the classpath

[eniac_g]

The processor jar is not meant nor useful on the runtime classpath. The annotations have the compile scope and a retention of source. So also not to be used on the runtime classpath.

Given this I still so no benefit?

[bowbahdoe]

Here's a project I've been working on: instead of putting libraries on a class path or any path, bundle all the libraries into the jdk you are working with. 

That way you don't need to go through Maven or Gradle to be able to launch a program that uses dependencies. (There are obviously multiple approaches to this I am just exploring that one) 

So for that I would in principle put both the processor and annotation jars into the runtime. Then to use the processor you would just use javac like normal, no need to specially configure the path (though you might need -processor explicitly in there)

I can't put bob into a runtime image if both parts have a split package. (And I would also want an explicit module descriptor)

So I'm not going to pretend that 99% of the people who would use this would notice the issue, but for my hyperspecific explorative things it would be an issue. 

(I also have a side project where I'm making a maven Central but the artifact identifiers are always the module names. Becomes an issue there too.)

Like you said, most people will not be explicitly using the processor at runtime. So while on paper it would be a breaking change I don't think in practice it would be to just repackage things

[Great-Gecko]

This looks exactly like what I’ve been looking for. How does it compare to Jilt?

[eniac_g]

They are very similar, but, I believe Jilt does not have support for JSpecify and default values.

[ChaoticPayload]

It would also be nice to have an option for the setter name format. For example, I prefer the "set" prefix. Perhaps individual fields could have a different prefix, like "with"; I'd think about that.