> On Mar 9, 2016, at 11:13 AM, Alan Bateman wrote:
>
>
>
> On 09/03/2016 18:01, Mandy Chung wrote:
>> what about sun.tools.vm.spi? jdk.internal.vm.agent.spi (instead of
>> jdk.internal.vm.spi which seems to be a generic VM SPI rather than specific
>> to tools?)
> As the tools are in sun.tool
On 09/03/2016 18:01, Mandy Chung wrote:
what about sun.tools.vm.spi? jdk.internal.vm.agent.spi (instead of
jdk.internal.vm.spi which seems to be a generic VM SPI rather than specific to
tools?)
As the tools are in sun.tools. and the SA tool classes are in
sun.jvm.hotspot.tools then this nam
> On Mar 9, 2016, at 1:39 AM, Alan Bateman wrote:
>
>
>
> On 08/03/2016 23:00, Mandy Chung wrote:
>>> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote:
>>>
>>> In order, then my preferences for resolving this are:
>>>
>>> 1. Compete the tool separation, meaning JDK-8059035.
>>>
>>> 2. Change
On 08/03/2016 23:00, Mandy Chung wrote:
On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote:
In order, then my preferences for resolving this are:
1. Compete the tool separation, meaning JDK-8059035.
2. Change these tools to use services so that the SA backend is a service
provider.
#2 seems
Hi Mandy,
thanks a lot for your patch. I've just verified that it works
perfectly on AIX and also did some smoke test on Linux (i.e. jstack)
which confirm that the original functionality is still preserved. This
is not a complete review because I'm not a serviceability expert but
with regard to fi
> On Mar 8, 2016, at 6:08 AM, Alan Bateman wrote:
>
>
> On 08/03/2016 07:45, Volker Simonis wrote:
>> :
>> OK, that would be fine. This problem isn't very urgent but it would be
>> good if we could resolve it before the big jake integration into
>> jdk9-dev.
>>
>>
> In order, then my preferen
On Tue, Mar 8, 2016 at 3:08 PM, Alan Bateman wrote:
>
> On 08/03/2016 07:45, Volker Simonis wrote:
>>
>> :
>> OK, that would be fine. This problem isn't very urgent but it would be
>> good if we could resolve it before the big jake integration into
>> jdk9-dev.
>>
>>
> In order, then my preference
On 08/03/2016 07:45, Volker Simonis wrote:
:
OK, that would be fine. This problem isn't very urgent but it would be
good if we could resolve it before the big jake integration into
jdk9-dev.
In order, then my preferences for resolving this are:
1. Compete the tool separation, meaning JDK-805
On Mon, Mar 7, 2016 at 8:58 PM, Alan Bateman wrote:
>
> On 07/03/2016 18:23, Volker Simonis wrote:
>>
>> :
>>
>> So while the tools are not being refactored, how can we fix the build
>> on non-SA platforms if moving the SA dependency to
>> module-info.java.extra is no viable solution? I've tried y
On 07/03/2016 18:23, Volker Simonis wrote:
:
So while the tools are not being refactored, how can we fix the build
on non-SA platforms if moving the SA dependency to
module-info.java.extra is no viable solution? I've tried your
suggestion to add `-addmods ALL-SYSTEM` to the jcmd launchers. It
s
Hi Alan,
I think you're right. Although I'm not familiar with the module system
at all, I can see the following:
- default build with jdk.hotspot.agent dependency in module-info.java
./images/jdk/bin/jdeps -m jdk.jcmd
module jdk.jcmd
requires java.base
requires jdk.attach
requires jdk.hotspot
On 07/03/2016 13:53, Volker Simonis wrote:
Hi Alan, Dmitry,
thanks a lot for your help. Alan's suggestion to move the dependency
from src/jdk.jcmd/share/classes/module-info.java to
src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After
doing that change I could successfully build on A
Hi Alan, Dmitry,
thanks a lot for your help. Alan's suggestion to move the dependency
from src/jdk.jcmd/share/classes/module-info.java to
src/jdk.jcmd/$OS/classes/module-info.java.extra works fine. After
doing that change I could successfully build on AIX. I'll open a bug
for this and post a webre
On 07/03/2016 09:38, Dmitry Samersoff wrote:
Volker,
Currently tmtools (jstack, jmap, jinfo, ... ) has two modes of
operations - one is cooperative (attach API based) other one is
non-cooperative (SA based).
Long term plan is completely separate these two modes, with jhsdb as the
only entry poi
Volker,
Currently tmtools (jstack, jmap, jinfo, ... ) has two modes of
operations - one is cooperative (attach API based) other one is
non-cooperative (SA based).
Long term plan is completely separate these two modes, with jhsdb as the
only entry point to SA.
This work is partially done - SA bas
On 04/03/2016 19:08, Volker Simonis wrote:
Hi Alan, Dmitry,
I've tried today to build the jake repository on AIX. Unfortunately
that doesn't work because we now have a hard dependency on SA which is
required by jcmd:
$cat jdk/src/jdk.jcmd/share/classes/module-info.java
module jdk.jcmd {
r
Hi Alan, Dmitry,
I've tried today to build the jake repository on AIX. Unfortunately
that doesn't work because we now have a hard dependency on SA which is
required by jcmd:
$cat jdk/src/jdk.jcmd/share/classes/module-info.java
module jdk.jcmd {
requires jdk.attach;
requires jdk.jvmstat;
On 03/02/2016 01:12 PM, Alan Bateman wrote:
On 02/03/2016 16:50, David M. Lloyd wrote:
Isn't there any way to break it up into functional sections or stages
that can be individually reviewed?
There source code is organized by module and there are also several
repositories, so I think it sho
On 3/2/2016 8:29 AM, Stephen Felts wrote:
Yes, you are correct. The rt.jar change and the classloading changes have
caused many of these tools problems. I should have tried to separate the Jake
from non-Jake problems.
I've also been entering bugs where possible. I entered them for gradle,
j
On 02/03/2016 16:50, David M. Lloyd wrote:
Isn't there any way to break it up into functional sections or stages
that can be individually reviewed?
There source code is organized by module and there are also several
repositories, so I think it should be manageable without needing to do
fi
On 03/02/2016 09:00 AM, Alan Bateman wrote:
We are starting to think through how to bring the module system that is
the monster patch in jigsaw/jake forest into the JDK 9 main line.
Isn't there any way to break it up into functional sections or stages
that can be individually reviewed?
--
-
ginal Message-
> From: Alan Bateman
> Sent: Wednesday, March 02, 2016 11:13 AM
> To: Stephen Felts; jigsaw-dev
> Subject: Re: Need help testing the EA builds
>
>
> On 02/03/2016 15:26, Stephen Felts wrote:
>> This will be a significant problem for a lot of people wit
e from the
junit problem).
-Original Message-
From: Alan Bateman
Sent: Wednesday, March 02, 2016 11:13 AM
To: Stephen Felts; jigsaw-dev
Subject: Re: Need help testing the EA builds
On 02/03/2016 15:26, Stephen Felts wrote:
> This will be a significant problem for a lot of people wi
On 02/03/2016 15:26, Stephen Felts wrote:
This will be a significant problem for a lot of people with respect to tools
not working.
Gradle junit - basic problem fixed in upcoming release
Jython
Ant - certain cases with classloader
JDT - doesn't work at all
Asm - never tracked down issue
Jmockit
ms that I don't have a workaround for, we can't run any tests,
either unit or functional, so coverage is almost non-existent and I don't know
what else is broken.
-Original Message-
From: Alan Bateman
Sent: Wednesday, March 02, 2016 10:01 AM
To: jigsaw-dev
Subject: N
We are starting to think through how to bring the module system that is
the monster patch in jigsaw/jake forest into the JDK 9 main line.
There are many reasons to do this. One reason is to reduce testing
effort. Another is to reduce the cost of sync ups as it takes a lot of
effort each week
26 matches
Mail list logo
