Lombok needs modules

[Andreas Studer]

The annotations of Lombok are really useful. But it seems to me as there is no possibility to integrate external plug-ins (or sort of).  It seems there was (is?) a possibility to make extensions. However, I didn't found an official documentation for that.

Now JDK9 introduced jigsaw modularization. JDK11 will introduce that for the long term... and drops some specific modules. I think that's the first time Java does that really...

One of the long-time-always-comes-up feature requests here are JavaFX Properties, which could be a lot easier to do with Lombok. I read in a post of Reinier long time ago that he had the feeling that JavaFX is not part of the Java Core. It seems as he's very right about that.

But that also means for Lombok in the future, there are modules out of java core which still have the need for Lombok.

So I think Lombok should have a module system which allows extensions for module specific annotations. This could be either the official Jigsaw module system from Java or, if there is the need for backwards compatibility, OSGi from the OSGi alliance (Note: this is a standard and there are already several implementations in the wild. Eclipse is just the most prominent Java implementation --> see Wikipedia).

I really think there should be something available in the Lombok space for the JavaFX module. But I see it the same way like Reinier that it shouldn't be part of the Lombok "core".

What do others think about that? Am I the only one who thinks Lombok needs some sort of Modularization now?

Cheers

Andreas

[Jan-Willem Gmelig Meyling]

Hi Andreas,

It's funny that you bring this up, as I have recently asked in this mailing group about the ability to extend Lombok. As of now, Lombok seems to be the only tool being able to manipulate existing classes during APT, and I think it would be nice if the basis for Lombok could be utilised for other tools to achieve this. While this type of extension has been possible in the past, it is not possible to do this with recent versions of Lombok as they have decided to shade the internal classes so that they do not appear on the auto complete for the IDE.

Personally I think it would be best to separate the Lombok annotations and the Lombok APT processor and release them as separate Maven artifacts. By default people would load the Lombok annotation artifact as "provided" or "compile" dependencies, and add the Lombok APT processor artifact as compiler dependency (or to the compilation classpath). Extensions however, could depend directly on the APT processor artifact and by that means extend lombok. I don't think we would need Jigsaw for this, modularization works just fine as long as we're willing to "break" the module structure compared to how it always has been. (as people now need to include two dependencies rather than one). Another option for this could be to release three rather than two artifacts, the third one being a "backwards" compatible legacy artifact.

I'd be willing to provide such a build config, wouldn't it be that Lombok is still on ANT and not Maven and I am not particullary  fond of poking that.

Kind regards, 

Jan-Willem

Op donderdag 10 mei 2018 15:48:14 UTC+2 schreef Andreas Studer:

[Marco Servetto]

The situation is much more complicated than just "releasing lombock
under a better packaging"
My understanding is that there are serious theoretical issues that
need to be solved to design the core of lombock up to a standard when
it can be used as a base for others to build upon in a library sense.
That is, *today* lombock is a very leaky abstraction.
Let me be clear, lombock is great and the authors have done a
fantastic job, and they are wisely choosing to focus their work on
lombock as an instrument to deploy useful tools/features instead of
lombock as a theoretical underpinning in compile time metaprogramming.
However, In order to make "plug and play" modular annotations we need
such theoretical understanding.
It would probably require a very good student doing a PhD under good guidance.

Marco.

On 11 May 2018 at 02:26, Jan-Willem Gmelig Meyling

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[Jan-Willem Gmelig Meyling]

I agree that extending Lombok isn't easily done. For one you have to write AST bytecode and to make things worse you have to do so differently for distinct compilers. Nevertheless, developers have shown to be capable to overcome the complexity of extending lombok before (for example: https://github.com/peichhorn/lombok-pg ), so I don't really see the point you're making. Currently extending lombok is simply impossible without recompiling the entire thing, even if you are true genius. This can IMHO be easily addressed even without extensive API changes that make it available to the less gifted also.

JW

> email to project-lombok+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
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-lombok+unsubscribe@googlegroups.com.

[Reinier Zwitserloot]

As far as extending lombok goes: Great idea. I'd want it added to lombok today, but it's a lot of work and we have limited time; as Marco said better, we're spending it elsewhere.

As far as modules go: Modules are mostly just a giant pain in our backside. Lombok doesn't 'do' modules and there's very little need for us to go down that route.

We support the notion of lombok transformations aimed at things that aren't part of the core library already; the lombok.extern package is the home for such transformations. There'd be no problem putting javafx-focussed things in @lombok.extern.javafx.SomeJavaFxOrientedTransformation.

However, properties requires a lot of design first, it's not a trivial feature :P

[Marco Servetto]

I'm running Lombock on Java 11 and now I get this warning.
Is there any plan around it?
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
lombok.javac.JavacTreeMaker$TypeTag to method
com.sun.tools.javac.code.Type.getTag()
WARNING: Please consider reporting this to the maintainers of
lombok.javac.JavacTreeMaker$TypeTag
WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

[Roel Spilker]

Did you try 1.18.4?

[Marco Servetto]

Ok, I was using an older version (1.18.2).
Now I have other problems (seams like @Data in the case of fields with
@NonNull is still generating only the default constructor; Note: i'm
using my own @NonNull annotation, that according to NonNull
documentaiton
should work just fine)

[Reinier Zwitserloot]

That too was changed. See the changelog. You can use lombok.config to add your custom nonnull annotation to the list so lombok knows about it.

Java is fundamentally a namespaced language. Our approach of considering any annotation named NonNull as signalling 'null check required' was broken behaviour. (For example, it might mean: When generating a validate() method, ensure this is not null. But this thing is an old-style just-set-your-fields 'builder' so don't warn until the validation. Or hibernate's annotatoin which signals: When translating this POJO to a CREATE TABLE statement, add a nonnull constraint. That one exists, but by sheer luck is called NotNull).

On Tuesday, November 6, 2018 at 1:58:13 AM UTC+1, Marco Servetto wrote:

Ok, I was using an older version (1.18.2).
Now I have other problems (seams like @Data in the case of fields with
@NonNull is still generating only the default constructor; Note: i'm
using my own @NonNull annotation, that according to NonNull
documentaiton
should work just fine)
On Tue, 6 Nov 2018 at 13:42, Roel Spilker <r.sp...@gmail.com> wrote:
>
> Did you try 1.18.4?
>
> On Tue, Nov 6, 2018, 01:38 Marco Servetto <marco.s...@gmail.com wrote:
>>
>> I'm running Lombock on Java 11 and now I get this warning.
>> Is there any plan around it?
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by
>> lombok.javac.JavacTreeMaker$TypeTag to method
>> com.sun.tools.javac.code.Type.getTag()
>> WARNING: Please consider reporting this to the maintainers of
>> lombok.javac.JavacTreeMaker$TypeTag
>> WARNING: Use --illegal-access=warn to enable warnings of further
>> illegal reflective access operations
>> WARNING: All illegal access operations will be denied in a future release
>>
>> --
>> 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-lombok+unsubscribe@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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-lombok+unsubscribe@googlegroups.com.

[Marco Servetto]

Umm..
Yes, I prefer the behaviour as described in this email. But..
I can not find what config option I have to use.
I have searched in:
*config documentation
*nonnull documentation
*change log.
The only "hint" is "lombok.copyableAnnotations" but I really hope I do
not have to put my NonNull there.
If that is the case, it is terribly named.
It would be great to have an example lombock.config in the
documentation of NonNull.

Marco!

>> >> To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > 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.

>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

[Nick Stolwijk]

If I take a look at the change[1] Lombok doesn't seem to accept custom nonnull annotations anymore. The function "hasNonNullAnnotations" only checks for the following annotations:

"lombok.NonNull",
"javax.annotation.Nonnull",
"edu.umd.cs.findbugs.annotations.NonNull",
"org.jetbrains.annotations.NotNull",
"android.support.annotation.NonNull",
"org.eclipse.jdt.annotation.NonNull",

With regards,

[1] https://github.com/rzwitserloot/lombok/commit/d7873f2d21564e8e7f22409fe03681d7dd4c8c1e

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~

Lord Baden-Powell

[Reinier Zwitserloot]

So, should we add a config key so you can extend with your own annotations? Presumably they'd inherently be treated as copyable whether you add them to the copyableAnnotations setting or not.

>> >> To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > 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-lombok+unsubscribe@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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-lombok+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
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-lombok+unsubscribe@googlegroups.com.

[Marco Servetto]

I'm unsure.
Right now I use my NonNull so that I do not have to import lombock at run time.
At a very fast look, all of the default search paths are in third
party libraries.
Of course, I could just make my 'own package/folder' javax.annotation
and put a NonNull there...
but it is quite unorthodox...

>>> >> >> To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

>>> >> >> For more options, visit https://groups.google.com/d/optout.
>>> >> >
>>> >> > --
>>> >> > 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.

>>> >> > For more options, visit https://groups.google.com/d/optout.
>>> >
>>> > --
>>> > 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.

>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> 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.

>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.