Is anyone using extension methods?

[Marc Günther]

aka: Are Extension Methods stable enough for productive use?

Hi,

one of the features I miss the most in good old Java is extension methods. Although in the end it's just syntactic sugar, it is such incredible useful syntactic sugar, that I really don't know how anyone can live without it.

So I was incredible excited when I found that Lombok provides exactly those. And it works in Eclipse, which unfortunately is the IDE I am stuck with for historical reasons.

So why am I writing this post? Well, after almost two months now of playing around with Lomboks extension methods, I wonder, is this really something which is ready to be used for real development?

I ask for the following three reasons:

a) It is still in experimental. And has been there for a long time, and it doesn't look like it's being promoted anytime soon. Not a good sign.

b) Nobody seems to be using it. Given how useful it is, one would think there were several projects on Github, where people would post their collection of static methods that are useful as extension methods. I found nothing whatsoever.

c) Within the first two days of using it, I stumbled upon at least 5 problems (which is another hint that no one is really using it):

  1) default methods in interfaces are not supported
  2) clashes in a bad way with methods that might already exist in sub classes
  3) can not handle methods with the same name, which differ only in their parameter types (overloading)
  4) val and extension methods do not work together (in javac only)
  5) delombok does not rewrite all extension method calls

1) was easy enough to fix in Lombok sources and works perfectly well. But I now need to keep a patched Lombok around. I wonder why such an easy change was never implemented. Default methods in interfaces exist since 8 years. There isn't even a bug report about it. Another sign that no one is really using it.

2) is somewhat limiting. Basically blocks you from extending Object with anything useful, unless you can come up with method names that no one else uses. Otherwise there will be errors in unexpected places. The one single example, that Lombok provides, the or() method on Object, already blows up in my code base.

3) is scary. I cannot implement let's say Stream.map(BiFunction), because then every single normal map(Function) invocation wants to use my new implementation and fails. It get's even scarier when I added the normal map(Function) version as well, then the compiler goes completely berserk, and spits out errors on all kinds of unrelated places.

4) was quite annoying. Everything was fine in Eclipse, I was busy changing things around, and when I commit after several hours, the CI build fails. Turns out, that javac cannot figure out the type of the rhs of a declaration, when an extension method is part of the expression, but Eclipse is totally fine with it.

Stuff like this is almost a show stopper for me. We are using immutables.io library as well, which also had a bug like this, where javac and Eclipse behave in completely different way. We lost two days of work or so, because a colleague did a big refactoring, only to find out after she was done, that it would not compile on CI, although everything worked fine in Eclipse. I do not want to go there again.

5) I never had to use delombok, and I hope I never need to, but I tried it nonetheless, and it left me with code that didn't compile, because it did not rewrite all extension method calls to their static form.


Conclusion:

After these initial problems, it works quite well now. But that might be because I now know what I should and should not do, and I am careful. I don't know what others might do with it, and I don't know if I want them to use a tool which potentially might break under real world use.

Apart from these, there are other small inconveniences as well, like "Open Declaration"/"Open Call Hierarchy" not working, and hovering over a method does not show anything useful in the tooltip. I think I can live with that, but others might not like that at all.

Until now I'm keeping this in an experimental branch. So before I unleash this on the rest of the team, I would like to get some feedback from the community. Do you use it? Are you happy with it? Is the payoff worth the problems and limitations? Or should I avoid it, and wait until Java gets their act together and finally implements extensions methods (aka: never)? Or switch to Kotlin?

Thanks,
Marc

PS: Just reported most of these as bugs, and also the PR for the annotation on interfaces.

[Chris Becker]

Extension Methods are actually the only aspect of Lombok I do use regularly.

And I love it.

I sometimes use other functionalities, too, and I love that they exist (hello @Builder, lazy @Getter and @With), but extension methods are what brought me here.

But just as you, I stumbled over lots of problems with the extension methods.

To your 3) when compiling the code, multiple overloaded methods, it does not select the method with the best fit, but just the first it gets its hands on (sequence of @ExtensionMethod({ X.class, Y.class })) .

Example:

@ExtensionMethod({ AObject.class, AString.class })

Compiles fine (Eclipse Build). But brings reliable runtime crashes, when it tries to cast an Object into a String or some other serious stack problems.

I have included the 3 example files, compiles fine with Eclipse, runs all my JREs into a JNI exception (some log files also included). Debugging is even worse, creates zombie apps, not responsive.

In some cases, reversing the arguments like

@ExtensionMethod({ AString.class, AObject.class })

was enough to prevent the runtime crash. But that's not really satisfying to me, leaves behind a bitter taste...

The second thing is: I learned quite fast that using any name that could occur in other (base) classes will create even more problems.

The way I'm going now is to use the Δ character in front of each method name, like so:

static public long ΔtoLong(final String pThis, final long pDefault) {

Due to Eclipse's nice auto-complete list, I still only have to type

toLong

but get the extension methods suggested farther down the list.

I'm writing most of my simple methods to be null-safe when possible, and for me it's good to see I actually use the proper methods, without having more typing to do.

So: yes, I'd really love an update on the extension methods, I am using them almost all of the time, and this is IMO the best feature Lombok brings along.

AND does it a lot better than AspectJ for example. With AspectJ I've run into so many problems so frequently that I simply will not use it anymore (at least until some major changes come along).

--
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/7abc9a99-ae4e-4389-b1b3-e38ed3c52bacn%40googlegroups.com.

--

Christian Becker
+49.176.2238 9755
chris.b...@gmail.com

[Marc Günther]

Hi Jay,

regarding the overloaded methods problem, there is a hidden setting, which fixed all of my problems:

https://github.com/projectlombok/lombok/issues/3261#issuecomment-1254129937

Basically you do:

@ExtensionMethod(value=MyExtensions.class, suppressBaseMethods=false)

You can give it a try if it helps with your specific problems as well? I'm using a patched version of the library, due to the interface fix, and I changed the default of that option, so I don't have to specify this everywhere.

Otherwise, yes, it's such a useful feature, it's a pity that apparently it is so complicated to implement and maintain. And almost no one is using it... ;-)

Marc

[Dirk Steinkamp]

Hi Marc,

I love extension methods, too!!! So we're at least three people ;-) ...

I stumbled upon some "special behaviour", too, but you did a much more thorough investigation!
For me it works fine in most cases, yet I agree edge cases need to be taken care of before promoting them out of experimental.

Dirk

[Michael Berry]

I'll pitch in as someone who doesn't use them. It's not just that it's experimental with some corner cases not covered for me - it just feels like too much of a "reach" for lombok IMHO.

Every other feature (that I use and see commonly used, in any case) is essentially bound to the class I'm annotating in some way. @ToString is adding a toString() method to that class, @Data is adding getters / setters / equals / hashcode to that class - etc. They're also reasonably obvious both in form and functionality - there's not many "special rules" to follow or remember.

Extension methods though are a different beast - suddenly through annotations I've potentially got very known standard library classes (like String) able to magically run methods that aren't on them - and there's not necessarily an obvious annotation telling me this is the case. As a developer, I'd have to understand the concept of extension methods (which might not be a given since they're not a "thing" in Java), have a look at the class(es) referenced by the @ExtensionMethod annotation, then also know that the static referenced method is being rewritten as an instance method which operates on its first argument.

In a solo project then sure, understand the rules and have at it - but in a corporate setting, it just strikes me as something that has the potential to cause more confusion than it solves.

To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/6c2c9418-7278-48f4-909a-1aa2eeaf3c69n%40googlegroups.com.

--

Thanks,

Michael

[Nawa]

I love extension methods. I wrote a blog about it years back : https://dzone.com/articles/lomboks-extension-methods .

Initially I promoted it to everyone ... but at some point I encounter compilation trouble which are really hard to debug/fix -- the error message is one the first line. So people complained to me a lot then :-(

Please keep the feature.

Thanks