We have made some progress in eliminating several undesirable
dependencies in the past few builds [1]. A class analyzer tool in the
jigsaw/tools repository [2] has been developed and used to analyze the
dependencies.
The next step of the jdk modularization effort is to make the build
. the
jigsaw-tools repository for your reference:
http://cr.openjdk.java.net/~mchung/6909572/jigsaw-tools-webrev/
Thanks
Mandy
Mandy Chung wrote:
We have made some progress in eliminating several undesirable
dependencies in the past few builds [1]. A class analyzer tool in
the jigsaw/tools
A updated webrev against the the changeset I just pushed to the tl repo
and also include some minor fixes:
http://cr.openjdk.java.net/~mchung/6911737/webrev.01/
Mandy
Mandy Chung wrote:
This is the next step toward modularizing the jdk:
6911737: Module build: generate modules with native
Hi Max,
Sorry for the bug. I have a fix for it included in the review for 6916217:
http://cr.openjdk.java.net/~mchung/6916217/webrev.00/make/common/Defs.gmk.frames.html
I can file a separate bug and fix it separately if necessary (if I don't
get the review done for 6916217 say by
Thanks Alan.
Mandy
Alan Bateman wrote:
Mandy Chung wrote:
Fix for 6916217: make/modules/Makefile requires ALT_JDK_IMPORT_PATH
Webrev at:
http://cr.openjdk.java.net/~mchung/6916217/webrev.00/
This fix addresses two problems:
1) A full jdk build would never need a ALT_JDK_IMPORT_PATH. Fix
6960789: com.sun.servicetag API needs to be added in ct.sym
Webrev at:
http://cr.openjdk.java.net/~mchung/6960789/webrev.00/
This change was missing during the forward port of the service tag
support from jdk 6 update to jdk 7 (6581243).
Mandy
review other makefile
changes?
Thanks
Mandy
Mandy Chung wrote:
Alan, Kelly,
Webrev:
http://cr.openjdk.java.net/~mchung/6926663
It in fact contains 2 fixes:
1. integrate the latest jdk modularity fixes from jigsaw repos
- add modules target in the top forest makefile [1]
- support
Looks good to me.
Mandy
On 08/18/10 12:52, Kelly O'Hair wrote:
I still need a reviewer on this.
-kto
On Aug 2, 2010, at 4:46 PM, Kelly O'Hair wrote:
Need reviewer: minor makefile fixes
6932743: Makefiles not parsing version strings with - from uname -r
On some Linux systems the -
Looks good.
Mandy
On 1/28/11 1:42 PM, Kelly O'Hair wrote:
Need reviewer: change sanity check on make 3.81
7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now
Use of gnu make 3.81 or newer is required now, which should be readily
available on all platforms.
The patch is
Looks good to me.
Mandy
On 3/3/11 10:33 PM, David Holmes wrote:
Hopefully all interested parties are addressed in the cc lists.
webrev at:
http://cr.openjdk.java.net/~dholmes/7022370/webrev/
The launcher ergonomics (ergo.c) currently relies on per-architecture,
eg ergo_sparc.c,
On 3/7/11 10:10 PM, David Holmes wrote:
There was a glitch with the use of CTARGDIR (which isn't defined), so
now we check for the ergo file in LAUNCHER_PLATFORM_SRC. Webrev has
been updated - same location.
Looks good. Sorry I didn't catch that CTARGDIR isn't defined as it
exists in the
7025631: Remove the modules build support from jdk 7
Webrev at:
http://cr.openjdk.java.net/~mchung/7025631/webrev.00/
JDK modularity is targetted for JDK 8 [1]. The modules build is
supported in the jigsaw repository [2] and updated to work with the
module system. The modules build
-image for both
open+closed and open only.
I missed the make/common/Subdirs.gmk in my previous webrev. Do you mind
reviewing one last file:
http://cr.openjdk.java.net/~mchung/7025631/webrev.01/
Thanks
Mandy
-kto
On Mar 8, 2011, at 11:26 AM, Mandy Chung wrote:
7025631: Remove the modules
On 3/9/11 3:34 AM, Alan Bateman wrote:
Mandy Chung wrote:
7025631: Remove the modules build support from jdk 7
Webrev at:
http://cr.openjdk.java.net/~mchung/7025631/webrev.00/
These changes look okay to me too, just wondering if
jdk/make/java/nio/mxbean/Makefile should be removed too
Changeset: 6aeed99af874
Author:mchung
Date: 2011-03-09 23:11 -0800
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6aeed99af874
7025631: Remove the modules build support from jdk 7
Reviewed-by: alanb, ohair
! make/Makefile
! make/com/sun/crypto/provider/Makefile
!
Changeset: 1657b854c956
Author:mchung
Date: 2011-03-09 23:59 -0800
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1657b854c956
7026228: Remove make/modules and make/common/Modules.gmk
Reviewed-by: alanb, ohair
- make/common/Modules.gmk
- make/java/nio/mxbean/Makefile
-
On 03/10/11 08:01, Alan Bateman wrote:
Mandy Chung wrote:
Oops... how can I miss that!! I'll file a new CR and push this. For
7024172, it will be at least 1-2 weeks since we need to submit for
CCC approval.
Here is the patch.
diff --git a/make/java/nio/FILES_java.gmk b/make/java/nio
On 3/15/11 2:25 PM, Kelly O'Hair wrote:
Need reviewer for these 2 demo fixes:
6685150: make/mkdemo/jpda/Makefile creates jpda.jar and src.zip instead of
examples.jar
6710813: SwingSet2 source display tabs do not work since JDK 7 b20
On 4/4/11 10:39 AM, Kelly O'Hair wrote:
Need reviewer on minor demo building issue for plugin demos.
7029905: demo applets missing some html files
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-plugin-demo/webrev/
Looks good. I think those are the only JFC demos with the
Jon, Kelly,
Can you review the fix for 7037081: Remove com.sun.tracing from
NON_CORE_PKGS
This fix removes the generation of javadoc for this package and adds
com.sun.tracing to the javac's legacy.properties that javac will issue
warnings of any use.
Webrev at:
On 4/21/11 7:31 PM, Kelly O'Hair wrote:
Need reviewer for these jar manifest changes.
Multiple issues here:
* Bean manifest information should only be in rt.jar, not resources.jar,
jsse.jar,
* Added missing basic jdk manifest information into demo jar manifests
* JCE jars manifest
On 05/11/11 10:50, Kelly O'Hair wrote:
On May 11, 2011, at 10:47 AM, Alan Bateman wrote:
Q2: Does it belong somewhere other than the bin directory?
The script can be used to tunnel RMI calls over HTTP. Probably legacy
now and I'm pretty sure that java-rmi.cgi is just meant to be an
On 2/2/2012 7:13 PM, David Holmes wrote:
Okay two questions :) : do you know when this will get modularized and
show up in the jigsaw repositories?
FWIW. We have been sync'ing up jigsaw forest with jdk8 periodically and
hope to do it in a regular basis. It's currently sync'ed with
Great. That would give a good starting point.
Mandy
On 2/2/2012 7:34 PM, Brian Goetz wrote:
The main ASM distribution is broken into 5 jars, based on how people
tend to use it; this is probably a good starting candidate for module
boundaries.
On 2/2/2012 10:33 PM, Mandy Chung wrote:
On 2
I agree with Jon. SKIP_BOOT_CYCLE=false has been a useful and handy
test case (building JDK with the newly built JDK) to catch issues early
on.Such functionality makes it easy and convenient to do the skip
boot cycle build via JPRT or our automated nightly builds. FWIW - skip
boot cycle
I need a reviewer to fix this build problem that only affects partial build.
make/common/internal/Defs-jaxws.gmk maintains an explicit list of
JAXWS packages to import from a JDK for a partial JDK. However,
the list was not up-to-date and missing some JAXWS classes. You can
reproduce the
On 10/17/2012 11:29 AM, Kelly O'Hair wrote:
Looks ok to me. Did you plan on integrating it into jdk8/build?
I can do that. Thanks for reminding me - my local repo is a clone of
jdk8/tl.
Mandy
-kto
On Oct 17, 2012, at 11:11 AM, Mandy Chung wrote:
I need a reviewer to fix this build
On 10/17/2012 11:53 AM, Kelly O'Hair wrote:
On Oct 17, 2012, at 11:44 AM, Alan Bateman wrote:
On 17/10/2012 19:33, Mandy Chung wrote:
On 10/17/2012 11:29 AM, Kelly O'Hair wrote:
Looks ok to me. Did you plan on integrating it into jdk8/build?
I can do that. Thanks for reminding me - my
This review request (add a new jdeps tool in the JDK) include changes in
langtools and the jdk build. I would need reviewers from the langtools
and the build-infra team.
Webrev for review:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/jdeps/langtools-webrev.02/
On 4/15/2013 3:42 PM, David Holmes wrote:
FYI updated webrev at same location, removing the dead code Erik spotted.
http://cr.openjdk.java.net/~dholmes/8010280/webrev/
Looks good to me. Nit: CopyFiles.gmk line 340 - you may want to remove
the extra space to align with the next line.
On 4/16/2013 7:34 PM, David Holmes wrote:
A simple sanity test? ;-) This would involve finding all the
libjvm's in a JRE and extracting their names, then finding and reading
the jvm.cfg file in the JRE, then invoking the VM with all the
possible entries in jvm.cfg and using the version
Looks good.
Mandy
On 5/8/2013 9:00 PM, Mike Duigou wrote:
Hello all;
Small issue for review. Some of the Main.gmk targets aren't mentioned in the
PHONY targets as they should be.
http://cr.openjdk.java.net/~mduigou/JDK-8014269/0/webrev/
Mike
Looks good to me.
Mandy
On 10/9/2013 5:47 PM, David Holmes wrote:
webrev:
http://cr.openjdk.java.net/~dholmes/8026232/webrev/
libnpt.so is used for debugging and profiling but was mistakenly
placed in profile compact1. It should be in compact3 along with the
hprof agent that uses it (other
On 10/14/2013 6:39 AM, Alan Bateman wrote:
This is an update to the BuildMetaIndex tool, the tool used in the
build to generate the meta-index file.
The problem is that the tool assumes that there are at least two
levels of package in the name of each type. This causes a problem for
On 10/15/2013 11:16 AM, Kumar Srinivasan wrote:
Hello,
Please review the removal of extraneous docs (specifically javaws.1)
no longer need for
Solaris.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8026500
Webrev:
http://cr.openjdk.java.net/~ksrini/8026500/webrev/
Looks okay to me.
On 10/22/13 9:36 AM, Tim Bell wrote:
All -
We are not building 32-bit Solaris any longer in JDK 8. (The main bug
number for that was JDK-8023288 Remove Solaris 32-bit from JDK8).
8027039 is a cleanup task for removing 32-bit Solaris from the
following files:
com.sun.management API is an exported API [1] except
com.sun.management.OSMBeanFactory class which is an
implementation-specific class and it's currently annotated as
@jdk.Exported(false) [2]. This patch will eliminate one use of
@jdk.Exported(false).
This is simply refactoring of the
Thanks you all for the review.
I'll rename AbstractOperatingSystemImpl before I push.
Mandy
On 11/8/2013 5:22 AM, Alan Bateman wrote:
On 08/11/2013 08:40, Jaroslav Bachorik wrote:
AbstractOperatingSystemImpl should be an abstract class as its name
already indicates.
Right, it probably
Looks good. Happy to see these methods finally removed for a clean jdk
modularization!
Mandy
On 12/10/2013 3:06 AM, Alan Bateman wrote:
(This one is for the jdk9-dev forest once it is created)
The addPropertyChangeListener and removePropertyChangeListener methods
defined by
On 2/6/2014 4:06 AM, Alan Bateman wrote:
One of things that we are hoping to do in JDK 9 is to drop support for
the IIOP transport from RMI connector in the JMX Remote API [1]. The
motive is modules and the first step on this journey was to downgrade
the support to optional from required
Hi Phil,
Is psfont*.properties* file more of a resource file? Is there any
reason (or specification) that psfont*.properties has to be in JRE/lib
directory? One potential reason might be the startup performance (warm
start/cold start) to avoid opening a jar file? They don't look like a
On 4/7/14 11:54 AM, Chris Hegarty wrote:
Updated webrev:
http://cr.openjdk.java.net/~chegar/8039362/01/webrev/
Thanks for doing this. Some minor comments:
line 225: since content-types.properties is moved to the same package as
MimeType class, you can simply use the relative path
On 4/11/2014 3:42 PM, Xueming Shen wrote:
webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
It's good to see the source of the zip provider moved to the jdk repo.
You have made some public classes to package-private which is good. I
wonder whether a few remaining public classes
Thanks Sean.
I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
Erik - I'm including build-dev to review the build change for
java.policy file.
Thanks
Mandy
On 4/24/14 11:32 AM, Sean Mullan wrote:
On 04/23/2014 05:29 PM, Mandy Chung wrote:
On 4
of just =. We only use = assignment
when explicitly needed.
Thanks for the review Erik. I'll make the change before the push.
Mandy
/Erik
On 2014-04-25 01:07, Mandy Chung wrote:
Thanks Sean.
I have updated the webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/
Erik
The jar files for access bridge are different on windows-i586 and
windows-amd64. Need to be able to generate different version of
java.policy for windows-i586 and windows-amd64 JDK.
This patch copies different copy according to its target OS/CPU.
Webrev at:
On 6/19/14 12:02 PM, Tim Bell wrote:
Hi Mandy:
The jar files for access bridge are different on windows-i586 and
windows-amd64. Need to be able to generate different version of
java.policy for windows-i586 and windows-amd64 JDK.
This patch copies different copy according to its target
On 8/15/2014 1:49 AM, Magnus Ihse Bursie wrote:
*** Issues regarding modules.xml ***
The new modules.xml and associated Java tools and make files seems
rather confusing to me. I understand some of the mysteries here are
due the the fact that the file has moved around during development.
On 8/12/2014 7:10 AM, Chris Hegarty wrote:
Webrevs:
http://cr.openjdk.java.net/~chegar/8054834/00/
I reviewed the hotspot change. Looks good. One minor point:
I think line 1230 can be removed when rt.jar is present.
Mandy
On 8/20/2014 1:26 PM, Phil Race wrote:
I understood we now build individual modules so when
I touched one java source file in the desktop module I expected to see
only
that one module rebuilt but I see this :-
java.desktop and all its dependencies are recompiled. The dependencies
are
On 8/22/14 11:46 AM, Naoto Sato wrote:
http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
I skimmed on the patch and have a few initial comment/questions.
JREENLocaleDataMetaInfo
JRENonENLocaleDataMetaInfo
- are the lists of locale names generated previously?
The long lines need to be
On 8/22/14 3:37 PM, Naoto Sato wrote:
I wonder ifavailableLanguageTags andgetSupportedLocaleString
should return a list or an array of String (see comment below).
There are two provider implementations for
sun.util.locale.provider.LocaleDataMetaInfo and two service config
files as
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055230/
This patch renames the class name of attach provider implementation class
to be the same for all platforms. This simplifies the build logic and
removes the need for generating the service config file at build time.
The files
On 8/27/2014 3:19 AM, Magnus Ihse Bursie wrote:
On 2014-08-27 10:26, Erik Joelsson wrote:
Hello Mandy,
Looking at this, I just realized that
$(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/jdeps-modules.xml
is a generated resource for a module and that you correctly added it
Erik, Magnus,
This is much easier than I have thought. I really like this new build.
I have separated out Gendata-jdk.dev.gmk and removed the modules-xml
target completely.
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856/webrev.01/
Mandy
On 8/28/14 1:32 AM, Magnus Ihse Bursie wrote:
On 2014-08-27 18:00, Mandy Chung wrote:
Erik, Magnus,
This is much easier than I have thought. I really like this new build.
Glad to hear! :)
I have separated out Gendata-jdk.dev.gmk and removed the modules-xml
target completely.
Webrev
.
Mandy
/Erik
On 2014-08-27 18:00, Mandy Chung wrote:
Erik, Magnus,
This is much easier than I have thought. I really like this new build.
I have separated out Gendata-jdk.dev.gmk and removed the modules-xml
target completely.
Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8055856
Naoto,
This looks better. Thanks for the update.
The getSupportedLocaleString method in both EnLocaleDataMetaInfo and
NonEnLocaleDataMetaInfo has the javadoc that missing the description.
sun.util.locale.provider is a package in java.base and
NonEnLocaleDataMetaInfo has to be in a
On 8/29/14 2:07 PM, Naoto Sato wrote:
I incorporated the suggestions from Mandy and Alan. Also one change
since the last webrev was to revert the hard-coding of the supported
locales list back to the one which dynamically generates the lists at
the build time. I initially thought static
On 9/12/14 7:03 AM, Erik Joelsson wrote:
Hello,
The checked in modules.list file defines the dependencies between
modules for the build. The dependency information in this file is
already captured in the modules.xml. Rather than keeping two copies of
this information, with this change,
With the Modular Source Code [1] in JDK 9, the verify-modules target
was added in the build to catch any regression to the module boundaries.
It's important to catch this regression early during jdk development.
This patch proposes to add verify-modules to the default target
and also images
On 9/13/2014 1:30 AM, Chris Hegarty wrote:
Update jdk part as per Mandy’s comments:
http://cr.openjdk.java.net/~chegar/8058118/webrev_jdk.01/webrev/
Looks good. Thanks for the update. As Alan pointed out, it'd be
good to add a private no-arg constructor to ModulesXmlReader and
to test a code
change builds properly, it would be included in the default target.
If you aren't affecting the images, then you don't expect to need
to build the images.
-phil.
On 9/15/2014 2:48 AM, Erik Joelsson wrote:
On 2014-09-13 10:05, Alan Bateman wrote:
On 12/09/2014 21:48, Mandy Chung
On 9/15/14 10:36 AM, Alan Bateman wrote:
On 15/09/2014 18:24, Mandy Chung wrote:
I am starting to not to count on most people building images and
inclined to catch any new dependence earlier in the default build
to avoid potential build breakage.
The time for verify-modules is not small
On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net/~naoto/8058509/webrev.0/
The fix is intended to move the LocaleDataMetaInfo of CLDR from
. There is no need to put their en
resources in java.base.
Naoto
On 9/15/14, 6:11 PM, Mandy Chung wrote:
On 9/15/2014 4:30 PM, Naoto Sato wrote:
Hello,
Please review the fix for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8058509
The webrev is located at:
http://cr.openjdk.java.net
Naoto
On 9/16/14, 9:50 AM, Mandy Chung wrote:
At one point you mention that CLDR will become the default in JDK 9.
Would you need to move them back to java.base when it becomes the
default?
Mandy
On 9/16/14 9:30 AM, Naoto Sato wrote:
CLDR's data is accessible only when cldrdata.jar is available
portion of CLDR locale data in
java.base would make it not possible for them to jrecreate the image
without CLDR.
Naoto
On 9/16/14, 2:09 PM, Mandy Chung wrote:
On 9/16/14 9:57 AM, Naoto Sato wrote:
Yes, the current plan is to make the CLDR's data the default one, only
when it is available
On 9/21/14 3:51 PM, Bradford Wetmore wrote:
Hi Sean/Mandy/Erik/Magnus/Alan/David/others,
Please review:
JDK-8058845 : Update JCE environment for build improvements
http://cr.openjdk.java.net/~wetmore/8058845/
The change looks fine in general. Some minor comments:
Hi Shanliang,
On 10/15/2014 8:19 AM, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/
Thanks for taking this on. The fix looks okay. I think you should
also take out:
make/common/Modules.gmk
line 45: JAVA_MODULES_FILTER := jdk.snmp
Mandy
On 10/15/2014 9:04 AM, Mandy Chung wrote:
Hi Shanliang,
On 10/15/2014 8:19 AM, shanliang wrote:
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/01/
Thanks for taking this on. The fix looks okay. I think you should
also take out:
make/common/Modules.gmk
line
On 10/16/14 3:20 AM, shanliang wrote:
Hi,
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/
Looks fine to me.
thanks
Mandy
On 11/19/2014 12:47 PM, roger riggs wrote:
Please review a cleanup for the 8u40 build.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-build-8065353/
Looks okay to me.
Are you also asking for 8u40 putback approval as well? Or maybe you are
thinking to send a separate 8u40 request?
On 11/20/14 3:19 AM, Erik Joelsson wrote:
Hello,
Please review this small fix, correcting the source generation from
properties when the properties files are in platform specific source
directories. The bug was introduced by me in JDK-8055191.
Bug:
Hi Sundar,
On 11/28/2014 2:41 AM, A. Sundararajan wrote:
Hi,
Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/
for https://bugs.openjdk.java.net/browse/JDK-8066146
Is jdk.nashorn.api.scripting a supported API? It looks like some
classes are defined for JEP 202 [1] and
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/
This patch adds back the verify-modules target to the dependences of the
images target that got dropped in the merge and hides a bug in jdeps
-Xverify:access.
Erik - I notice make/Javadoc.gmk that sets -bootclasspath
fix javadoc in the same change.
It's such a small issue I rather not go through the hassle of creating
a bug and a new review.
Thanks!
/Erik
On 2014-12-12 19:25, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/
This patch adds back the verify
This looks fine and good to see the hardcoded exception replaced.
Mandy
On Feb 16, 2015, at 2:57 AM, Erik Joelsson erik.joels...@oracle.com wrote:
Hello,
When merging jdk9/dev and jdk9/hs, the following message appears and the
build fails:
gmake[2]: *** No rule to make target
On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
On 13.01.2015 17:23, Alan Bateman wrote:
Typo in my mail, I meant verify-modules.
They are currently issues with verify-modules and boot cycle builds
so I think verify-modules is currently disabled (at least in
jdk9/dev). Erik is working on this via
On 1/13/15 9:34 AM, Sergey Bylokhov wrote:
On 13.01.2015 20:26, Mandy Chung wrote:
On 1/13/15 7:45 AM, Sergey Bylokhov wrote:
On 13.01.2015 17:23, Alan Bateman wrote:
Typo in my mail, I meant verify-modules.
They are currently issues with verify-modules and boot cycle builds
so I think
On 2/13/15 10:01 AM, Sergey Bylokhov wrote:
http://cr.openjdk.java.net/~serb/8039269/webrev.00/root
http://cr.openjdk.java.net/~serb/8039269/webrev.00/jdk
I looked at java/awt/Cursor.java that looks fine to me
Minor comment on java/awt/Cursor.java
line 166, 167: all caps are
On 3/9/15 4:46 AM, Magnus Ihse Bursie wrote:
The fix for JDK-8074429
https://bugs.openjdk.java.net/browse/JDK-8074429 moved the jar tool
into a new jdk.jartool module.
However, it did not remove all references from the old module.
Gensrc-jdk.dev.gmk still references the old jar path, which
jdk.unpack200 and not jdk.pack200 ? since it
contains only the unpacker, and the bin utilities are pack200 and
unpack200.
Kumar
On 3/4/2015 5:13 PM, Mandy Chung wrote:
As listed in an open issue in JEP 200:
The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any
On 3/12/2015 5:54 AM, Staffan Larsen wrote:
The build for jconsole currently takes a template file and inserts the version
number of the build into the file. We can simplify this by removing the
template file and reading the java.runtime.version system property at runtime.
bug:
On 3/24/2015 2:36 PM, Pete Brunet wrote:
Here's the latest patch:
http://cr.openjdk.java.net/~ptbrunet/JDK-8055831/webrev.01/
The modules.xml change looks fine.
Mandy
On 2/27/15 12:55 PM, Brent Christian wrote:
Hi,
Please review a small update to the module config files for a new
jdk.management.cmm module.
Webrev: http://cr.openjdk.java.net/~bchristi/8073596/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8073596
The change looks fine.
Mandy
it into jdk.security.tools and jdk.security.util. Put the
executables into tools and APIs into util.
--Max
On Mar 5, 2015, at 09:13, Mandy Chung mandy.ch...@oracle.com wrote:
As listed in an open issue in JEP 200:
The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong
As listed in an open issue in JEP 200:
The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed or refactored.
Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in
the JDK that
On 3/5/2015 12:31 AM, Alan Bateman wrote:
On 05/03/2015 01:13, Mandy Chung wrote:
:
Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/
I think this looks okay
Max,
Since the new APIs you're working on are still in design phase, I think
it's a bit early to discuss where these new APIs should be in.
Just one thing to say about the new JarSigner API from your webrev.
com.sun.jarsigner is an existing exported package that you should
consider
On 2/19/15 10:51 PM, Erik Joelsson wrote:
Hello,
Please review these two small fixes to the build system. When we tried
to add a custom Gensrc-module.gmk file, it didn't work as expected.
The -I flags on the make command line were wrong, so it couldn't
import the GensrcCommon.gmk or
On 1/13/2015 11:30 AM, Sergey Bylokhov wrote:
On 13.01.2015 21:51, Alan Bateman wrote:
I think this looks okay. I see Mandy's comment about dropping the
dependency on sun.security.util and that would be good to do (but can
be another patch if you want).
ok. The new versions:
On 4/2/15 12:58 PM, Shanliang Jiang wrote:
Hi,
I have to ask the review again because I need to modify:
langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java
The issue was found when langtools tests were added into my test list.
The new version is:
On 4/2/2015 4:52 PM, Jonathan Gibbons wrote:
Sorry for the relatively wide distribution.
JDK-8076583 is a conceptually simple cleanup, to move the source file
for the jdk.Exported class from the langtools repo (where it is a
singleton outlier) to the jdk repo (alongside most of the rest of
On 4/17/2015 6:09 AM, Magnus Ihse Bursie wrote:
From bug report: Proposal has been made to remove native2ascii tool
from JDK9.
It was identified that JDK9 uses native2ascii itself to convert
Japanese nroff man pages to various encodings (Linux: UTF-8, Solaris:
UTF-8, PCK/SJIS) from eucJP
This API is only available on windows but not other platforms. I think
src/windows/classes is the right location.
Mandy
On 4/7/2015 10:51 PM, Pete Brunet wrote:
Please review/approve the following patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
The recent push for
On 4/8/2015 3:21 AM, Staffan Larsen wrote:
Please review these small changes to support an addition of closed code to the
java.instrument module.
webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/
The change looks fine.
I agree with Phil's suggestion and file a bug to follow up the javadoc
build issue.
You can verify the result from make docs that there is no javadoc
generated for this package on windows build.
Mandy
On 4/8/2015 10:29 AM, Phil Race wrote:
Isn't it sufficient to comment out this one line ?
+1
Mandy
On 4/8/2015 11:00 AM, Phil Race wrote:
That looks good to me.
-phil.
On 4/8/2015 10:55 AM, Pete Brunet wrote:
How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
On 4/8/15 12:47 PM, Mandy Chung wrote:
I agree with Phil's suggestion and file a bug to follow up
On 3/31/2015 9:39 AM, shanliang wrote:
Please review this fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
Thank you for doing this big change to separate com.sun.management
API from java.management module. Looking really
1 - 100 of 410 matches
Mail list logo
