On 02/02/2017 22:27, Mandy Chung wrote:
libmanagement_agent should be the proper library name for jdk.management.agent.
It was an oversight with the current name.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/
This patch also takes out the qualified exports of java.base/j
> On Feb 2, 2017, at 3:58 PM, David Holmes wrote:
>
> Hi Mandy,
>
> Looks reasonable.
>
> No tests that need changing?
>
No since it’s just the shared library name change. The shared library provides
the native method implementation for jdk.internal.agent.FileSystem (no change
there)
Man
Hi Mandy,
Looks reasonable.
No tests that need changing?
Thanks,
David
On 3/02/2017 8:27 AM, Mandy Chung wrote:
libmanagement_agent should be the proper library name for jdk.management.agent.
It was an oversight with the current name.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858
libmanagement_agent should be the proper library name for jdk.management.agent.
It was an oversight with the current name.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8173858/webrev.00/
This patch also takes out the qualified exports of java.base/jdk.internal.vm
to java.management which i
Hi,
A direct consequence of this change is that you may have
to either blow up your ./build directory, or run
'make clean-java' after pulling this fix.
Otherwise you may see strange build failures like below:
Error occurred during initialization of VM
java.lang.RuntimeException: Package com.sun
Hello Matthias,
While your change is ok and can certainly be pushed on its own, there is
so much more needing cleanup here. If you don't mind, here is what I
think needs doing:
* Inline BUILD_JSPAWNHELPER_SRC, JSPAWNHELPER_CFLAGS,
BUILD_JSPAWNHELPER_DST_DIR and LINK_JSPAWNHELPER_OBJECTS. Sin
Hello,
could I please have a review for the following small change that
cleans up the special macosx BUILD_JSPAWNHELPER_DST_DIR setting that is not
really
needed any more after CR 8066474: "Remove the lib/ directory from Linux
and Solaris images" changed the default setting .
> On Feb 2, 2017, at 4:37 AM, Daniel Fuchs wrote:
>
> Hi Mandy,
>
> On 02/02/17 02:41, Mandy Chung wrote:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
>>
>> Does java.management still depend on java.base/jdk.internal.module?
>
> Well spotted! It doesn't. I have updated modu
Looks ok.
/Erik
On 2017-02-02 13:24, Magnus Ihse Bursie wrote:
There are dead code inBuildNashorn.gmk that is related to the now
defunct nashorn.jar. It should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8173822
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8173822-remove-nasho
> On 2 Feb 2017, at 13:07, Magnus Ihse Bursie
> wrote:
>
> When building with Solaris Studio 12u4, linking of unpack200 fails. The fix
> is to include "environ" in the mapfile.
>
> This patch is contributed by Douglas Simon.
For full disclosure, the original patch and discovery was by Stefan
Hi Mandy,
On 02/02/17 02:41, Mandy Chung wrote:
http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.06
Does java.management still depend on java.base/jdk.internal.module?
Well spotted! It doesn't. I have updated module-info.java for java.base.
http://cr.openjdk.java.net/~dfuchs/webrev_
Actually, just realizing I can take that idea one step further. I can install
!0.8 as a VM on VMWare.
Thank you.
— Jim
> On Feb 2, 2017, at 4:00 AM, Erik Joelsson wrote:
>
> There was a discussion about this a few weeks back, but you are correct.
> David DeHaven suggests creating a VM to
There are dead code inBuildNashorn.gmk that is related to the now
defunct nashorn.jar. It should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8173822
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8173822-remove-nashorn-jar-cleanup/webrev.01
/Magnus
Looks ok to me.
/Erik
On 2017-02-02 13:07, Magnus Ihse Bursie wrote:
When building with Solaris Studio 12u4, linking of unpack200 fails.
The fix is to include "environ" in the mapfile.
This patch is contributed by Douglas Simon.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172548
Patch in
When building with Solaris Studio 12u4, linking of unpack200 fails. The
fix is to include "environ" in the mapfile.
This patch is contributed by Douglas Simon.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172548
Patch inline:
diff --git
a/make/mapfiles/libunpack/mapfile-vers-unpack200-solari
There was a discussion about this a few weeks back, but you are correct.
David DeHaven suggests creating a VM to build in.
http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018518.html
/Erik
On 2017-02-01 20:00, Jim Laskey (Oracle) wrote:
I haven’t tried in a while, but I ran up a
16 matches
Mail list logo