Re: RFR 9: 8074818: Resolve disabled warnings for libjava
Hi, Sadly, but not entirely unexpectedly there is an anomaly in the include files: It seems that Windows does not define O_SYNC and O_DSYNC. To make up for the absence jdk/src/java.base/share/native/libjava/io_util.h conditionally defines them. There is no problem if the system include files appear first, but in the other order, fcntl.h tries to re-define it. In the recommended order, there is no issue. Roger On 5/22/15 1:47 PM, Martin Buchholz wrote: It's a good idea to order include statements by system dependencies, jdk dependencies, implementation helpers, BUT order of include statements should never ever matter. If it does, then we have a bug that should be fixed. Every header file should be independently includable, and C files should only Include What They Use. It would be good for us to test some of that, e.g. can you compile each .h file as its own translation unit? +#include fcntl.h +#include limits.h + #include jni.h #include jni_util.h #include jlong.h @@ -32,9 +35,6 @@ #include java_io_FileInputStream.h -#include fcntl.h -#include limits.h -
Re: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent Product version
Any chance I could get a review on this? /Erik On 2015-05-20 16:09, Erik Joelsson wrote: Thanks, changed to: Windows native binaries have inconsistent Product version Changed the label. /Erik On 2015-05-20 14:49, Seán Coffey wrote: It might be good to edit the bug synopsis before pushing the change. I don't think this issue is specific to java.net bundles. Might also be useful to use the noreg-sqe label rather than noreg-build given that SQE team do appear to have test code for this area. Approved pending code review. Regards, Sean. On 20/05/15 13:32, Erik Joelsson wrote: Please review and approve this fix for 8u60. On windows, native libraries and executables have version numbers embedded into them. These can be seen when right-clicking the binary in explorer, on the Details tab, as Product version. Currently in 8 update releases, these versions strings are inconsistent. An example: in 8u45 b09 we have: bin\client\jvm.dll: 8.0.0.9 bin\decora_sse.dll: 8.0.45.09 bin\deploy.dll: 8.0.450.9 bin\java.exe: 8.0.45.9 These differences fall into 4 different categories. 1. jvm.dll in hotspot is not picking up the update version at all. This is due to a bug in the build-infra makefile rewrite that wasn't discovered in JDK 8 because it didn't have an update version. 2. decora_sse.dll is part of javafx. Fixing their version scheme is out of scope of this fix. A separate bug for javafx would be needed. 3. deploy.dll is actually the correct one. Historically we have encoded the update version with an extra digit for a potential letter at the end of the string. 4. java.exe, and the rest of the binaries from the jdk repository lost their extra 0 in the build-infra makefile rewrite and it wasn't discovered in JDK 8. Since we no longer use letters in update version strings, we could fix this by removing the extra 0. However, we have already released 8 updates where some binaries have the extra 0. Removing it would mean releasing 8u60 with binaries having version numbers lower than previous updates. For this reason I propose fixing this by adding the 0 for JDK and Hotspot binaries again, and of course by supplying the correct variable to the hotspot makefiles so that it even gets the update version in there. For clarity, with this patch, the above will log like this: bin\client\jvm.dll: 8.0.450.9 bin\decora_sse.dll: 8.0.45.09 bin\deploy.dll: 8.0.450.9 bin\java.exe: 8.0.450.9 Note that in JDK 9, the version number scheme is being completely reworked so this will not be an issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 Webrev: http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html /Erik
Re: AWT Dev RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc
+1 -phil. On 05/21/2015 12:11 AM, Erik Joelsson wrote: Hello Pete, This looks good to me. /Erik 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/ Background: - As part of the open sourcing of the JAB and Java Accessibility Utilities (JAU) the JAU Javadoc was setup to be added to the build. - Due to a 8u build issue (it uses source bundles) the Javadoc had to be temporarily disabled: JDK-8076552 - The issue was caused by JAU code being in windows instead of share. - For 9 the JAU code is in jdk.accessibility/share/classes/com/sun/java/accessibility/util (and the JAB code under jdk.accessibility/windows). - For 8u both the JAU and JAB code is in jdk/src/windows. - The problem on 8u is with non-windows builds; the 8 Javadoc build process doesn't find the JAU files because they are in a windows directory. - The fix is to refactor so 8u is like 9 with the JAU files in share; then the javadoc build process will find the source for all build platforms. - Make has been changed so jaccess.jar is built for all platforms - Some obsolete files have been removed as they were causing build problems. They were removed from 9 earlier but not from 8u. These are com/sun/java/accessibility/util/java/awt/ChoiceTranslator.java and all the files in com/sun/java/accessibility/extensions. Thanks, Pete
