-8076182 (Open source Java Access Bridge) which
exposed some files that were in closed the webrev needs a full re-review.
I've also made the changes requested by Mandy.
http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/
Pete
On 3/23/15 4:41 PM, Mandy Chung wrote:
On 3/19
.
Mandy
Pete
On 6/10/15 6:08 PM, Mandy Chung wrote:
Just a quick check, jdk.accessibility is only linked in windows image at the
moment. It is a bug. Are you going to fix that in this changeset? I think
you have to verify this change in windows as well as other platforms.
Mandy
On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore
maurizio.cimadam...@oracle.com wrote:
Hi,
In the context of the IntelliJ project support for JDK, I have a question on
the very last step of 'make images' :
## Starting verify-modules
Checking dependencies across JDK modules
Access
and Security.getProviders() call. So,
if the META-INF/services/java.security.Provider file content is not
correct, the new test would fail and it's a clear indication that
ServiceLoader can't find one or more of the providers.
Thanks,
Valerie
On 6/5/2015 10:43 PM, Mandy Chung wrote:
On Jun 5, 2015, at 4:32
ongoing and we should be able to reach a
decision in a day or two.
Will update the list again.
Thanks,
Valerie
On 06/01/15 16:39, Magnus Ihse Bursie wrote:
On 2015-05-29 00:10, Valerie Peng wrote:
Please find comments in line...
On 5/27/2015 3:42 PM, Mandy Chung wrote:
Valerie,
Did
On 2015-05-21 07:33, Pete Brunet wrote:
Please review the following change for 8u:
http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/
I only skimmed through the change. package-info.java should have @jdk.Exported.
Mandy
Background:
- As part of the open sourcing of the
Valerie,
Did you see my comment yesterday?
http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html
Since you have reverted the java.security to keep the classname, to avoid
causing merge conflict to jimage refresh, let’s remove the META-INF files in
the first push and the
On May 25, 2015, at 3:00 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 25/05/2015 09:53, Chris Hegarty wrote:
If it is agreed that these files are needed, then I can look at expanding
the ImageBuilder to do concatenate them.
I agree with Mandy's point that java.security should be
On 05/22/2015 08:09 AM, Alan Bateman wrote:
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class
to hack ImageBuilder to special case the service
config file and merge them.
Any thought?
On May 21, 2015, at 3:03 PM, Valerie Peng valerie.p...@oracle.com wrote:
Mandy,
Please find comments in line.
On 5/20/2015 10:39 PM, Mandy Chung wrote:
A quick comment on the META-INF/services
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 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/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 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
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
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/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
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
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 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
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
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 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 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 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:
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
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
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
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:
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 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
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 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:
. 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
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
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
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 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 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/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
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/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
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/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
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
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
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
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
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
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 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
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
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
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
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:
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/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
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
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
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
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/
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
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
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
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 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
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/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
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
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/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
!
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/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
301 - 400 of 410 matches
Mail list logo