You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/11/25 08:18:57 UTC
[proxy]
Hello guys,
Maybe too early and I'm pretty I'll not get time to work on it in the
following months but saw yesterday jdk8 contains asm repackaged:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b
This could be great for [proxy] to support it in main module and avoid
the need to add any bytecode library from the user perspective no?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy]
Posted by Matt Benson <gu...@gmail.com>.
It might be interesting to have a version of the ASM impl that could be
available automatically in such an environment, yes.
Matt
On Mon, Nov 25, 2013 at 6:21 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Your initial statement is right however I don't get why we shouldn't
> do it. basically same applies for Unsafe which is used by all
> frameworks. I don't say we should drop spi to use it, just we should
> support it as a base when nothing is provided. IMO this would really
> simplify the setup of [proxy]
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2013/11/25 sebb <se...@gmail.com>:
> > On 25 November 2013 07:18, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
> >> Hello guys,
> >>
> >> Maybe too early and I'm pretty I'll not get time to work on it in the
> >> following months but saw yesterday jdk8 contains asm repackaged:
> >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b
> >>
> >> This could be great for [proxy] to support it in main module and avoid
> >> the need to add any bytecode library from the user perspective no?
> >
> > However, it looks like this is part of the intermal workings of JDK8.
> >
> > Unless there is a public API, it would tie proxy to working with one
> > particular Java implementation.
> >
> > I don't think we should do that.
> >
> >> Romain Manni-Bucau
> >> Twitter: @rmannibucau
> >> Blog: http://rmannibucau.wordpress.com/
> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> >> Github: https://github.com/rmannibucau
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy]
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Your initial statement is right however I don't get why we shouldn't
do it. basically same applies for Unsafe which is used by all
frameworks. I don't say we should drop spi to use it, just we should
support it as a base when nothing is provided. IMO this would really
simplify the setup of [proxy]
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/25 sebb <se...@gmail.com>:
> On 25 November 2013 07:18, Romain Manni-Bucau <rm...@gmail.com> wrote:
>> Hello guys,
>>
>> Maybe too early and I'm pretty I'll not get time to work on it in the
>> following months but saw yesterday jdk8 contains asm repackaged:
>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b
>>
>> This could be great for [proxy] to support it in main module and avoid
>> the need to add any bytecode library from the user perspective no?
>
> However, it looks like this is part of the intermal workings of JDK8.
>
> Unless there is a public API, it would tie proxy to working with one
> particular Java implementation.
>
> I don't think we should do that.
>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy]
Posted by sebb <se...@gmail.com>.
On 25 November 2013 07:18, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Hello guys,
>
> Maybe too early and I'm pretty I'll not get time to work on it in the
> following months but saw yesterday jdk8 contains asm repackaged:
> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b
>
> This could be great for [proxy] to support it in main module and avoid
> the need to add any bytecode library from the user perspective no?
However, it looks like this is part of the intermal workings of JDK8.
Unless there is a public API, it would tie proxy to working with one
particular Java implementation.
I don't think we should do that.
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org