Delombok a single annotation

[lombokissues]

Migrated from Google Code (issue 711)

[lombokissues]

👤 snekse   🕗 Jul 23, 2014 at 15:20 UTC

With the @ Delegate annotation being moved back to Experimental, it seems like it would be useful to have a flag option in Delombok to remove just the annotations that I specify.

e.g.
delombok -a Delegate,SneakyThrows

[lombokissues]

👤 reinierz   🕗 Feb 08, 2015 at 21:02 UTC

I can see why you'd possibly want that, but we're not going to build this. We don't foresee any main-package feature ever moving into experimental. Delegate was a unique case (it was added before we came up with the 'experimental' concept).

[lombokissues]

End of migration

[timtebeek]

@rzwitserloot Would you ever reconsider this position? We're coming across an issue where other tools do not play well with Lombok, and where it would be nice to retain the majority of what Lombok offers, but remove a single feature. (In this case val).

There are other use cases as well such as retroactively banning @SneakyThrows from the organization, which would benefit from a feature argument to Delombok.CmdArgs, possibly combined with an inplace argument to update the source rather than a target.

I understand there's already so much to work on, but I really think it would underwrite the notion that Lombok is safe to use, and easy to selectively retire features in the future if need arises.

[rzwitserloot]

val migration is certainly useful, yes. But I think we need to do something else for that - if delombok makes modifications it might various parts of your file a little bit (not in a syntactically relevant way, of course).

For val specifically we could write something that leaves everything bit-for-bit intact, replacing just val.

Or possibly even simpler, just replace val with final var and be done with it, which is probably the simplest thing to do here (and if you want to move away from val but stick with JDK8, maybe we just say you can't do that).

A 'dumb' sed script can do it, more or less, but it'd be nice if only specifically lombok.val usage is replaced and not any mention of val anywhere in a java file. That's not quite safe.

There are other use cases as well such as retroactively banning @SneakyThrows from the organization

That sounds like a mistake. Nothing about why @ST has been introduced changed.

possibly combined with an inplace argument to update the source rather than a target.

Boy, the scope creep, I can smell it from here.

A val replacement script, that makes sense to me. The rest not so much.

[timtebeek]

Good to hear we agree at least on the val migration; would you want track that as a separate issue?

Or are you suggesting users apply that themselves with sed, without further changes to Lombok?

[rzwitserloot]

Well, the sed thing is hard to do correctly, in the sense that you don't want String x = "Please select a different val" to be turned into String x = "Please select a different final var", but writing a sed script to do it correctly is tricky, especially considering that int val = 5; is legal java and definitely should not become int final var = 5;.

I think a separate issue is in order, specifically for a java -jar lombok.jar valToVar command (Possibly it makes more sense to make this a 'mode' of the delombok tool instead, we'll think about it).

[timtebeek]

Perfect; want me to create a new issue? Or are you planning to add some implementation details already yourself?

[rzwitserloot]

Go ahead :)

[timtebeek]

Perfect, thanks; details here: #3207