What about Lombok runtime?

[v6ak]

Well, I can write an app using Lombok and compile it (javac, eclipsec,
delombok). However, when I want to run it, I sometimes (currently if
@SneakyThrows is used) need lombok.jar. Well, I can include it to
include path. However, it contains too much things: Lombok installer,
Eclipse plugin, javac handlers, delombok (currently not in stable
version) etc. I don't need many of them. What about separating a
simple slim distribution lombok-runtime.jar which allows to run lombok-
compiled code? Original distribution can be unaffected.

[Michael Lorton]

I don't think there is any runtime library.  All the annotations seems to write their code on the fly and inject it into the class.

M.

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[Vít Šesták]

Well, you're right if you're writing about most of Lombok annotations
(e.g. @Data, @Getter, @Setter).
However, there is at least one exception:
http://projectlombok.org/features/SneakyThrows.html
For example: I've a project with about 4000 lines with one
@SneakyThrows so I've to include about 1.7MiB Lombok with one small
runtime-useful class only :-D
I understand why authors want to mix delombok, Eclipse plugin, javac
handlers, Lombok compile-time annotations, Lombok installer and Lombok
runtime together, but it would be useful to have special ultra thin
distribution for runtime only.
Vít Šesták AKA v6ak

On 11/27/09, Michael Lorton <mic...@circuspop.com> wrote:
> I don't think there *is* any runtime library. All the annotations seems to

> write their code on the fly and inject it into the class.
>
> M.
>
> On Fri, Nov 27, 2009 at 7:26 AM, v6ak <v6...@volny.cz> wrote:
>
>> Well, I can write an app using Lombok and compile it (javac, eclipsec,
>> delombok). However, when I want to run it, I sometimes (currently if
>> @SneakyThrows is used) need lombok.jar. Well, I can include it to
>> include path. However, it contains too much things: Lombok installer,
>> Eclipse plugin, javac handlers, delombok (currently not in stable
>> version) etc. I don't need many of them. What about separating a
>> simple slim distribution lombok-runtime.jar which allows to run lombok-
>> compiled code? Original distribution can be unaffected.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups group for http://projectlombok.org/
>>
>> To post to this group, send email to project...@googlegroups.com
>> To unsubscribe from this group, send email to

>> project-lombo...@googlegroups.com<project-lombok%2Bunsu...@googlegroups.com>

[Reinier Zwitserloot]

SneakyThrows is the only exception right now, but other planned
transformations will also have runtime dependencies.

We'll spin out something lean and mean. In the mean time, just remove
the file lombok/Lombok.class from the jar and include that in your
distribution; it's the only actual dependency.

On Nov 27, 8:24 pm, Vít Šesták <vit...@gmail.com> wrote:
> Well, you're right if you're writing about most of Lombok annotations
> (e.g. @Data, @Getter, @Setter).
> However, there is at least one exception:http://projectlombok.org/features/SneakyThrows.html
> For example: I've a project with about 4000 lines with one
> @SneakyThrows so I've to include about 1.7MiB Lombok with one small
> runtime-useful class only :-D
> I understand why authors want to mix delombok, Eclipse plugin, javac
> handlers, Lombok compile-time annotations, Lombok installer and Lombok
> runtime together, but it would be useful to have special ultra thin
> distribution for runtime only.
> Vít Šesták AKA v6ak
>

> On 11/27/09, Michael Lorton <mich...@circuspop.com> wrote:
>
>
>
> > I don't think there *is* any runtime library.  All the annotations seems to
> > write their code on the fly and inject it into the class.
>
> > M.
>

> > On Fri, Nov 27, 2009 at 7:26 AM, v6ak <v...@volny.cz> wrote:
>
> >> Well, I can write an app using Lombok and compile it (javac, eclipsec,
> >> delombok). However, when I want to run it, I sometimes (currently if
> >> @SneakyThrows is used) need lombok.jar. Well, I can include it to
> >> include path. However, it contains too much things: Lombok installer,
> >> Eclipse plugin, javac handlers, delombok (currently not in stable
> >> version) etc. I don't need many of them. What about separating a
> >> simple slim distribution lombok-runtime.jar which allows to run lombok-
> >> compiled code? Original distribution can be unaffected.
>
> >> --
> >> You received this message because you are subscribed to the Google

> >> Groups group forhttp://projectlombok.org/

>
> >> To post to this group, send email to project...@googlegroups.com
> >> To unsubscribe from this group, send email to

> >> project-lombo...@googlegroups.com<project-lombok%2Bunsubscribe@go oglegroups.com>

> >> For more options, visit this group at
> >>http://groups.google.com/group/project-lombok?hl=en
>
> > --
> > You received this message because you are subscribed to the Google

> > Groups group forhttp://projectlombok.org/

[Reinier Zwitserloot]

I've been busy. If you check out lombok from the git repository and
build it, the jar itself is now capable of lots of interesting things
from the command line, including spitting out a lombok-runtime.jar.
Try it out with:

java -jar lombok.jar --help

to spit out the runtime version:

java -jar lombok.jar createRuntime -pc

(that's "print things that would cause a dependency on lombok-
runtime.jar, and create lombok-runtime.jar. Command line help is of
course available via java -jar lombok.jar createRuntime --help).

v0.9.2 is shaping up to be an interesting release.

[Vít Šesták]

Ok, it is a similar solution. I'm writing from my mobile phone with no
java source compiler, no GIT application and with J2ME (AOT VM) only
java so I haven't tried it yet.
Note that I've a crazy idea: warning type "lombok-runtime". Every
annotation that requires lombok-runtime.jar would cause this warning.
If a programmes knows that it is ok, he can simply add
@SuppressWarning("lombok-runtime") This warning should be globaly
suppressable (for whole project), I think. I don't know much about
global compilation configuration.
What do you think about this crazy idea?
Vít Šesták AKA v6ak

> Groups group for http://projectlombok.org/

[Reinier Zwitserloot]

Unfortunately, warning suppression isn't generally configurable in
most compilation/IDE sources. Even @SuppressWarnings isn't a
particular nice solution either, as at least eclipse will generate a
warning on unknown strings in @SuppressWarnings. So, can't do it :(

On Nov 28, 2:04 pm, Vít Šesták <vit...@gmail.com> wrote:
> Ok, it is a similar solution. I'm writing from my mobile phone with no
> java source compiler, no GIT application and with J2ME (AOT VM) only
> java so I haven't tried it yet.
> Note that I've a crazy idea: warning type "lombok-runtime". Every
> annotation that requires lombok-runtime.jar would cause this warning.
> If a programmes knows that it is ok, he can simply add
> @SuppressWarning("lombok-runtime") This warning should be globaly
> suppressable (for whole project), I think. I don't know much about
> global compilation configuration.
> What do you think about this crazy idea?
> Vít Šesták AKA v6ak
>

[Vít Šesták]

Well, if Eclipse has the Lombok plugin, it shouldn't be unknown
warning. If Eclipse has not the plugin, you can't compile source that
uses Lombok so it is irrelevant, I think.
I know that there are some ways to specify something globaly. Well,
you maybe cannot globaly suppress some warning, but if you can add an
parameter to the annotation processor (javac: -Akey=value), the
annotation processor can decide to not throw the warning.
Vít Šesták AKA v6ak

> Groups group for http://projectlombok.org/

[Reinier Zwitserloot]

Nope; the set of legal warning strings is not an expandable concept.
We could of course simply hack eclipse's list-of-known-warning
strings, but even if it is a known warning, I still don't like this
idea. You'd have to stick @SuppressWarnings() on *EVERY* *USAGE* of
@SneakyThrows. Seems rather silly.

On Nov 28, 4:49 pm, Vít Šesták <vit...@gmail.com> wrote:
> Well, if Eclipse has the Lombok plugin, it shouldn't be unknown
> warning. If Eclipse has not the plugin, you can't compile source that
> uses Lombok so it is irrelevant, I think.
> I know that there are some ways to specify something globaly. Well,
> you maybe cannot globaly suppress some warning, but if you can add an
> parameter to the annotation processor (javac: -Akey=value), the
> annotation processor can decide to not throw the warning.
> Vít Šesták AKA v6ak
>

[Vít Šesták]

1) It is possible to make something like @SneakyThrows(suppress=true) or @SuppressLombokRuntimeWarnings @SneakyThrows instead of @SuppressWarnings("lombok-runtime") @SneakyThrows.
2) At least javac supports annotation processor options: -Akey[=value]              Options to pass to annotation processors
javac -cp lombok.jar -Asuppress-lombok-runtime ...
3) @SuppressLombokRuntimeWarnings / @SuppressWarnings can be used per class.
4) Well, is it really often used?

Vít Šesták AKA v6ak

Reinier Zwitserloot napsal(a):

[Reinier Zwitserloot]

suppress=true doesn't feel right. It would mean that every future
lombok transformation that has a runtime dependency needs to remember
to put that in, and soon people will start using muscle memory to
write @SneakyThrows(suppress=true) without actually thinking of the
issue.

Lombok isn't an annotation processor (that's just the mechanism used
by lombok to run in javac), so passing options via -A is not a good
option.

Some specific annotation to indicate you're aware of the need to have
lombok-runtime.jar available is probably the best of the set, but it
still feels wrong. @SneakyThrows exists primarily to tell the compiler
to take a hike and stop whining. And then _WE_ start whining?

[Roel Spilker]

We could give delombok an option to list all classes that have a
runtime-dependency.

[v6ak]

OK, I can see that this is probably a simpler and better solution.