dev/2018-April/023529.html
Thanks, Mandy. The proposed API looks great. Good luck with those
corner-cases in the implementation :-)
regards,
Andrew Dinn
---
e as a Java API).
The contents of each service file provides details of the service by
listing available providers i.e. names of classes which can be loaded
and instantiated to implement the interface/abstract class.
regards,
Andrew Dinn
---
On 11/09/16 22:17, mark.reinh...@oracle.com wrote:
> 2016/7/27 4:33:11 -0700, Andrew Dinn :
>> Regarding the proposed solution of adding method redefineModule to class
>> Instrumentation:
>>
>> I have a Proof Of Concept implementation which shows that that this
>>
tions then the existing solution will still stand. If
not then the original problem still needs resolving.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 13/09/16 15:40, Alan Bateman wrote:
> On 13/09/2016 15:28, Andrew Dinn wrote:
> We have a number of patches coming that will align the implementation
> with the current proposals and expect to have EA builds shortly too.
Excellent! Thanks for the very quick response.
regards,
An
ossible but ... really?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
the restrictions you are proposing and ii) (with or without
such compelling reasons) requiring that you either provide some means of
retaining in part or in whole the status quo. If you don't address these
points then I don't see that you can expect anything other than a
wholesale rejec
On 26/09/16 12:11, Alan Bateman wrote:
> On 26/09/2016 10:28, Andrew Dinn wrote:
>
>> :
>> I'm sorry, Alan ,but I think that is disingenuous. When we see "access
>> control" on this list all of us really ought to bear in mind what have
>> been the de
On 26/09/16 14:19, Alan Bateman wrote:
> On 26/09/2016 12:36, Andrew Dinn wrote:
>
>> :
>> I addressed that in the text you snipped. The one point of relevance is
>> that which the original poster asked about:
>>
>>-- Why do we need Jigsaw to constr
On 27/09/16 10:27, dalibor topic wrote:
> On 26.09.2016 18:37, Andrew Dinn wrote:
[snip]
>> I think those involved in this discussion already know all that you have
>> stated here regarding /what/ this project is doing. The present question
>> is /why/ is something th
pful explanation (n.b. I'm taking all
embedded questions as rhetorical). I hope it satisfies the original poster.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
e consumer module when there isn't
> explicit initialization. John Rose has good write-ups in JIRA with ideas
> in this area.
I'd be happy to try to conduct such an experiment. Can you provide links
to the relevant JIRAs.
regards,
Andrew Dinn
---
Senior Principal Softwar
On 28/09/16 19:09, Alan Bateman wrote:
> On 28/09/2016 13:22, Andrew Dinn wrote:
>> I'd be happy to try to conduct such an experiment. Can you provide links
>> to the relevant JIRAs.
> The javadoc for MethodsHandes.Lookup is probably the best place to
> start, assuming
he current jake tree. Unfoirtunately,
jigsaw-9ea-b136 does not yet contain a critical fix for a bug in
multi-rlelease jar processing. Once that is fixed I intend to publish
the code as part of Byteman release 4.0.0-BETA.
[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July
here it can or
cannot happen. That's certainly important for analyses which may help
performance optimization.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ect those dependencies (just like any other released artifact).
Where is the actual problem?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
that this is a deliberate choice of bootstrap loader
behaviour? Or is there perhaps some other bug here?
If this is a deliberate choice is there any possibility of reviewing it?
Would it be particularly difficult to modify the boot loader to
recognise jars in multi-release format?
Thanks in advance!
re
t because
I thought the multi-release option was a very neat solution that I
really ought to try to use
I envisaged that other agent implementors might not find it so easy to
encapsulate the required functionality
It's a shame multi-release won't work for all agents but never mind.
Th
agent you can use it to create
whatever lookups you need. However, depending on what John et al comes
up with by way of a privilege model for acquiring lookups it may avoid
the need to have an agent.
regards,
Andrew Dinn
---
ng there in the classpath.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ke forest.
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009860.html
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
mpiler. So
this creates opportunities for the compiler to optimize the code that
employs them. Accessible fields/methods/constructors are opaque to the
compiler which makes it much less likely that optimization will be possible.
regards,
Andrew Dinn
---
framework then arrange for that module to hand out Lookups (or better
MethodHandles) to framework code as and when they are needed via a
private channel. You can do arrange that with a single addExports option
on the command line and a very small amount of setup code to establish
the private channel
regards,
Andrew Dinn
---
Oops, wrong package! -- corrected inline
On 01/11/16 15:09, Andrew Dinn wrote:
> On 01/11/16 14:39, David M. Lloyd wrote:
>> On 11/01/2016 09:23 AM, John Rose wrote:
>>> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou wrote:
>>>>
>>>> Can we clari
On 01/11/16 15:35, David M. Lloyd wrote:
> On 11/01/2016 10:09 AM, Andrew Dinn wrote:
>> There is a very easy way to provide tightly controlled access to a
>> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g.
>> java.lang.[invoke].MethodHandles to a nominat
On 02/11/16 01:58, John Rose wrote:
> On Nov 1, 2016, at 12:02 PM, Andrew Dinn wrote:
>>
>> I did actually suggest a way of avoiding the use of Unsafe. You
>> give your nominated module full reflective access to
>> java.lang.invoke allowing it to create Lookup instanc
to resolution-time ambiguity.
n.b. the above only applies ot code in named modules; classpath
deployment still allows split packages and hence is still susceptible to
resolution-time ambiguity.
regards,
Andrew Dinn
---
some other problem will render it of no importance? If the
former can you explain why? If the latter can you explain what that
other problem is?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798
n't fix runtime ambiguity. So, if
your problem is runtime ambiguity then you'll still have to fix that.
But not being able to fix one mess doesn't mean Jigsaw is of no help for
another mess.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registe
is already treated as a spread call.
I'm not really sure why this is operating the way it does by wrapping
the String[] input in an Object[]. It seems that it may perhaps be an
artefact of trying to combine inexact invocation with duck typing for
generics. Am I doing something wro
up.findVirtual(method.getDeclaringClass(),
method.getName(),
methodType);
}
if (method.isVarArgs()) {
handle = handle.asfixedArity();
}
if (isStatic) {
handle.invokeWithArguments(args);
} else {
handle.bindTo(receiver)
ackaged up.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 07/01/17 15:10, Remi Forax wrote:
> Hi a
these proposed changes in full or maybe even sign up to the last of
these lists in order to monitor progress on work that still remains to
be completed.
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/
http://mail.openjd
vailable to
interested 3rd parties:
https://bugs.openjdk.java.net/browse/JDK-8162494
If you have any input to provide as to how this might be done without
(as John says) 'giving away the store' I am sure it would be listened to
with interest.
regards,
Andrew Dinn
---
Senio
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 cr
l that I need. I'll try it out asap.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
e glory of double billing yet corresponding
onus of double duty in the above help text -- which cannot be right.
Could you provide corrected details of the intended command line options
for the cases that have been elided?
regards,
Andrew Dinn
---
Senior Principal Software Engine
ell, maybe I need to say this -- yes, an easy start is a /big/
priority.
That's merely 2 cents, gratis. Your mileage may vary, particularly when
it fails for your app. But I don't the mere possibility of the latter as
a reason to poop on someone (everyone?) else's parade.
regards,
Andrew Dinn
---
list rather than just to you
directly so as to clarify the provenance of your post for those who are
still as confused as I was until I found David's original note on the
expert group list.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in E
and responding
*here* to a fragment of a thread posted *there* (on the EG list). If you
want to take part in a dialogue then directing your comments to another
room, albeit an adjacent one, generally falls somewhere between futile
and disruptive.
regards,
Andrew Dinn
---
Senior Prin
PMS. To me it is still an open question
whether EE actually needs the 'enhanced security benefits of JPMS
modules'. Contrariwise, it is *critical* for many other reasons that we
close out Java 9 and move on.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 22/03/17 11:42, Alan Bateman wrote:
> On your comment about neglect then you might want to look at JEP 264 [1].
> ...
> [1] http://openjdk.java.net/jeps/264
You might also want to look at this xkcd
https://xkcd.com/927/
which is, perhaps, just as relevant.
regards,
An
it's the best way we've
> found, so far, to preserve platform integrity in the face of dynamic
> agent loading. If there's a better way to do that, we'd like to know.
No, I don't think there is a better mechanism, only a better default.
That reflects my belief that, whi
Also, can you provide a reason why you are so agin agent-hoisting from
within a JVM? Is there a reason why it is such a cardinal sin?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
like, say, java.base) from an agent which has been dynamically
loaded might well be a workable compromise -- that at least allows users
to employ an agent to tweak any code that is in the classpath through
their choice.
However, whatever compromise we arrive at I'd certainly like time to
; aarch64 arm64
arm64 is *not* a correct name for the AArch64 architecture. There is in
fact no arm64 architecture. The latter name has been used to identify
the Oracle-developed port but that fact does not sanction its use for
OS_ARCH.
regards,
Andrew Dinn
---
Senio
e state without the contributions of Oracle staff and I for
one appreciate their contribution enormously.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Hi Mark,
Thanks again for another thoughtful and well-reasoned response.
On 03/04/17 23:36, mark.reinh...@oracle.com wrote:
> 2017/4/3 9:44:43 -0700, Andrew Dinn :
>> One thing I am not clear on as regards that 'really nice' is whether
>> anything in the JVM wants -- or
nd the new APIs.
. . .
Yes, please! I have been postponing a new Byteman release waiting for
this :-)
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("
its you seriously reviewing and definitely
confirming such an opinion before posting it.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ely if ever reached (never mind the problem
of maintaining such bliss).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
t; platform classes, so an additional mechanism to protect those classes
> does not appear to be worthwhile.
I'm happy with this although it might be worth reviewing it later.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
explicitly acknowledge what it is
doing (more precisely, to make those deploying the code be more explicit
about their intention to do so).
That's not such a terrible thing to transition to in the longer term,
assuming we are given time to manage the transition.
regards,
Andrew Dinn
pretty sure that you have found out that you
> cannot self attach, and are therefore already in the camp of knowing you are
> doing something bad.
This is a fair point.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales un
maintaining
two slowly diverging sets of classes. So, you might still want to
consider the approach I followed.
Your mileage (or madness) may vary.
regards,
Andrew Dinn
---
s
of the target class java.net.HttpURLConnection.
So, what am I asking:
Is there a clearer rationale for this check which might lead to a less
restrictive variant?
Can I haz it in jdk9 pleeze?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
pers. Of course, that
doesn't mean it won't have a knock-on effect for users of those agent
(perhaps a rather larger commmunity :-).
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
classes;
>> they
>> should somehow also be able to reflectively inspect those same classes!
>> But how? We ran into similar problems trying to port java agents at
>> Google
>> to jdk9.
>
> On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the
&g
hat is enough to get you started.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
It gets them for free.
To me this rather undermines the seriousness of the many claims that
automatic module naming is going to break everything. Once B is
modularised A needs to be rebuilt to explicitly import the packages it
exports. And so on up the line. Maybe I have got something wrong
r where we can never achieve important changes in
the JVM and JDK.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 25/04/17 09:19, Andrew Dinn wrote:
> This discussion really ought to be happening on the Byteman forum but
> anyway ...
>
> Yes, Alan is right that this is exactly what is going on. Byteman on
> jdk9 (the 4.0.0-BETA release series) now uses method handles in place
Hi Mandy,
On 02/05/17 03:37, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/
>
> . . .
Not an official review, I am afraid, but the patch looks good and is
much appreciated!
regards,
Andrew Dinn
---
Senior Princi
On 09/05/17 11:56, Alan Bateman wrote:
> On 09/05/2017 01:45, Martin Buchholz wrote:
>
>> On Tue, May 2, 2017 at 2:40 AM, Andrew Dinn wrote:
>>
>>> Just wanted to post a heads-up that this fall-back behaviour has now
>>> been implemented in Byteman relea
On 16/05/17 19:11, Gregg Wonderly wrote:
> If we really cannot actually keep from breaking 90% of existing Java
> in the market place when this new JDK release goes out, how valuable
> is JigSaw really?
citation needed?
regards,
Andrew Dinn
---
tes the potential for conflict on the
> command line. One thing that jlink could do is emit a warning that the
> resulting run-time image doesn't have the management and instrumentation
> features, might that be the right balance.
Like Remi, I think this is an entirely reasonable po
nfiguratons? Is there an
opportunity/need here to define and make visible a standard image format
('instrumentable') which comprises minimal + java.instrument?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ate all
Byteman users about the pitfalls that might accompany careless drawing
up of interior decor procedures. I don't really see why the JDK team
need to do that job for me.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales
(and I think they probably are)
then such a move would be as foolish as it is unlikely. Sorry but this
argument looks like FUD too.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
t, trading quality and reliability at the potential
cost of footprint. I'm very happy to compete on those terms.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
apps affected will be those which i) don't have an EE jar
on their classpath and ii) require the (partial) stub implementations
provided by Java SE. That sounds much better since such a configuration
is of almost no use to anyone and hence is very unlikely to arise.
regards,
Andrew Dinn
--
I am on the list so no need to include me specially in the CC.
Response to your questions are included inline below. Sorry for the
length of the reply -- it's really quite complicated (the first draft of
this reply was twice as long :-)
regards,
Andrew Dinn
---
Senior Principal Sof
On 20/04/16 12:40, Alan Bateman wrote:
>
> On 19/04/2016 18:00, Andrew Dinn wrote:
>> :
>> I have been building and testing on JDK9 Byteman using the EA program
>> releases and have not seen anything break so far. However, that may just
>> be because i) Byteman
gent jar and instantiating the relevant management classes
indirectly according to whether modules are present or not. That will
ensure that the JDK9(+)-compiled classes are not loaded when running on
JDK8(-).
Thanks once again for your, as ever, very helpful insights.
regards,
Andrew Dinn
---
and don't see it
when I leave them in the system classpath.
I will be happy to validate any fix.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
thesis that for now, at least,
making this method say 'yes' is not going to break anything that could
not already potentially be broken -- in particular it's not going to
foil the expectations of the JIT (yet? :-).
So, I'd be very interested to know how horrified you
used by Byteman? If so then can I take a peek?
(and maybe steal it :-)
regards,
Andrew Dinn
---
le checks. Of course, I'd prefer that
we adopt this on its merits rather than by resort to mob rule^H^H^H^H
democracy.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 05/05/16 20:50, Alan Bateman wrote:
>
> On 05/05/2016 17:31, Andrew Dinn wrote:
>> :
>>
>> I looked at several ways of making this work and decided the best thing
>> was to have the agent redefine AccessibleObject.checkCanSetAccessible so
>> that it g
so as to grant access to 'trusted' code.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ry unattractive proposition since it
complicates both development and deployment.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
to cause my
employer a problem). If you could acknowledge that permission then I'll
be able to click on the link.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
On 06/05/16 09:37, Alan Bateman wrote:
> On 06/05/2016 09:16, Andrew Dinn wrote:
>> :
>> Yes, that's probably the best way to restrict access if you assume the
>> agent is itself in a Jigsaw module.
> Your agent may not be in a named module but it will be in an unname
Hi Peter,
On 06/05/16 15:34, Peter Levart wrote:
> On 05/06/2016 10:07 AM, Andrew Dinn wrote:
>> Not yet but I will do. n.b. for all practical purposes there is only one
>> Byteman module although which one it is depends upon whether the agent
>> jar is hoisted into the bo
module? If
so then is there a switch (equally as well hidden :-) which allows me to
re-instate them? If not then does anyone have any idea why are we seeing
these missing package errors?
n.b. please keep Mike Musgrove in the cc for any replies as he is not
subscribed to this list.
regards,
A
ernatrive ORB jar to the system
classpath then we will actually be safe. If you have reason to believe
otherwise please let me know. Meanwhile, I'll get back to you if and
when this turns into a packed lunch problem. Thanks for the help.
regards,
Andrew Dinn
---
Senior Principal So
ev which
implements what would be needed to provide the necessary capability via
Instrumenatation.
regards,
Andrew Dinn
---
On 24/05/16 19:28, Alan Bateman wrote:
> On 24/05/2016 16:51, Andrew Dinn wrote:
>> :
>>
>> Given the impending guillotine for completion of JDK I intend to raise a
>> JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as
>> still needing a fix
condition? If the latter then how will the
condition be widened?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ially
those who have implemented agents -- need to discuss whether the
resulting breakage of existing functionality is acceptable. That sort of
decision cannot be arrived at as a fait accompli simply by virtue of the
fact that your envisaged Jigsaw design will produce it as a side effect.
re
hout using Unsafe.
#2 is no good for Java agents which want to (re)transform an already
loaded class. That's not just an issue for dynamically loaded agents.
Even when the agent is loaded on the command line it may need to modify
a class which has already been loaded like, say, clas
On 02/06/16 14:32, Alan Bateman wrote:
> On 02/06/2016 13:53, Andrew Dinn wrote:
>> #2 is no good for Java agents which want to (re)transform an already
>> loaded class. That's not just an issue for dynamically loaded agents.
>> Even when the agent is loaded on the c
o the JDK? Is the plan to release what we have
now and then try to back-patch fixes? That sounds to me like it would be
a very bad move for JDK9 and, indeed, Java as a whole. What's the
alternative plan?
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
mmand line argument or to
the VM_Attach dynamic load API.
regards,
Andrew Dinn
---
On 16/06/16 12:46, Alan Bateman wrote:
>
> On 16/06/2016 10:11, Andrew Dinn wrote:
>> :
>> Ok, so now the bonus question:
>>
>> Does that mean that it is not possible to implement a Java JVMTI agent
>> as Jigsaw modularised code?
>>
>> I'll a
ent method would go some way to
> help with this issue.
I agree this would be very helpful.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
ovide an API to add a module to the
module path at runtime?
Alternatively, perhaps the proposed API could be used to define a new
module at runtime as well as to redefine an existing one? That still
leaves the question of how to populate that module with one or more classes.
regards,
Andrew Dinn
create a module at runtime? I did not think that was
possible. I think that would be by far the best option for me and it
would also make the current proposal acceptable.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under C
ired classes in a
dynamically created module). Remi's reply seems to indicate that I can
do this using the Layer API. I will take a look at that to see what it
allows me to do.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales un
anize feedback on the proposed changes from
affected JBoss developers but it is taking some time to canvas views and
get the relevant devs to formulate a response. I am hoping you will
receive something within the next few days.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
1 - 100 of 131 matches
Mail list logo
