Re: Request for review: always generate java-rmi.cgi

Kelly O'Hair wrote: I found this bug: http://bugs.sun.com/view_bug.do?bug_id=4495986 Which seems to imply that maybe this java-rmi.cgi file doesn't belong in the "bin" directory at all? But it also seems to me that the current: 91 ifneq ($(ARCH_DATA_MODEL), 32) 92 build: stubs 93 else

Re: Build portability: enable or disable warnings

David Holmes wrote: : In contrast, there are basically two Java compilers in general use (javac and ecj) and one is part of OpenJDK. Yet, the Java code does not have -Werror enabled by default and there are a mass of warnings there as a result. I don't understand the point you are making h

Re: Build portability: enable or disable warnings

Jonathan Gibbons wrote There's a useful interim milestone which is relatively trivial to do. If javac -Xlint:all gives warnings, you can go javac -Xlint:all,-xyz to disable the xyz category of warnings. The specific value of xyz to use is given at the beginning of the warning message in squa

Re: Request for review: 7039182 NIO platform specific files

David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7039182/webrev/ This will be pushed through the TL jdk repo but Alan suggested getting build-dev to review (in addition to himself). Yes, I suggested including build-dev as Kelly asked to be included on any build changes. The approach l

Re: 7057935: com/sun/nio/sctp tests should be moved out of jdk_nio and into their own target, jdk_sctp

Chris Hegarty wrote: Kelly, Alan, The com/sun/nio/sctp tests are run when running the jdk regression tests with the makefile in the jdk/test directory. They are currently part of the jdk_nio3 target. SCTP is a niche area and there is no need to have these tests run with the nio tests. Also

Re: Warning without cleanbuild

Sebastian Sickelmann wrote: Hi, i sometimes get this warning if i don't execute a "make clean" before my "make all" in jdk repository. /home/sebastian/deve/openjdk8/build/linux-i586/j2sdk-image/bin/javac -J-XX:ThreadStackSize=768 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:

Re: code review request: 7092627: use agentvm mode instead of samevm in regtests

Weijun Wang wrote: Hi Dmitry Webrev updated at http://cr.openjdk.java.net/~weijun/7092627/webrev.01/ Also, a new variable CONCURRENCY is added so that you can run tests in multiple VMs. The value can be a number or "auto" which uses Runtime.getRuntime().availableProcessors() as the value.

Re: code review request: 7092627: use agentvm mode instead of samevm in regtests

Weijun Wang wrote: : Also shouldn't you also s/SAMEVM/AGENTVM/ so that there are no longer any references to samevm? Is that necessary? That would also need s/samevm/agentvm/ and s/RunSamevmBatch/RunAgentvmBatch/. :) It just seems odd to have any mention of samevm in this Makefile now. I

Re: code review request: 7092627: use agentvm mode instead of samevm in regtests

Weijun Wang wrote: So here it is http://cr.openjdk.java.net/~weijun/7092627/webrev.02/ I grep -i same test/Makefile and find no match. Looks good, thanks again for doing this. -Alan. PS: Not your doing, but I notice that these tests are missing copyright headers.

Re: Code Review 7103549: Remove dependencies on libjava and libjvm from security libraries

Chris Hegarty wrote: All of the security native libraries have runtime dependencies on libjava and libjvm, most of which are completely unnecessary. This CR proposes to remove these dependencies and provide localized versions of the trivial utility functions that are being used from libjava, i

jdk/src/solaris - time to re-visit it?

In the jdk repository then src/solaris has all the Solaris and Linux code. Most of it is used for both platforms with a small number of files specific to one or the other. I'm sure this has come up before (probably many times) but I'd like to bring it up again. One of motives for bringing th

Re: jdk/src/solaris - time to re-visit it?

On 23/11/2011 13:33, Fredrik Öhrström wrote: : I have no suprise there I guess ;-). If you read CompileJavaClasses.gmk in build-infra/jdk7/jdk/make you can see the hoops we need to go through to filter out platform specific classes in share/classes and linux specific classes in solaris/classe

Re: jdk/src/solaris - time to re-visit it?

On 23/11/2011 20:48, David Holmes wrote: Alan, It's definitely tricky (lots of refactoring needed) but it definitely needs to be done at some point - however I think we already missed the opportunity to do this before integrating the BSD and MacOSX code (same on the VM side) I've often wonder

Re: (XS) Request for review: 7109092 - link changes for embedded builds

On 23/11/2011 06:55, David Holmes wrote: We need to make an adjustment to the link instructions used for libjava in embedded builds, as defined in Defs-embedded.gmk webrev: http://cr.openjdk.java.net/~dholmes/7109092/webrev/ Summary: system soft-float libraries need not have the level of accu

Re: jdk/src/solaris - time to re-visit it?

On 24/11/2011 14:39, Fredrik Öhrström wrote: : It would be great to do the rename. However, we should not do that before the build-infra changes are in place. The peculiarities of the current build have already been worked around and the new makefiles are useful, since it is easy to see where the

Re: jdk/src/solaris - time to re-visit it?

On 29/11/2011 19:34, Phil Race wrote: : * 95%+ of the code will be the same across solaris/linux/etc And remember this includes all the X11 code. * Of the remaining 5%, most of it is best dealt with via ifdef because its a few line delta in a large file. I'd guess 2% of the code might meri

Re: please review 7122061: enable -Werror in various jdk build steps

On 16/12/2011 02:59, Stuart Marks wrote: The webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7122061/webrev.0/ This defines the JAVAC_MAX_WARNINGS and JAVAC_WARNINGS_FATAL variables in a variety of Makefiles within the jdk repository. This essentially adds -Xlint:all -Werror to the

Re: please review 7122061: enable -Werror in various jdk build steps

On 22/12/2011 01:51, Stuart Marks wrote: I dug up a bit of background on this. Apparently Sasha ran across this problem back in July and asked about this on net-dev [1]. Discussion continued on build-dev [2]. Kurchi later picked up this work and after some discussion got it integrated [3].

7132204: Default testset in JPRT should not run all tests

Kelly - this is a change to the JPRT configuration to dial-down the number of test targets that are run by default. It also adds a new testset, called "core" that runs all langtools and jdk excepts except for the AWT/Swing/client tests. A couple of persistent offenders added to the ProblemLis

Re: RFR: 7133124 Remove redundant packages from JAR command line

On 26/01/2012 09:44, Rickard Bäckman wrote: Hi, We have a problem with some versions of jar reporting errors when trying to run jar cf com/test com/test/foo This fix removes the redundant subdirectories from the command. Webrev is here: http://cr.openjdk.java.net/~rbackman/7133124/webrev/

7140918: Remove dependency on apt and com.sun.mirror API

The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed) to remove the JAX-WS dependency on apt and the com.sun.mirror API: http://cr.openjdk.java.net/~alanb/7140918/webrev/ This is needed before Joe Darcy can wield his machete. Please cc'ed Miran and Martin on my review comm

Re: 7140918: Remove dependency on apt and com.sun.mirror API

On 31/01/2012 01:17, David Holmes wrote: : Okay. So as part of this will the new zip file be installed before the change gets pushed? Yes, that's right. -Alan

Re: 7140918: Remove dependency on apt and com.sun.mirror API

On 01/02/2012 15:13, Miroslav Kos wrote: Hi Alan, do you have any update about approving the changeset? The jaxws bundle is already in place, so there should be nothing blocking us from the final step(?) I plan to push it later this week once I've verified the the downloads and done a few test

Re: Adding asm to JDK 8

On 03/02/2012 04:04, Mandy Chung wrote: 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. Brian - I

Re: Adding asm to JDK 8

On 03/02/2012 05:08, Dmitry Samersoff wrote: Jim, Do you plan to remove one already existing in the rt.jar (it comes from jax-ws)? com.sun.xml.internal.ws.org.objectweb.asm Do you have permission to include one particular version or plan to sync it regularly? -Dmitry This is a good point. On

Re: Adding asm to JDK 8

On 03/02/2012 15:07, Brian Goetz wrote: The current plan is to use ASM long-term to generate classes at runtime. Now, it is possible that "something better will come along" (perhaps needed functionality will be provided by JSR-292 in the future) but we're not banking on this. The EE team has

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

On 22/03/2012 15:19, Martijn Verburg wrote: Hi all, I'm back from holiday and am building the latest (http://hg.openjdk.java.net/jdk8/tl/jdk) project for our 3rd Java User Group OpenJDK hack day. I've run across an error that I haven't been able to resolve. .. .. ../../../build/linux-i586/t

Re: Review Request: Build-infra M1

On 21/03/2012 14:07, Erik Joelsson wrote: : jdk, all changes including a partial copy of the old makefiles. http://cr.openjdk.java.net/~erikj/build-infra-m1/webrev-jdk-new/ Fredrik - I think it would be better to leave Modul

Re: Review Request: Build-infra M1

On 22/03/2012 21:21, Fredrik Öhrström wrote: Yes, of course, I just pushed a fix. Thanks, I just wanted to check as it is the webrev. Have you changed the class analyzer to output a text file with the mapping of the sources? e.g. java/lang/Object.java jdk.base/java/langObject.java We should

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

On 22/03/2012 17:51, Martijn Verburg wrote: Hi Andrew/Alan, Thanks for responding! I suspect you are right, I'm only building the tl project, which i guess is a partial build? I saw the patch that Andrew mentioned but hadn't put 2 and 2 together that I'd need to build the hotspot part separat

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

On 25/03/2012 13:01, Martijn Verburg wrote: Hi Sean/Alan/Max, Sean - Your solution did the trick, and I'll probably use this for now as it means a smaller VM for the members to work with Alan/Max - I did get the full build going, but then my VM ran out of space. I see Seán suggestion is to use

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

On 26/03/2012 02:25, Weijun Wang wrote: : There is completely no harm in setting JDK 8 as BOOTDIR of JDK 8, but I would suggest you using 7u4. If there is anything wrong, you can send us a bug report. I don't think we can guarantee that jdk8 will always be buildable using another jdk8 build a

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

On 26/03/2012 11:42, Jonathan Gibbons wrote: Alan, Really? I'm not sure I agree. If you have a complete and successful build of JDK 8, then you should pretty much always be able to use that as a bootstrap JDK. No argument on that case as everything should match. The case I'm concerned about

Re: javadoc and API docs

On 26/03/2012 12:34, Jonathan Gibbons wrote: Right now, in the current build, we use a "hybrid" javadoc to build the API documentation, where "hybrid" means: latest sources, running on bootstrap JDK. Looking to the future, at least for Jigsaw, and now maybe for JSR 308, we may need to run jav

Re: Review Request: Build-infra M1

This isn't really an issue for the first push, more of a question as to how this will all look once the remaining make files has been converted. My question relates to jdk/makefiles/CompileJavaClasses.gmk and CompileNativeLibraries.gmk and how they will be maintained more longer term. Is the

Re: Request for Review: 7165722 invalid path in MemoryMonitor demo's README.txt

On 02/05/2012 09:27, Jonathan Lu wrote: Hi build-dev, I've got a minor change to fix an invalid path from README.txt of MemoryMonitor demo, could anybody please help to take a look? http://cr.openjdk.java.net/~luchsh/7165722/ Best regards! - Jonathan 7165722 was submitted as an incident and

Re: Review Request: Build-infra update

On 16/05/2012 13:32, Erik Joelsson wrote: The build-infra project has been quite productive and would like to push an update to the new build in jdk8. All webrevs can be found here: http://cr.openjdk.java.net/~erikj/build-infra-m1.1/ W

Re: Need reviewer - @GenerateNativeHeader

Kelly, Can you hold off pushing this for a few days? While this is compile-time only dependency I think the impact needs further study. -Alan. On 23/05/2012 02:14, Kelly O'Hair wrote: 7170969: Add @GenerateNativeHeader to classes whose fields need to be exported for JNI http://cr.openjdk.j

Re: Review Request: Build-infra update

On 23/05/2012 08:30, Erik Joelsson wrote: I'm also not sure if Alan's comment was a blocker. The idea with GenerateNativeHeader was approved by Jon Gibbon's initially at least. Alan? I don't like holding things up but I do think this needs wider consideration. -Alan

Re: Review Request: Build-infra update

On 23/05/2012 17:50, Kelly O'Hair wrote: Has anyone tried creating an unused native method declaration in the class to trigger the native header generation? public native void GenerateNativeHeader(); ??? Is that too ugly? -kto As Jon put it, for the classes in the base module, "we are del

Re: Review Request: Build-infra update

On 04/06/2012 15:15, Erik Joelsson wrote: I have created a (hopefully temporary) hack to run javah manually for these 5 classes. This webrev is just against the build-infra repo. Unless anybody objects to this temporary solution, I will publish a new full webrev against the jdk8/build forest to

Re: Review Request: Build-infra update

On 04/06/2012 17:52, Kelly O'Hair wrote: ./share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java:@GenerateNativeHeader ./solaris/classes/sun/nio/ch/sctp/AssociationChange.java:@GenerateNativeHeader ./solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java:@GenerateNativeHeader ./solaris/classes/sun

Re: [PATCH FOR REVIEW] System Zlib Support

On 31/07/2012 00:24, Andrew Hughes wrote: Ok for the build forest? Once reviewed then I think jdk8/tl would be better as that's the route that the changes to the zip code take. -Alan.

Re: The future of partial builds

I think this is a great topic to discuss. At least within Oracle then I think the majority of people do partial builds in their local environment. When I say "partial build" then I mean they build a subset of repositories, not all of them. So folks working in the jdk repository tend to just b

Re: Is the "skip boot cycle" trick still needed?

On 10/09/2012 20:42, Andrew Hughes wrote: : Yes, jtreg tests would catch this too, but they take more time& configuration than a simple second build, plus there are tests that are known to fail and areas that aren't tested. A topic for another thread but the goal is that all tests should pass

Re: The future of partial builds

On 10/09/2012 15:20, Magnus Ihse Bursie wrote: : In build-infra, there is currently a "somewhat partial build" feature that is implemented like this: 1) You check out a "master forest", containing all repos. You only need to do this checkout once, and you are not required to pull/update it (

Re: The future of partial builds

On 10/09/2012 15:00, Magnus Ihse Bursie wrote: In the new build system, fast incremental builds of Java code is dependent on the new "smart javac", which unfortunately has still not proven stable enough to be enabled by default, even in the experimental build-infra forest. It is still our hop

Re: The future of partial builds

On 11/09/2012 19:23, Fredrik Öhrström wrote: Den tisdagen den 11:e september 2012 skrev Alan Bateman: So far my experience is that touching native code and re-building is super fast, it's on par to executing specific make files in the old build (while wearing the appropriate a

Re: The future of partial builds

On 12/09/2012 06:46, Fredrik Öhrström wrote: : Excellent. I hope you realize how valuable it is that the build system recompiled the proper source files, then proceed to generate the the jni headers output because of native methods in those classes that were recompiled, then proceed to recompi

Re: The future of partial builds

On 12/09/2012 19:49, Kelly O'Hair wrote: Some stats on incremental builds. Not partial builds.. This is an older Solaris machine svc6.us.oracle.com, building the complete openjdk forest from scratch for 64bit including images took less than 14 minutes (parallel build setting was 8) and images

Re: Review request for 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false

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 local repo is a clone of jdk8/tl. It probably doesn't matter if this goes in via jdk8/tl. -Alan.

Re: Review request for 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false

On 17/10/2012 19:11, Mandy Chung wrote: 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 JA

Re: Make File Changes For CR4239752

On 23/10/2012 09:16, Erik Joelsson wrote: : The first question then is whether a native header is still needed for java_io_FileSystem? Are the constants used in native code? Do they still belong in this class given that the method moved? I have no idea, so I'm asking you. Yes, with Dan's ch

Re: Make File Changes For CR4239752

On 23/10/2012 19:47, Dan Xu wrote: Thank you for all your good comments. After adding the @GenerateNativeHeader annotation, I am able to build the jdk using the new build. But where can I check whether this class is part of the base module in jigsaw? Or should I just use the annotation as the

Build changes for 7176225: Remove JDBC-ODBC Bridge

We're jettisoning the legacy JDBC-ODBC bridge from Oracle's jdk8 builds and this means updating several make files. Here's the webrev: http://cr.openjdk.java.net/~alanb/7176225/webrev/ I believe I got everything in the both builds. The only thing that isn't clear is the old Def-solaris.gmk a

Re: Build changes for 7176225: Remove JDBC-ODBC Bridge

On 26/10/2012 21:14, John Yeary wrote: Hello All, Out of curiosity what will replace it? I looked at the transitional notification[1], but it leaves me feeling a little uneasy about it. At one point, I worked on a number of "simple" applications which used MS Access as the database for a Java Sw

Re: Build changes for 7176225: Remove JDBC-ODBC Bridge

On 29/10/2012 12:41, John Yeary wrote: Thanks Ulf, that was my exact point Ulf. Although, you were much more eloquent. One of the most consistent things that Java has done is ensuring backwards compatibility. The removal of something like the JDBC-ODBC bridge will cause issues later. We tell peo

Re: [8]Review request: 8001231 : Move locale data out of rt.jar (except the US locale)

On 30/10/2012 16:33, Naoto Sato wrote: Hello, I need someone to review my changes to the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231 The fix is to move locale data out of rt.jar into localedata.jar which will be optional in the compact profile (http://openjdk.ja

Re: RFR 8003161: Cannot build jdk8/build using the new build system after latest merge.

On 08/11/2012 09:59, Fredrik Öhrström wrote: It seems that some changes (like introduction of cmshalf.c) did not update the new makefiles and caused the OpenJDK only build to fail. http://cr.openjdk.java.net/~ohrstrom/webrev-8003161-root/ http://cr.openjdk.java.net/~ohrstrom/webrev-8003161-jdk/

Re: solaris builds and new infra.....

On 28/11/2012 19:45, Kumar Srinivasan wrote: Hi, Is it possible for the new infra, to produce a composite image of both server and client VMs on Solaris 32-bit --with-jvm-variants=client,server --with-target-bits=32 For extra credits is it possible to build the 64 bit image as well and ha

Re: Review Request: 8004131: move jdi tests out of core testset

On 29/11/2012 02:08, Stuart Marks wrote: Hi all, The JDI tests have proven to be fairly unstable and are causing a lot of spurious failures in our JPRT and nightly jobs. Instead of moving all the tests into the problem list, we've decided to move the 'jdk_jdi' test target out of the 'core' te

Re: solaris builds and new infra.....

On 29/11/2012 04:01, Kelly O'Hair wrote: On Nov 28, 2012, at 12:27 PM, Alan Bateman wrote: : I don't know about that, but the "overlay-images" will create the 64-bit overlay that we are used to. Personally I think we should get rid of the overlay have have separate 32-b

Re: solaris builds and new infra.....

On 30/11/2012 17:05, Kelly O'Hair wrote: : The overlay image has been one of these special cases that I would like to avoid, but at the same time, building two rt.jar files for the 32bit and 64bit images seems pretty silly too. So for the sake of simplicity, I'm willing to take the "build two r

8004491: Build breakage on Linux due to 8004188

The new build is broken in jdk8/tl again, this time it's Linux only and the culprit is this change: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44ae777564eb Attached is the proposed change. I'd like to push it to jdk8/tl/jdk. -Alan diff --git a/makefiles/CopyFiles.gmk b/makefiles/CopyFiles.

Re: 8004491: Build breakage on Linux due to 8004188

On 05/12/2012 11:23, Chris Hegarty wrote: Looks fine me. -Chris. Thanks, I'd like to get someone from the build group to okay this too. -Alan

Build changes for 8004371: (props) Properties.loadFromXML needs small footprint ...

We're reviewing this one on core-libs-dev and the changes involve a small build change to accommodate new locations in src/share/classes/jdk/internal. As it's just pure java code then there is no impact to the new build; for the old build we just need a top-level Makefile, the make/jdk/asm/Ma

Re: Workaround for partial builds

On 21/12/2012 12:58, Fredrik Öhrström wrote: : The example Erik gave: make jdk-only JDK_FILTER=java/awt Be aware that this workaround is of limited use, since it does not assist in recompiling dependent packages, if the public api of java.awt was changed, you need to know the 79 other packages

Re: Encoding problem when building

On 04/01/2013 05:29, Frank Ding wrote: Hi Kelly I investigated how local specific characters get into generated sources in corba module. Those classes are generated by following command idlj c:/openjdk/dep/jdk1.7.0_02/bin/idlj -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-Lo

X11/Intrinsic.h not found, ALT_X11_PATH=/opt/X11

I upgraded a Mac to 10.8.2 and Xcode 4.5.2 over the break, now I'm trying to get the jdk7u/jdk7u-dev, jdk8/tl and jigsaw/jigsaw forests building again. I installed XQuartz 2.7.2 so I have X11 and jdk8/tl builds fine with the new build (except for the "images" target, there's an issue with sed

Re: X11/Intrinsic.h not found, ALT_X11_PATH=/opt/X11

On 07/01/2013 10:03, Joel Borggrén-Franck wrote: On 7 jan 2013, at 10:43, Alan Bateman wrote: I upgraded a Mac to 10.8.2 and Xcode 4.5.2 over the break, now I'm trying to get the jdk7u/jdk7u-dev, jdk8/tl and jigsaw/jigsaw forests building again. I installed XQuartz 2.7.2 so I have X1

Re: Review request: 8005096: Move a few source files in swing/beaninfo and in a demo.

On 07/01/2013 13:57, Fredrik Öhrström wrote: : The makefile comments, comment on the fact that Java sources that reside inside make/tools are in fact part of the dt.jar (ie part of the jdk, not just a tool). However this is not that easy to fix, since the actual tool that generates the swing cla

Re: Review Request: 8005856: build-infra: Remove special handling of base module classes header generation

On 08/01/2013 14:07, Erik Joelsson wrote: Five classes which in jigsaw will be located in the base module currently have their native headers generated in a special way (explicitly with javah). This was because the base module could not be made dependent on the compiler module where the annotat

Re: Review Request: 8006100: build-infra: Bundle up the correct images in jprt

On 14/01/2013 13:24, Erik Joelsson wrote: This didn't quite work as I expected. Found the issue in needing to include SPEC before Jprt.gmk so that variables from SPEC would be available in Jprt.gmk at parse time. http://cr.openjdk.java.net/~erikj/8006100/webrev.root.02/ /Erik Thanks Erik, I'v

Re: Review Request: 8006296: build-infra: Unsigned sunmscapi.jar is missing manifest.

On 15/01/2013 11:13, Erik Joelsson wrote: This fix adds the missing manifest to sunmscapi.jar. This should fix javax/crypto/sanity/CheckManifestForRelease.java which is currently failing for build-infra builds. http://cr.openjdk.java.net/~erikj/8006296/webrev.jdk.01/ /Erik This looks good to

Re: Codereview request for 8003680: JSR 310: Date/Time API

On 22/01/2013 19:09, Xueming Shen wrote: Hi, Webrev has been updated to address the build issue in the new build infra. M (1) added the java.time packages into common/makefiles.javadoc/CORE_PKGS.gmk to be included into ct.sym http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/ (2) not

Re: Codereview request for 8003680: JSR 310: Date/Time API

On 22/01/2013 22:19, David Holmes wrote: All of the jar building was modified so that jars go into images/lib not jdk/lib. So it should not be necessary (or desirable) to build into jdk/lib and then copy over. Sherman can confirm, but I believe the TzdbZoneRulesProvider requires it in the lib d

Re: RFR : 8006594/8006595 : Define jdk_core test set

On 22/01/2013 21:15, Mike Duigou wrote: Hello all; This is a two piece patch. 8006594: Add jdk_core target to jdk/test/Makefile 8006595: Use jdk/test/Makefile targets in preference to local definitions I chose to do it as two patches because the changes are in different repos and the changes

Re: Review Makefile Changes For JDK-8001334 - Remove use of JVM_* functions from java.io code

On 24/01/2013 00:23, Martin Buchholz wrote: : Many years ago I filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4904617 that remains unaddressed :-( Perhaps as part of this change or set of changes, that bug could be dealt with? Perhaps even by deleting JVM_Read? I believe there is effor

Re: Review Request: 8006873: SWAT-b74 msvcr100.dll does not have the permission for all

On 29/01/2013 14:54, Erik Joelsson wrote: Adding a chmod when copying msvcr100.dll into the jdk output dir. The unix permissions shouldn't be needed on windows, but if the bundles are unzipped on unix and accessed over nfs or samba, permissions matter. http://cr.openjdk.java.net/~erikj/8006873

8007436: (profiles) Add JSR-310 to Compact Profiles contents

As David mentioned in another mail, he is hoping to push the profiles work to jdk8/build next week. One update that is needed to the configuration is the changes to take account of ThreeTen (java.time.**). This includes taking into account the ThreeTen updates for M7 that remove the old time

Re: XS RFR: 8008424: Isolate PROFILE make variable from incidental setting in the environment

On 19/02/2013 09:20, David Holmes wrote: On 19/02/2013 6:27 PM, Erik Joelsson wrote: Looks good to me. Thanks Erik. I guess I also need a jdk8 Reviewer ? David It looks fine to me too. -Alan.

hg: jdk8/build/jdk: 2 new changesets

Changeset: 6f4615fd32da Author:alanb Date: 2013-02-19 11:08 + URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6f4615fd32da 8007097: (profiles) Build needs test to ensure that profile definitions are updated Reviewed-by: dholmes, erikj - make/tools/src/build/tools/RemoveMeth

Re: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure

On 20/02/2013 14:20, Erik Joelsson wrote: Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the target bootcycle-images. Also fixing an issue with bootcycle-images target that prevented them from creating images. http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/ /Erik This

Re: "j2sdk-image" and new build system

On 23/02/2013 10:29, David Holmes wrote: Just be aware there's a lot more involved in doing this than just changing one a name in a makefile. You beat to me too! Yes, there are likely a lot of scripts and paths that assume the image name is j2sdk-image or j2re-image so renaming will be a bi

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 22/02/2013 22:03, Martin Buchholz wrote: Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread "main" java.lang.InternalError at java.util.zip.Inflater.init(Native Met

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 23/02/2013 18:06, Martin Buchholz wrote: I am actually encountering this in openjdk7 with the old build system. I can repro the problem in openjdk8 with the old build system, but not the new one. I don't know if you consider this a bug with the new build system - it's supposed to generate

8008808: Allowed dependencies added by JDK-8008481 no longer required

Last week, David Holmes had to do a temporary addition to refs.allowed (used by the dependency analyzer in the profiles build) in order to get profiles over the line (a last minute glitch caused by closed code). The temporary addition can now be removed so I'd like to get that done before it

8008977: profiles build broken by Nashorn build changes

The build changes for Nashorn were pushed to jdk8/tl yesterday and one of the casualties is the profiles build. My reading of the make file changes is that ListPathsSafely_If (defined in MakeBase.gmk) has changed the expansion so that secondary expansion is no longer required. Erik is away t

8008978: nashorn-rules.gmk missing

While looking at the Nashorn build changes, I see that /make/nashorn-rules.gmk is included by the top-level Makefile but was missed in the change-set. I checked with Jim Laskey and it he sent me the missing .gmk which I've put here: http://cr.openjdk.java.net/~alanb/8008978/webrev/ I plan

Re: 8008978: nashorn-rules.gmk missing

On 26/02/2013 14:10, Chris Hegarty wrote: On 02/26/2013 01:52 PM, Alan Bateman wrote: While looking at the Nashorn build changes, I see that /make/nashorn-rules.gmk is included by the top-level Makefile but was missed in the change-set. Wow, a whole missing rules file! I'm surprised

8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes

I ran into another issue cause from Nashorn build changes, also secondary expansion related. The issue is that some classes are going into rt.jar that shouldn't be there, particularly the SunEC provider, some charset classes too. I would like to push the attached patch to jdk8/tl to fix these

Re: Dollar ($) expansion still needs attention

On 27/02/2013 02:47, David Holmes wrote: : So the same file names are listed once with \$$ and once with \, and they both have to be that way to work! This is untenable. There should only be one way to write the name of a nested class file inside the makefile. FYI in Profiles.gmk when

8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows

This is another patch to get jdk8/tl building again after the Nashorn build changes. The changes for 8009021 [1] that were pushed to jdk8/tl/nashorn yesterday break the build on Windows. The problem is that NASGEN_SRC and ASM_SRC shouldn't have $(FIXPATH) in the value. Kudos to David Holmes

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 27/02/2013 23:16, Martin Buchholz wrote: I have another iteration of this change http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ that adds exciting new exception detail message for the InternalError I was scrat

Re: demos and images

On 27/02/2013 19:44, Mike Duigou wrote: The demos target is being built as a pre-requisite to building images. This was probably done for compatibility the the old build system. How soon before we can we break this bogusness? Mike The demos have traditionally been included in the SDK image (de

Re: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so

On 28/02/2013 16:11, Martin Buchholz wrote: On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman <mailto:[email protected]>> wrote: The update to make/java/zip/Makefile looks good to me, we should have done it a long time ago. I assume you are pushing ahead on this be

Re: 8008977: profiles build broken by Nashorn build changes

On 04/03/2013 11:20, Erik Joelsson wrote: The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be bet

Re: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure

On 05/03/2013 15:14, Erik Joelsson wrote: : Discovered some more problems with the bootcycle-images target that needed to be fixed. A full bootcycle build is still not possible due to errors like this: /localhome/mercurial/closed-jdk8-build/jdk/make/tools/src/build/tools/javazic/GenDoc.java:

--with-zlib=system supposed to work?

I've been meaning to ask this for a while but is --with-zlib=system supposed to work? With the old build then there is a build variable to use the system zlib but it only worked (to my knowledge) when doing dynamic linking of C++ runtime. Attached is what I get currently and maybe we have

Re: RFR: 8009428 and 8009429 - Profile related fixes and clean ups

On 08/03/2013 01:48, David Holmes wrote: Not sure which is best list for this given Alan will likely be the only reviewer anyway :) Webrevs under: http://cr.openjdk.java.net/~dholmes/8009428_8009429/ As further background to others, the reverting of the $ substitution became possible when Nas

  1   2   3   4   5   6   7   8   >