On 10/01/17 17:54, Alan Bateman wrote:
> Could you use MethodsHandles.privateLookupIn here instead?
Ah, that's very interesting! -- I have been on holiday since the start
of December so I missed seeing this get pushed into JDK9. Thanks for
pointing it out.
I believe this API will do all that I ne
On 10/01/2017 17:16, Andrew Dinn wrote:
:
The version which uses Lookups only needs to tweak the exports for one
module i.e. java.base. It modifies java.base to 'export open' package
java.lang.invoke to the Byteman module. That then allows Byteman to call
the private constructor for MethodHandle
On 10/01/17 16:48, Jochen Theodorou wrote:
> On 10.01.2017 15:40, Andrew Dinn wrote:
> [...]
>> That's possible because an agent can use its Instrumentation instance to
>> 'export open' the MethodHandles package to a module of its own making
>> and then create the Lookup from within that module.
>
On 10.01.2017 15:40, Andrew Dinn wrote:
[...]
That's possible because an agent can use its Instrumentation instance to
'export open' the MethodHandles package to a module of its own making
and then create the Lookup from within that module.
but that won't work for me in Groovy as a library. T
On 10/01/17 13:51, Jochen Theodorou wrote:
. . .
> I guess the trick is that I am using reflection to get a Lookup object
> that has full priviledges... a trick that does no longer work in current
> jigsaw
You /can/ use this trick if you have an agent. I do so in my latest
Byteman prototype (not
On 10.01.2017 12:28, Uwe Schindler wrote:
Hi,
just coming to the example you brought, because I exercised this a week ago:
[...] For example... can you
call Object#clone on Object using MethodHandles? I actually did not try
this, but since the method is protected and in a module I would assu
Hi,
just coming to the example you brought, because I exercised this a week ago:
> [...] For example... can you
> call Object#clone on Object using MethodHandles? I actually did not try
> this, but since the method is protected and in a module I would assume
> no. You had been able to do so by re
On 09.01.2017 12:47, Andrew Dinn wrote:
[...]
If you carefully review discussion on the subject of this (slightly
false) dichotomy between static and dynamic capabilities I think you
will find that there has been a lot of explicit discussion. In my view,
your summary of the status quo is at best
On 09/01/17 09:53, Alessio Stalla wrote:
> Jochen, what you say resonates with me a lot too. And though I don't want
> to hijack the thread to a pointless Java-is-dying flame, I have to say one
> thing:
> Java won because of its (imperfect, but surprisingly usable and versatile)
> balance between s
De: "Alessio Stalla"
> À: "Alan Bateman"
> Cc: "jigsaw-dev"
> Envoyé: Lundi 9 Janvier 2017 10:53:50
> Objet: Re: Suggestion: allow accessible reflection on protected methods of
> exported types.
> Jochen, what you say resonates with me a lot too.
Jochen, what you say resonates with me a lot too. And though I don't want
to hijack the thread to a pointless Java-is-dying flame, I have to say one
thing:
Java won because of its (imperfect, but surprisingly usable and versatile)
balance between static and dynamic. And lots of marketing, of course
On 03/01/2017 18:13, Jochen Theodorou wrote:
You sound as if there are equal good alternative solutions to all
these cases. For example changing the environment for a subprocess
after its creation No, there is no clean solution. The only
solution that does not require an opens is to do i
On 03.01.2017 18:04, David M. Lloyd wrote:
[...]
Here's an important point about adoption (these are my own observations,
not the EG's or my employer's). One of the effects of the way Java is
produced and its historical entrenchment is that no matter what happens,
adoption is more or less inevit
Hi,
> From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of
> Alan Bateman
> On 29/12/2016 16:24, Rafael Winterhalter wrote:
>
> > :
> >
> > I argue that this module system should not be responsible to assert the
> > usage of such protected methods on exported types. Such m
On 03.01.2017 17:28, Alan Bateman wrote:
On 29/12/2016 16:24, Rafael Winterhalter wrote:
:
I argue that this module system should not be responsible to assert the
usage of such protected methods on exported types. Such methods are not
really encapsulated as they are considered official API by
On 12/29/2016 01:09 PM, Jochen Theodorou wrote:
On 29.12.2016 18:24, Rafael Winterhalter wrote:
Hei Jochen, thank you for your feedback. I must have missed your
posting, I regularly fail to follow up on the things discussed on the
mailing list and its not easy to seatch for topics, sorry for tha
On 29/12/2016 16:24, Rafael Winterhalter wrote:
:
I argue that this module system should not be responsible to assert the
usage of such protected methods on exported types. Such methods are not
really encapsulated as they are considered official API by subclasses.
Right, they are intended to be
I really hope that some official API makes the cut.
In the case of defineClass, java.lang.reflect.Proxy also needs this
functionality, and uses its own native defineClass0 in order to inject the
proxy classes into the correct class loader.
I don't know if making that defineClass method accessible
(Accidental enter hit during my last mail.)
To give a short update on this:
I have now updated my code generation library Byte Buddy to fallback to
sun.misc.Unsafe::defineClass for injecting types. I find this really
unfortunate as I managed to avoid using Unsafe in Byte Buddy in five years
and I
manner would be the much preferred outcome.
2016-12-29 19:17 GMT+01:00 Remi Forax :
> - Mail original -
> > De: "Rafael Winterhalter"
> > À: "jigsaw-dev"
> > Envoyé: Jeudi 29 Décembre 2016 17:24:55
> > Objet: Suggestion: allow accessible refl
On 29.12.2016 18:24, Rafael Winterhalter wrote:
Hei Jochen, thank you for your feedback. I must have missed your
posting, I regularly fail to follow up on the things discussed on the
mailing list and its not easy to seatch for topics, sorry for that.
don´t worry, my complaints have not been ign
- Mail original -
> De: "Rafael Winterhalter"
> À: "jigsaw-dev"
> Envoyé: Jeudi 29 Décembre 2016 17:24:55
> Objet: Suggestion: allow accessible reflection on protected methods of
> exported types.
> Hello everybody,
Hi Rafael,
>
> I
Hei Jochen, thank you for your feedback. I must have missed your posting, I
regularly fail to follow up on the things discussed on the mailing list and
its not easy to seatch for topics, sorry for that.
In Byte Buddy, I created an option to use subclassing by creating dedicated
class loaders for p
On 29.12.2016 17:24, Rafael Winterhalter wrote:
Hello everybody,
I did another round of testing a recent build of Java 9 with some
applications and framework that I work with or maintain. I ran into an
issue that I consider rather severe and I want to make a suggestion on how
to potentially solv
Hello everybody,
I did another round of testing a recent build of Java 9 with some
applications and framework that I work with or maintain. I ran into an
issue that I consider rather severe and I want to make a suggestion on how
to potentially solve this problem.
Some libraries entertain utilitie
25 matches
Mail list logo
