Autogenerate Interfaces

[deniswsrosa]

Hi guys, I would like to implement a new feature in lombok to generate interfaces automatically, say if you have a class named MyServiceImpl I would like to generate its interface "MyService" with all public methods of "MyServiceImpl" declared in it.

Does it make sense? have you tried to do that in the past?

[buckett]

There is https://github.com/peichhorn/lombok-pg/wiki/%40AutoGenMethodStub but the lombok-pg project currently seems to be unmaintained and doesn't work with Java 8.

[Maaartinus]

IIUIC @AutoGenMethodStub does the opposite: It adds methods present in an interface to a given class.

AFAIK interface generation can be done easily using a (standard) annotation processor - unless you want to generate the interface in the same source file, which you probably don't. Surprisingly, I can find no such annotation processor, but it sounds like the simplest useful annotation processor possible.

As lombok never generates new source files, I guess, it doesn't really fit.

[buckett]

@Maaartinus Ok yes, although you can get close by creating an empty class:

@AutoGenMethodStub
public class MyServiceImpl implements MyService {
}

This is helpful where you want to implement a few methods but don't want to clutter up a class with lots of methods just returning default values.

[xdhmoore]

I think generating interfaces could be useful in Spring where if you want to use the normal proxying method, you end up creating a lot of interfaces for service classes that only have one implementation.

[Maaartinus]

@xdhmoore Shouldn't Spring be fixed instead? Java can proxy classes as well as interfaces. Sure, java.lang.Proxy can't, but why should I care? That's what libraries (e.g., Spring :D) are for (I may be wrong, there may be performance differences or whatever; I don't know).

[jasonab]

I love how @RequiredArgsConstructor works well with Spring's constructor-based autowiring, and I agree that this annotation would fix a lot of copy and paste to update interfaces for Spring.

[janrieke]

I think that it is not a very common use case, and it is one that does not help very much to write good code. Furthermore, I fully agree to what @Maaartinus said: It should be relatively easy to write a standalone annotation processor to achieve this; Lombok, in contrast, is designed to perform inline modifications, not to generate new files.

As annotation processors are executed in rounds, such a processor should also work in combination with Lombok.

[randakar]

Those interfaces are not really necessary. I've taken to eliminating those in all our spring projects and things work just fine. That which serves no purpose should be eliminated.

On Sat, Mar 2, 2019, 10:30 Jan Rieke notifications@github.com wrote:

I think that it is not a very common use case, and it is one that does not help very much to write good code. Furthermore, I fully agree to what @Maaartinus https://github.com/Maaartinus said: It should be relatively easy to write a standalone annotation processor to achieve this; Lombok, in contrast, is designed to perform inline modifications, not to generate new files.

As annotation processors are executed in rounds, such a processor should also work in combination with Lombok.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rzwitserloot/lombok/issues/1320#issuecomment-468903993, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKCRQy7Jq2dz1Mf82Wq_8houLhWqMYXks5vSkSbgaJpZM4MPWjJ .

[xdhmoore]

After looking at the Spring docs again, I still think this an interesting idea. However, it sounds like regardless of whether or not it's a good idea, that Lombok isn't the place for it because it doesn't generate new files.

@janrieke By standalone annotation you mean the stuff in javax.annotation.processing?

[janrieke]

Yes, create your own annotation processor (and define your own annotation to process), and let it generate the interface from classes with your annotation. The concept of annotation processors was designed exactly for such a task.

[IZWO]

As a use case, I have often XXXImpl and need to make the interface XXX manually, so that I can use it in code and generate Mock Objects for test classes.
Therefore I like the idea of @InterfaceOf or @ExtractInterface to generate interfaces.
See also the discussion https://groups.google.com/g/project-lombok/c/VduInQQH9bg/m/6RxFdqhJAwAJ
Should this not be generally available?
But if you can send me a link how I can do it with standard annotations, this is also good.

[acrazing]

@AutoGenMethodStub really useful. Is there any updates?

Consider a scenario where the interface definition and implementation are in two different repositories. You are developing the interface implementation part. One day, someone updates the interface definition adds a new method and have not yet had time to implement the method. At this time, your part will not be compiled unless you manually implement this new method.

This is why grpc-go introduced the require_unimplemented_servers option.

[dstango]

@AutoGenMethodStub really useful. Is there any updates?

Consider a scenario where the interface definition and implementation are in two different repositories. You are developing the interface implementation part. One day, someone updates the interface definition adds a new method and have not yet had time to implement the method. At this time, your part will not be compiled unless you manually implement this new method.

I'd understand the scenario, but would suggest to ask the interface-developer to add empty default implementations to the interface to remain backwards compatible to existing implementations ... that's what was done in the standard library when quite some existing interfaces were retrofitted to support some functional programming features in Java 8 ... (yes, I know: influence on other people is limited ;-) ...)

[borkabu]

This annotation (@AutoGenMethodStub) would be useful for interfaces which did not originate from Java. For example, Apache Thrift. My use case is that there is Thrift API for some service. The hassle comes from integration tests, where I have a stub service, where I need to override those few methods I actually use. Other 200 methods are just stubs which throw UnimplementedMethod exception. Do not see how that would be different from generating Getters/Setters in Lombok.