On 15 June 2017 at 21:31, Jeremy Manson wrote:
> My initial thought in this general direction was to write a JVMTI agent
> that takes a list of JAR files as arguments. It then does two things:
>
> - Intercepts all loads of classes using the ClassFileLoadHook, checks to
> see if there is a class w
On 16/06/2017 10:26, Michael Rasmussen wrote:
:
If going that route, then there are 3 capabilities added with JVMTI 9
that you should look into, in order to be able to intercept the
loading of the very early classes as well (Object, String, Class etc):
can_generate_early_vmstart
can_generate_all_
Hey Alan,
Thanks. We'd been tossing that around in the list of possibilities, but
hadn't gotten far enough to think about whether it would be easier or not.
My initial thought in this general direction was to write a JVMTI agent
that takes a list of JAR files as arguments. It then does two thin
On 15/06/2017 01:00, Jeremy Manson wrote:
:
The upshot is that, in the same way as we would have turned on the big
kill switch by default to ease the transition, we are also likely to
implement -Xbootclasspath/p to ease the transition.
You might find it easier to add --patch-module to your JDK
On 14/06/2017 00:57, Jeremy Manson wrote:
Hey folks,
As a followup to this, given everything else that has happened in the mean
time: I wonder if the same logic Mark put in his proposal to allow illegal
access to internal APIs (
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.
e-libs-dev"
> Envoyé: Mercredi 14 Juin 2017 01:57:55
> Objet: Re: Accessing module internals from bytecode rewriting agent
> Hey folks,
>
> As a followup to this, given everything else that has happened in the mean
> time: I wonder if the same logic Mark put in his pro
Another way to think about transition to a new JDK is to treat the new
release JDK N as a "better JDK N-1". You still target JDK N-1 at build
time but get performance and quality improvements from the JDK N runtime,
running along with JDK N-1 for years. Then every small incompatibility is
a big n
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 release 4.0.0-BETA5.
Thanks - I can confirm 4.0.0-BETA5 works for me.
On Mon, May 8, 2017 at 5:54 AM, dalibor topic
wrote:
> On 05.05.2017 08:39, Jeremy Manson wrote:
>
>> Mostly, I'm telling you all because I think it makes an interesting case
>> study - a large Java installation and the issues it faces trying to roll
>> out JDK 9.
>>
>
> Indeed - thank you for pr
On 05.05.2017 08:39, Jeremy Manson wrote:
Mostly, I'm telling you all because I think it makes an interesting case
study - a large Java installation and the issues it faces trying to roll
out JDK 9.
Indeed - thank you for providing valuable insight into your concerns and
experiences.
If oth
Hi Jeremy,
I think your email points out *why* turning this on out of the blocks is going
to make things a ton more difficult. IMHO, 9 needs to be opt-in rather than
opt-out. By 10 I think we’ll be ready for opt-out rather than opt-in.
Kind regards,
Kirk Pepperdine
> On May 5, 2017, at 8:39 AM
On 02.05.2017 18:46, Jeremy Manson wrote:
People
are using Xbootclasspath for a variety of things.
It's worth keeping in mind when using such options that
"Non-standard options are general purpose options that are specific to
the Java HotSpot Virtual Machine, so they are not guaranteed to be
On 02/05/2017 19:00, Remi Forax wrote:
Hi Kirk,
--patch-module both at compile time and at runtime is what your are looking for.
Right, and more details in the "Patching module content" section of JEP
261 [1].
-Alan
[1] http://openjdk.java.net/jeps/261#Patching-module-content
017 19:50:50
> Objet: Re: Accessing module internals from bytecode rewriting agent
> Hi Alan,
>
> One of the techniques that I’ve used in the past for troubleshooting is to
> prepend modified classes to the bootstrap class path. I fear all this mucking
> about with modularization is
Hi Alan,
One of the techniques that I’ve used in the past for troubleshooting is to
prepend modified classes to the bootstrap class path. I fear all this mucking
about with modularization is going to leave the road to diagnostics littered
with a ton of tools that will not longer work. As it is,
On Tue, May 2, 2017 at 2:15 PM, Paul Sandoz wrote:
> At one point we were mulling back porting the Java 9 runtime changes to
> Java 8 and therefore we could go back to Java 7, but we decided not to
> proceed with that, which is what i suspect you may be thinking about.
>
>
Yes, I was hopeful abou
> On 2 May 2017, at 09:45, Michael Nascimento wrote:
>
> On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote:
>
>> 8 can deal with multi-release JARs.
>>
>
> I missed that. Starting with what update? Is there any link I could use to
> share this info?
>
There have been no modifications to t
On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote:
> 8 can deal with multi-release JARs.
>
I missed that. Starting with what update? Is there any link I could use to
share this info?
Regards,
Michael
8 can deal with multi-release JARs. The extra goop is ignored. So a
7/8/9 MRJar is perfectly possible (and in fact, the whole point of doing
them in the first place, so library writers could publish JARs that span
7/8/9.)
On 5/2/2017 2:50 AM, Jeremy Manson wrote:
Maybe when there's something
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 of
> reflection. Unfortunately
On 02/05/2017 07:50, Jeremy Manson wrote:
:
If we follow this path, before we migrate to Java 9, we would need to
make sure all of our code builds and the tests pass with Java 9 and
Java 8. We can't make all of the code build and the tests pass with
Java 9 as-is, because many of them use opt
Maybe when there's something breaking in Java 10 or 11, I can do that.
Right now, that approach requires me to have a fork of my code, have
special build goop, rely on yet another Java 9 feature, and make my
relatively widely used OSS project require Java 9 to build *prior to Java
9's release -* ju
Or use multi-release JARs.
On 4/25/2017 3:14 AM, Jeremy Manson wrote:
I guess I can call it reflectively.
Thanks, all. I should have remembered the special casing of
java.util.concurrent in checkUnprivilegedlookupClass. It's surprising to
see different behavior crossing the java.util.concurrent boundary, as I
observed trying to access PriorityQueue.queue (fails!) vs.
PriorityBlockingQueue.queue (succ
[...]
>
> Meanwhile, Mandy Chung has kindly offered to look into the security
> considerations that are at play and come up with a less restrictive
> policy which enforces the security needs more accurately. At that point
> I will probably remove the fallback -- in part because I hope that by
> t
On 25/04/17 07:22, Alan Bateman wrote:
> On 25/04/2017 04:26, Martin Buchholz wrote:
>
>> :
>>
>> java.lang.IllegalArgumentException: illegal lookupClass: class
>> java.util.PriorityQueue
>>
>> Bytecode rewriting agents have the power to inject code into classes;
>> they
>> should somehow also be
Thanks.
It wouldn't have occurred to me that I needed to use a Java 9 API. I can't
remember ever having an upgrade path for anything in any Java version for
which I couldn't use the same code in Java N and Java N+1, if the use case
was a supported part of the spec in both.
The usual migration pa
On 25/04/2017 07:29, Jeremy Manson wrote:
Ah, then it sounds as if I just don't know what I'm doing. Any pointers?
This should help:
http://download.java.net/java/jdk9/docs/api/java/lang/instrument/Instrumentation.html#redefineModule-java.lang.Module-java.util.Set-java.util.Map-java.util.Map
Thanks, Alan. I don't use byteman, and my agent wasn't working out of the
box to redefine JDK classes... I guess I can keep digging.
Jeremy
On Mon, Apr 24, 2017 at 11:35 PM, Alan Bateman
wrote:
> On 25/04/2017 07:22, Jeremy Manson wrote:
>
> :
>>
>> The instrument API specifically supports a
On 25/04/2017 07:22, Jeremy Manson wrote:
:
The instrument API specifically supports a Boot-Class-Path attribute in the
MANIFEST, as well as Instrumentation.appendToBootStrapClassLoaderSearch. I
had been using that as a way to make it possible to rewrite JDK internals
(add allocation instrumen
On 25/04/2017 04:26, Martin Buchholz wrote:
:
java.lang.IllegalArgumentException: illegal lookupClass: class
java.util.PriorityQueue
Bytecode rewriting agents have the power to inject code into classes; they
should somehow also be able to reflectively inspect those same classes!
But how? We r
31 matches
Mail list logo
