Good idea. But I am not sure whether the runtime code generation is a SPI or not. That is to say, should we regard the bytecode generation implementation as an extension point. The implementation of bytecode generation is too low level, and user should not touch this. It should be transparent to users. Maybe user don't care it at all, or there is no real scenario that user indeed want to change it. Just give users what they indeed need, to keep our product simple, stable, and easy to use. This is my own option. So my idea is that Dubbo only keep one built in impl, I prefer Byte Buddy. And currently, Dubbo don't expose this extension. If the community want this extension, we can consider to add it by SPI. Or we can seperate these extensions from Dubbo core. Most user just need the default impl, and don't need to import those extra classes or jar.
2018-03-23 14:23 GMT+08:00 ken.lj <[email protected]>: > Instead of replacement, how about add a new extension with Byte Buddy > using Dubbo's SPI. > > @vangoleo <https://github.com/vangoleo> Let's bring this awesome idea to > [email protected] for further discussion. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/apache/incubator-dubbo/issues/1504#issuecomment-375556826>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AB7_8kR0Y0GGC02W6-aX8zsMPRVMcTIkks5thJTfgaJpZM4S4LD9> > . >
