A point for UtilityClass

[Michael Berry]

Hello,

I noticed that the UtilityClass annotation is marked as experimental:

"Some debate as to whether its common enough to count as boilerplate."

https://projectlombok.org/features/experimental/UtilityClass

I notice the outlook on this is positive, which is great to hear (I definitely think this is a common enough use case to count as boilerplate.) Just thought I'd add my 2p for another reason as to why this is a good idea though. The usual alternative is to add a private constructor that throws an AssertionError or similar (and maybe to mark the class as final.)

However, that then means that private constructor is almost impossible to unit test unless one resorts to ill-advised reflection hacks. Not testing it isn't really an issue in itself, but that has the inevitable effect of bringing the total test coverage down (unless you wade in and exempt the private constructor, which differs per testing framework.) The UtilityClass annotation is a convenient side-step to all of that, which is another reason it's very useful IMHO.

[Reinier Zwitserloot]

We'll take your +1 on this feature under advisement :)

Note that lombok as a principle holds that 100% code coverage is a silly goal and not something we'll expend any effort for. 100% code coverage requirements lead one to delete sensible defensive / futureproofing code constructs. This is bad.

[Michael Berry]

Oh I quite agree - 100% code coverage is, generally speaking, not a sensible target (nor is it feasible.)

My +1 here isn't in relation to reaching that "magic 100%" goal, but simply about generating cleaner test reports.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/e2e5b059-af31-4bda-a3ab-0fb9ddc527b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Thanks,

Michael

[Marco Servetto]

> Note that lombok as a principle holds that 100% code coverage is a silly goal and not something we'll expend any effort for. 100% code coverage requirements lead one to delete sensible defensive / futureproofing code constructs. This is bad.

YES, I wonder if Java should have an annotation to mark `unusedIsOk`
for code that is there for consistency and future proofing but do not
need to be `strictly needed`
It is different wrt an `unused` warning silenting since I would expect
to be an error to mark as unused something and then... use it..

>
> On Monday, July 15, 2019 at 11:06:36 PM UTC+2, Michael Berry wrote:
>>
>> Hello,
>>
>> I noticed that the UtilityClass annotation is marked as experimental:
>>
>> "Some debate as to whether its common enough to count as boilerplate."
>>
>> https://projectlombok.org/features/experimental/UtilityClass
>>
>> I notice the outlook on this is positive, which is great to hear (I definitely think this is a common enough use case to count as boilerplate.) Just thought I'd add my 2p for another reason as to why this is a good idea though. The usual alternative is to add a private constructor that throws an AssertionError or similar (and maybe to mark the class as final.)
>>
>> However, that then means that private constructor is almost impossible to unit test unless one resorts to ill-advised reflection hacks. Not testing it isn't really an issue in itself, but that has the inevitable effect of bringing the total test coverage down (unless you wade in and exempt the private constructor, which differs per testing framework.) The UtilityClass annotation is a convenient side-step to all of that, which is another reason it's very useful IMHO.
>