You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by 雷威 <le...@gmail.com> on 2018/03/23 07:17:04 UTC
Re: [apache/incubator-dubbo] [Suggestion] What about migrating from
Javassist to Byte Buddy (#1504)
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 <no...@github.com>:
> 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
> dev@dubbo.apache.org 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>
> .
>
Re: [apache/incubator-dubbo] [Suggestion] What about migrating from
Javassist to Byte Buddy (#1504)
Posted by shang zonghai <yi...@hotmail.com>.
+1， The Runtime code generation should be reconstructed into “SPI”, the dubbo framework itself is designed to be highly scalable.
> 在 2018年3月26日，11:37，jun liu <ke...@gmail.com> 写道：
>
>> 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.
>
>> 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.
>
> In fact, it’s already been designed as a SPI, see ProxyFactory[1], Compiler[2].
>
Re: [apache/incubator-dubbo] [Suggestion] What about migrating from
Javassist to Byte Buddy (#1504)
Posted by jun liu <ke...@gmail.com>.
> 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.
> 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.
In fact, it’s already been designed as a SPI, see ProxyFactory[1], Compiler[2].
> 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.
By default, “jdk” extension will be used as the default proxy mechanism, most users don’t have to know about it.
For dubbo, code generation only affects the speed at start-up, so I think we should care more about stability than performance. Since it is an SPI extension point, there’s no harm with one more choice.
[1]. https://github.com/apache/incubator-dubbo/blob/master/dubbo-rpc/dubbo-rpc-api/src/main/java/com/alibaba/dubbo/rpc/ProxyFactory.java <https://github.com/apache/incubator-dubbo/blob/master/dubbo-rpc/dubbo-rpc-api/src/main/java/com/alibaba/dubbo/rpc/ProxyFactory.java>
[2]. https://github.com/apache/incubator-dubbo/blob/master/dubbo-common/src/main/java/com/alibaba/dubbo/common/compiler/Compiler.java <https://github.com/apache/incubator-dubbo/blob/master/dubbo-common/src/main/java/com/alibaba/dubbo/common/compiler/Compiler.java>
> On 23 Mar 2018, at 3:17 PM, 雷威 <le...@gmail.com> wrote:
>
> 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 <no...@github.com>:
>
>> 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
>> dev@dubbo.apache.org 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>
>> .
>>