@Configuration interface with Java 8 default methods (as a standalone artifact) [SPR-14220]

[spring-projects-issues]

joerg.hohwiller@googlemail.com opened SPR-14220 and commented

#15547 brought an awesome improvement to support @Bean in Java8 default methods of interfaces. In the end I currently still have to implement an @Configuration class that implements the interfaces. Assuming that all methods of the interface(s) are default method implementing the @Configuration class is just unnecessary code if it just implements one interface. Why not have support directly for

@SpringApplicationConfiguration(classes = MyConfigInterface.class)

This was already slightly discussed in #15547 but considered out of scope.

The major advantage of (miss)using interfaces for configs is that you can:

• use inheritance instead of @Import what is more natural and even more safe as the compiler can detect conflicts.
• as an end-user of a flexible designed library just define your config by extending according @Configuration interfaces from the library but still selectively override @Bean methods where ever you want to customize. When using @Import this is not easily possible.
• as an author of a library you can provide your @Configuration objects in such a flexible way as interfaces but without the burden to have a corresponding class for each interface that does noting but implement the interface. If you have a very modular library you might have many @Configuration objects (see e.g. add spring @Configuration classes m-m-m/util#178).

To summarize I like to propose that with Java8 the interface is the new top-level language element. It would be great to see this even more supported by spring. I already use default methods to implement QueryDSL queries in default methods with pure interfaces and no single repository implementation class. This already works today with current spring releases (Thanks guys for your great work). See also m-m-m/util#163 for more advanced usage of Java8 interfaces.

---

Affects: 4.2.5

Issue Links:

• @Configuration(prefix = "aabb") (or: how to create reusable configurations) [SPR-14103] #18675 @Configuration(prefix = "aabb") (or: how to create reusable configurations)
• Introduce a mechanism for abstract types at component scanning [SPR-11663] #16286 Introduce a mechanism for abstract types at component scanning
• @Bean on Java 8 default methods in interfaces [SPR-10919] #15547 @Bean on Java 8 default methods in interfaces
• Add a functional way to register a bean [SPR-14832] #19398 Add a functional way to register a bean

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

The technical complexity involved at runtime is quite a warning sign: We'd have to create a dynamic proxy and then dispatch to default methods via MethodHandle-triggered invokespecial operations. We're not doing anything like this all over the core framework, so it seems unclean to start doing it here.

Also, our configuration class model is complex enough already. Adding one more variant - in particular one that is not idiomatic in Java to begin with - doesn't seem right from this perspective either. Our focus is rather on functional bean registration mechanisms (#19398) these days.

All in all, I'm afraid there are currently no intentions to make such interface-only configuration artifacts work.

[spring-projects-issues]

joerg.hohwiller@googlemail.com commented

OK. Thanks for considering. I will create a dynamic proxy factory myself and try to find a way to create a simple @Configuration bean class that does nothing but creating the proxy from the interface and then plugging this into spring via context aware interface. Hope this will work...
Otherwise I would go for isolated spring-boot auto starters...