Re: pre-submit tests for github PRs

Ah. -phil On 5/23/22 8:18 AM, Langer, Christoph wrote: Hi, that's because the PR is a based on a pre-loom version of master. Best regards Christoph -Original Message- From: build-dev On Behalf Of Philip Race Sent: Montag, 23. Mai 2022 17:14 To: Aleksey Shipilev ; Ioi Lam ; build

Re: pre-submit tests for github PRs

BTW I am wondering whether I should believe this explanation since it does pass sometimes, eg : https://github.com/openjdk/jdk/pull/8820 How is that possible ? -phil On 5/23/22 8:05 AM, Aleksey Shipilev wrote: On 5/23/22 16:53, Ioi Lam wrote: On 5/23/2022 4:41 AM, Alan Bateman wrote: On

Re: pre-submit tests for github PRs

Yet right "at the top" of the list is Linux 86 ...  do we have no way to put it on some 2ndary list ? -phil. On 5/22/22 3:58 PM, David Holmes wrote: On 23/05/2022 8:22 am, Philip Race wrote: Why is it that the vast majority of PRs are recording spurious looking failures of github

pre-submit tests for github PRs

Why is it that the vast majority of PRs are recording spurious looking failures of github pre-submit tests ? https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr There seems to be so much noise in these that I pay no attention to them any more (except for jcheck) but they

Re: AWT & Swing tests failed: Function frag_col has a deployment target which is incompatible with this OS.

A bug should be filed but if it is specific to using xcode 12.5 we won't have seen any issue yet at Oracle as all official builds use xcode 12.4. However at some point (JDK 19) we'll likely upgrade and then it'll be an issue. -phil. On 10/27/21 3:02 AM, Jayathirth D V wrote: Hi Vitaly,

Re: RFR: 8255790: GTKL: Java 16 crashes on initialising GTKL on Manjaro Linux [v3]

You are right there's no check. One could be added by a motivated party .. The minimum for Linux may be as old as 1.2.3  but safer is 2.3.1 since we rely on that for AAT font support. I can't (quickly) speak to any important bug fixes in later releases we may need, just API / functionality.

Re: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0

I built with gcc 10.3 https://bugs.openjdk.java.net/browse/JDK-8265373 I expect we can accommodate disabling one more warning to support more compilers. -phil. On 5/4/21 12:31 PM, Florian Weimer wrote: * Phil Race: Upgrade to harfbuzz 2.8 I believe this causes a build failure with GCC

Re: RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

I have worked out how to pass this option to at least the jtreg tests for the lanai headful mach5 job, so once this is fixed we can check it out in jtreg and get some level of confidence  that we are checking all the important cases. Note that we know some tests will fail just because it spits

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module

no return type specified; defaults to 'id' [-Werror,-Wmissing-method-return-type]  - init:(JNIEnv *)env as:(const char *)javaExceptionType reason:(const char *)reasonMsg;  ^ -phil. On 2/1/21 8:02 AM, Philip Race wrote: Per my comment in the PR I am currently working on updating it to handle

Re: RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module

Per my comment in the PR I am currently working on updating it to handle the test update needed. Once the other in-flight PRs are integrated, my grepping says that the only remaining build change needed after that is to remove one disabled warning in make/autoconf/flags-cflags.m4 I am

Re: RFR: 8251854: [macosx] Java forces the use of discrete GPU

From the CSR ; >This change also improves the startup performance, on my current new > laptop mbp 16 + BigSur 11.1 the switching discrete/integrated causes unexpected delays up to 10 seconds. This also has to be a bug. I thought it had gone away. Have we reported that to Apple ? If not we

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

a specific native library. The build is parallel at a higher level but not at that lower level. -phil On 11/17/20, 10:00 AM, Florian Weimer wrote: * Philip Race: There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. -phil. On 11/17/20, 9:01 AM, Florian Weimer wrote: * Phil Race: This upgrades JDK

Re: RFR: 8074844 : Resolve disabled warnings for libfontmanager

at it if they want as a separate fix. -phil. On 8/27/20, 12:45 PM, Sergey Bylokhov wrote: Hi, Phil. Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus. On 27.08.2020 12:39, Philip Race wrote: Bug : https://bugs.openjdk.java.net/browse/JDK

RFR: 8074844 : Resolve disabled warnings for libfontmanager

Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html This resolves the disabled compiler warnings in what is now quite a small fontmanager library. I've built windows, mac and linux in our build system and run our full battery of

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

-phil I guess by default they try to "maximize battery life": https://support.apple.com/en-us/HT202043 -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ?

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

Is there any performance cost to doing this ? I'd expect so. Any estimate ? And there's then no way to explicitly request the discrete card on a 15/16" MBP. Should we release note this ? -phil On 8/21/20, 3:02 AM, Magnus Ihse Bursie wrote: On 2020-08-21 06:55, Sergey Bylokhov wrote:

Re: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager

path. -phil. On 8/11/20, 2:38 AM, Magnus Ihse Bursie wrote: On 2020-08-10 22:47, Philip Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8251367 webrev: http://cr.openjdk.java.net/~prr/8251367/ When using something other than the java launcher (ie the jpackage launcher) harfbuzz.dll

Re: RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

-31 10:58, Philip Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8250894 webrev : http://cr.openjdk.java.net/~prr/8250894/ Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated out libharfbuzz from libfontmanager, it would be natural for distros to want to link against

RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

bug: https://bugs.openjdk.java.net/browse/JDK-8250894 webrev : http://cr.openjdk.java.net/~prr/8250894/ Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated out libharfbuzz from libfontmanager, it would be natural for distros to want to link against the libharfbuzz that they

Re: [OpenJDK 2D-Dev] RFR (XS) 8250605: Linux x86_32 builds fail after JDK-8249821

OK .. although I hope to come back in JDK 16 and eliminate all disabled warnings from the now much smaller libfontmanager : https://bugs.openjdk.java.net/browse/JDK-8074844 -phil. On 7/27/20, 5:41 AM, Erik Joelsson wrote: Looks good to me. /Erik On 2020-07-27 00:28, Aleksey Shipilev wrote:

Re: RFR: 8249821: Separate libharfbuzz from libfontmanager

493-494: Too much indent /Erik On 2020-07-21 14:39, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8249821 Webrev: http://cr.openjdk.java.net/~prr/8249821/ This fix breaks out libharfbuzz from libfontmanager. As well as building I've done extensive testing on all platforms. I

RFR: 8249821: Separate libharfbuzz from libfontmanager

Bug: https://bugs.openjdk.java.net/browse/JDK-8249821 Webrev: http://cr.openjdk.java.net/~prr/8249821/ This fix breaks out libharfbuzz from libfontmanager. As well as building I've done extensive testing on all platforms. I have tweaked the disabled warnings so we don't have un-needed

Re: [15] RFR: JDK-8246094: [macos] Sound Recording and playback is not working

LGTM. -phil On 7/21/20, 12:24 PM, Erik Joelsson wrote: Here is a late fix for Macos Catalina. In JDK-8244951, I added a missing entitlement to enable sound recording with the hardened runtime signing. It was later discovered that this wasn't quite enough. To be able to record sound you also

Re: build problems with man pages on linux

I thought that if the version of pandoc is not suitable, the build skips man pages. No idea if pandoc 2.3.1 is available for Ubuntu 16.04. -phil. On 6/22/20, 5:10 PM, Jonathan Gibbons wrote: You need something like pandoc 2.3.1 -- Jon On 6/22/20 4:58 PM, Philip Race wrote: from Ubuntu

Re: build problems with man pages on linux

, What version of pandoc are you using? One from jib, or some other version, e.g from Linux. -- Jon On 6/22/20 4:42 PM, Philip Race wrote: I've been working on Windows and Mac issues for the last several weeks so it has been some time since I even tried to build JDK on my Ubuntu 1604 system

build problems with man pages on linux

I've been working on Windows and Mac issues for the last several weeks so it has been some time since I even tried to build JDK on my Ubuntu 1604 system. In the interim it seems to have stopped working. I get these errors : LauncherCommon.gmk:223: recipe for target

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

Kim, Until it says in "the JDK" and not "in HotSpot" you have not addressed my main point. Please rename the JEP. -phil. On 6/13/20, 8:48 PM, Kim Barrett wrote: On Jun 10, 2020, at 2:26 AM, Kim Barrett wrote: On Jun 8, 2020, at 4:07 PM, Philip Race wrote

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

Hi Kim, Can we amend the JEP itself to be not solely about hotspot. Since it affects other areas I think that 1) They may need to be compiled with C++14 enabled whether they use new features or not 2) They may want - or need - to adopt C++11 or C++14 features too. You already know that soon

Re: Mac OS X 32bit x86 build fails for jdk12u

I think you are right. I don't remember even JDK 7 having a 32 bit version. There may have been some unused partial support to create one, but we never shipped such a thing - nor were there internal 32 bit builds. Also macOS 10.15 doesn't support 32 bit applications. So when 10.14 goes EOSL in

Re: macOS hardened runtime issue - missing entitlements

sible information and are not accessible without the corresponding entitlement, just as the microphone. El 13 may 2020, a las 17:43, Philip Race <mailto:philip.r...@oracle.com>> escribió: What OpenJDK functionality are you using that provides camera access ? I know of no such API. -phil. On

Re: macOS hardened runtime issue - missing entitlements

What OpenJDK functionality are you using that provides camera access ? I know of no such API. -phil. On 5/13/20, 1:18 AM, Adrián Ruiz Arroyo wrote: Hello, I filled an issue a few days ago

RFR: 8242325: Remove VIS version of medialib

Bug: https://bugs.openjdk.java.net/browse/JDK-8242325 Webrev : http://cr.openjdk.java.net/~prr/8242325/ With the impending removal of the Solaris SPARC port, there is even less point than before to keeping around the VIS version of medialib, and versions of the 2D rendering loops that call

Re: [14] Review Request: 8233827 Enable screenshots in the enhanced failure handler on Linux/macOS

That didn't answer all my questions, at least not in a way that I can understand. How is this useful given that we disable jtreg failure handlers for the headful tests ? -phil. On 12/30/19, 11:33 AM, Sergey Bylokhov wrote: On 12/23/19 9:15 pm, Phil Race wrote: I am not sure what the right

Re: RFR: JDK-8230067: Add optional automatic retry when running jtreg tests

Looks good to me (and worked fine in my testing). -phil. On 12/5/19, 3:21 PM, Erik Joelsson wrote: The issue with jtreg has now been fixed in b16. Here is an updated webrev: http://cr.openjdk.java.net/~erikj/8230067/webrev.02/index.html /Erik On 2019-08-23 14:10, Erik Joelsson wrote: There

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

> I believe otherwise it is an accurate incremental webrev of the jpackage changes since EA-5. It is also not very incremental. * *src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/main/Main.java is definitely not "new" ... -phil. On 11/26/19, 2:17 PM, Andy Herrick wrote: yes,

Re: [OpenJDK 2D-Dev] PING: RFR: 8220074: Clean up GCC 8.3 errors in LittleCMS

OK -phil. On 11/18/19, 5:34 PM, Yasumasa Suenaga wrote: PING: Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8220074 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/ I think it is a trivial change. Yasumasa On 2019/11/13 11:42, Yasumasa

Re: [OpenJDK 2D-Dev] RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar

No other comments so far so here's that update : http://cr.openjdk.java.net/~prr/8224778.1/ -phil. On 5/24/19, 2:41 PM, Philip Race wrote: Yes, I just copied that line + edited it. I can update both lines if that is what you are asking but I'll wait a little to see if there are any other

Re: RFR: 8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar

Yes, I just copied that line + edited it. I can update both lines if that is what you are asking but I'll wait a little to see if there are any other comments first. -phil. On 5/24/19, 2:16 PM, Erik Joelsson wrote: Hello Phil, Patch looks good, but the curly braces look weird in a makefile.

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Adding build-dev for the build changes. I don't know if these were previously reviewed there, but I am not sure what the changes in NativeCompilation.gmk have to do with jpackage. -phil. On 4/24/19, 5:47 PM, Andy Herrick wrote: On 4/24/2019 8:44 PM, Andy Herrick wrote: Please review

RFR: 8222362: Upgrade to Freetype 2.10.0

freetype 2.10 has been released and this fix upgrades the JDK's internal copy from the previous latest of 2.9.1 Bug : https://bugs.openjdk.java.net/browse/JDK-8222362 Webrev : http://cr.openjdk.java.net/~prr/8222362/ Built on all platforms - tested using --with-freetype=bundled Automated

Re: [OpenJDK 2D-Dev] [13] RFR: JDK-8217707: JNICALL declaration breaks Splash screen functions

> I've run SplashScreen jtreg tests, all tests pass. I assume you mean you did this for 32 AND 64 bit builds ? If so, then +1 -phil. On 3/28/19, 9:11 AM, Alexey Ivanov wrote: Any volunteers for review? On 24/03/2019 19:18, Alexey Ivanov wrote: Hi, Please review the fix for jdk 13. bug:

Re: RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1

On 28/02/2019 16:12, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Webrev: http://cr.openjdk.java.net/~prr/8210782/ This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which is currently the latest release of harfbuzz harfbuzz is the 3rd party (e

RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1

Bug: https://bugs.openjdk.java.net/browse/JDK-8210782 Webrev: http://cr.openjdk.java.net/~prr/8210782/ This change upgrades JDK 13 from using harfbuzz v 1.8.1 to v 2.3.1 which is currently the latest release of harfbuzz harfbuzz is the 3rd party (external) C++ library used by OpenJDK for

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

Category 3 has to deal with plenty of native code too ... -phil On 1/25/19, 9:15 AM, Martin Buchholz wrote: In our own wrappers around configure, we've introduced the concept of a "developer mode". But this thread suggests there are 3 populations of users invoking configure: 1. release

Re: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file o

+1 from me. -phil. On 11/29/18, 7:27 PM, Sergey Bylokhov wrote: Then it can be simplified further: http://cr.openjdk.java.net/~serb/8212680/webrev.01 I added the new option since I am not sure how important the usage of "PNG_MAXIMUM_INFLATE_WINDOW or PNG_SKIP_sRGB_CHECK_PROFILE" As I said,

Re: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file o

On 11/29/18, 9:38 AM, Sergey Bylokhov wrote: On 28/11/2018 20:24, Philip Race wrote: Not something we want to do if there's any way out of it. can we just disable PNG_SET_OPTION_SUPPORTED in pnglibconfig.h which is something that is "generated" and not part of the png source ?

Re: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file o

Not something we want to do if there's any way out of it. can we just disable PNG_SET_OPTION_SUPPORTED in pnglibconfig.h which is something that is "generated" and not part of the png source ? I don't see anything that is important enabled by that option. -phil. On 11/28/18, 3:38 PM, Erik

Re: [12] Gcc 8.1 HarfBuzz library compilation issues

I have removed awt-dev and replaced it with the CORRECT 2d-dev list. Please reply to this one .. to get awt-dev out of the loop. I already have an open bug to upgrade harfbuzz I will be handling soon. If the necessary changes are there we are all good. We do not much like at all locally modifying

Re: hg: jdk/jdk: 8214007: Fix sun.awt.nativedebug on X11 platforms

Was this fix run through jdk-submit ? https://wiki.openjdk.java.net/display/Build/Submit+Repo -phil. On 11/19/18, 12:36 PM, David Holmes wrote: Volker & reviewers, This breaks the Solaris build: jib > Undefinedfirst referenced jib > symbol in file jib >

Re: (trivial, urgent) RFR(xxs): 8214075: [BACKOUT] 8214007: Fix sun.awt.nativedebug on X11 platforms

Thanks .. yes .. not so much need to test the reversion to the previous known good state. -phil. On 11/19/18, 1:29 PM, Thomas Stüfe wrote: Thanks guys. I pushed. ..Thomas On Mon, Nov 19, 2018 at 10:21 PM David Holmes wrote: On 20/11/2018 7:17 am, Thomas Stüfe wrote: p.s. does this need

Re: RFR: JDK-8213906: Update arm devkits with libXrandr headers

+1 -phil. On 11/15/18, 6:07 PM, Tim Bell wrote: Erik: Please review this change which bumps the devkits Oracle uses to build Linux arm/aarch64 internally. I forgot to update them when adding libXrandr to the main Linux x64 devkit. No code changes required in the devkit generator makefiles.

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

PS I am not sure why xrandr headers would not be available for AIX. They are a standard part of the xdistribution. If true, think what you are going to have to do is add a --with-xrandr-include option and provide it that way. -phil. On 11/15/18, 8:55 AM, Philip Race wrote: Hmm. I don't like

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

Hmm. I don't like the ifdefs. Xrandr is a requirement for the build. If its not there at runtime that's OK. -phil. On 11/15/18, 8:06 AM, Volker Simonis wrote: Hi, can I please have a review for the following small change: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213944/

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/13/18, 12:52 PM, Roger Riggs wrote: Hi, There are enough files unique to each platform to put them in separate packages otherwise you get too many (IMHO) files in a single package/directory and its harder to tell which go with which. There isn't much of a problem with classes

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

rrent process" There may be more like that. and as I mentioned offline, I think the correct word is "deregister" not "unregister" both in comments and method names. -phill On 11/12/18, 2:38 PM, Andy Herrick wrote: On 11/12/2018 4:54 PM, Philip Race wrote: On 11/12/

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

On 11/12/18, 1:45 PM, Andy Herrick wrote: On 11/12/2018 3:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support for receiving and handling file open events

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

nt storage location then default to the "unix" location if there's no match .. although I am not sure it makes sense on platforms that aren't targeted by jpackager. -phil. -phil. On 11/12/18, 12:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime r

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

where the parameter list of the new * activation in conflict with the existing activation -phil. On 11/12/18, 12:22 PM, Philip Race wrote: Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

Adding build-dev back .. I noticed that module jdk.jpackager.runtime requires java.desktop on all platforms So far as I can tell this is for a Mac-only support for receiving and handling file open events. Probably it only makes sense or gets used when the API is used from a running desktop

Re: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

I suspect I understand this one now .. the array is stack allocated so we don't want NULL but the compiler probably complained about possible uninitialised use of the values ? -phil. On 10/1/18, 9:38 AM, Philip Race wrote: You really do need to explain *each* of the changes better. This one

Re: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

You really do need to explain *each* of the changes better. This one .. why not NULL ? http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html -phil On 10/1/18, 9:19 AM, Philip Race wrote: Hi, 1) Has this been built

Re: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt

Hi, 1) Has this been built on all platforms ? 2) I can't find the list of warnings that you are seeing and fixing and they are all over the place. So adding 2d-dev and build-dev. For each of these changes, please show what was the warning that you received from the compiler This might sound

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

Some day, I'd like to replace a lot of medialib functionality with something like the proposed Vector API. But that is far enough away that medialib needs to be maintained, and unlike a previous discussion about a similar issue in the JPEG library, we are on the hook for maintaining medialib.

Re: [RFR]: 8209115: adjust libsplashscreen linux ppc64le builds for easier libpng update - was : RE: RFR 8195615 : libsplashscreen linux ppc64le build error after libpng update

://cr.openjdk.java.net/~mbaesken/webrevs/8209115.0/ <http://cr.openjdk.java.net/%7Embaesken/webrevs/8209115.0/> https://bugs.openjdk.java.net/browse/JDK-8209115 Thanks , Matthias *From:*Philip Race *Sent:* Dienstag, 7. August 2018 17:15 *To:* Baesken, Matthias *Cc:* Doerr, Marti

Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c

> It looks fine to me but I am a bit hazy about who to give attribution for the fix .. I pondered this for a little while and decided it should be joint between Adam who identified the issue and championed it and Thomas who I think first suggested the code change, modified only slightly at

Re: RFR: JDK-8203795: Change default compiler on Windows to VS2017

# The order of these defines the priority by which we try to find them. -VALID_VS_VERSIONS="2013 2012 2010 2015 2017" +VALID_VS_VERSIONS="2017 2015 2013 2012 2010" I think it better to have VS2013 as the 2nd option since 2015 was never an official compiler and people might have 2015 configs

Re: [11] Review Request: 8203308 Remove the appletviewer classes

I verified that applet based tests (manual + automated) still run in jtreg. So +1 -phil. On 5/22/18, 8:32 AM, Erik Joelsson wrote: Build changes look good. /Erik On 2018-05-21 19:39, Sergey Bylokhov wrote: Hello. Please review the fix for jdk11. Bug:

Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF)

I think I am 99% OK with this. In general I see what you are doing here and how you've presented the webrev. Treating even the new files as moved helps see the differences but it is still a challenge to follow all the moving pieces. So before we had just abstract class

Re: RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources

http://cr.openjdk.java.net/~prr/8191522.1 uploaded. Adding .. the removal of .. a couple of uses of lucida - sanity check of lucida in font config files is no longer needed. - J2DBench demo opts change from lucida to dialog. Not sure why it had lucida anyway .. -phil. On 5/16/18, 4:08 PM,

Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c

Hi, OK .. if you can convince upstream this is worth doing, then we can accept it as we would not regress when updating. As I noted previously : http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html this is still an issue in the currently being developed 9c train. -phil. On

Re: [OpenJDK 2D-Dev] RFR: JDK-8202052: Disable warnings when building libawt with VS2017

+1 -phil. On 4/19/18, 3:41 PM, Mikael Vidstedt wrote: Please review the following change which disables some warnings in libawt which show up when building with VS2017: bug: https://bugs.openjdk.java.net/browse/JDK-8202052 webrev:

Re: [11] Review Request: 8200146 Remove the appletviewer launcher

+1 -phil. On 3/30/18, 3:52 PM, Sergey Bylokhov wrote: Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200146 Webrev can be found at: http://cr.openjdk.java.net/~serb/8200146/webrev.00 CSR: https://bugs.openjdk.java.net/browse/JDK-8200549 Fix description:

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any platform for the new releases, then there aren't resources or effort being put into making sure it still builds. Our build systems might still support it, but for how long? It might effectively have to become a "port" that

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

he license and provide the text only for one or for both. On 09/03/2018 15:28, Philip Race wrote: Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/1

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html

Re: RFR: Bug Pending: Build fails to compile jchuff.c

The discussion about SLE seems to have taken over. This was originally about zLinux. If it actually makes sense for zLinux for JDK 11 then I have no objections to the proposed toolchain specific patch ... If it does not make sense for 11 then I think you should look only at 8u and prepare a

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

> Switching the OPTIMIZATION to LOW will solve this at a stroke. And regress performance for all platforms I expect in a case where performance matters .. in order to work around a gcc bug ? I don't think so. Disabling the specific error with the specific tool chain is the only acceptable

Re: [10] Review Request: 8189656 The Windows L should be moved out from the shared folder

OK .. approved. -phil. On 11/28/17, 2:11 PM, Sergey Bylokhov wrote: On 28/11/2017 13:38, Phil Race wrote: I see this opens was moved to platform-specific code ... 115 opens com.sun.java.swing.plaf.windows to 116 jdk.jconsole; So jdk.jconsole definitely accesses this only on Windows ? Its

Re: RFR: JDK-8139653: Freetype bundled on macosx, but not correctly linked

Looks good .. and worked for me when I tested with --enable-freetype-bundling. I used otool to verify the rpath used by fontmanager and used vmmap to verify an executing process was picking up freetype from the JDK's lib. So when we do bundle freetype then it should work as expected. -phil.

Re: Support building OpenJDK on Windows using MSYS2 and MinGW-w64 GCC?

Some issues I see here are that - the code has lots of things like #ifdef _MSC_VER .. fixable perhaps, but .. - the Windows SDK which includes the compiler is needed anyway - no one is likely to maintain this .. - Oracle is unlikely to use this for its own builds. So probably not something

RFR: 8170681 : Remove fontconfig header files from JDK source tree

Bug: https://bugs.openjdk.java.net/browse/JDK-8170681 Webrev: http://cr.openjdk.java.net/~prr/8170681/ This fix removes the copy of fontconfig.h from the JDK sources. The file was originally included in the JDK sources because the build platforms of the day were too old to include it. It will

Re: RFR: JDK-8189119: Devkit for Linux needs to include fontconfig-devel

Sorry I did not reply to this earlier. But yes I've tested it and it works and I am going to send my fix for review soon. -phil. On 10/22/17, 11:59 PM, Magnus Ihse Bursie wrote: On 2017-10-18 13:28, Erik Joelsson wrote: In preparation for removing fontconfig.h from the jdk src, this change

Re: [OpenJDK 2D-Dev] RFR: JDK-8177135: OpenJDK 9 freetype needs msvcr100.dll

+1 -phil. On 3/29/17, 6:16 AM, Magnus Ihse Bursie wrote: On 2017-03-29 15:00, Erik Joelsson wrote: Hello, The build of freetype used internally at Oracle when building OpenJDK builds (for the reference implementation) is very old. It was also built using Visual Studio 2010, which makes it

Re: RFR: JDK-8029942: Update VERSION_MAJOR for JDK 10

+1 -phil. On 1/26/17, 5:56 AM, Erik Joelsson wrote: The default major version for the jdk 10 repos needs to be updated from 9 to 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8029942 Patch: diff -r 07f6f1f4140e common/autoconf/version-numbers --- a/common/autoconf/version-numbers +++

Re: JDK 10 RFR of JDK-8173383: Update JDK build to use -source and -target 10

I think that this has always waited until *at least* that previous JDK is GA. If you think about it there isn't really any such thing as JDK 9 (or at least Java SE 9) until then so it has to be so. Thus ask this again in August. -phil. On 1/25/17, 9:36 PM, joe darcy wrote: And do we also

Re: [OpenJDK 2D-Dev] [9] Review Request: 8140266 Performance loss between jdk8 and jdk9 on Maskfill

lib/Awt2dLibraries.gmk.sdiff.html> Build change looks ok, but I too think a comment explaining why is a good idea. /Erik On 2016-12-23 15:49, Philip Race wrote: Looks OK to me although it is a very cryptic option so maybe include a comment that it is for performance with some versions of gcc ... -phil. On 12

Re: [OpenJDK 2D-Dev] [9] Review Request: 8140266 Performance loss between jdk8 and jdk9 on Maskfill

Looks OK to me although it is a very cryptic option so maybe include a comment that it is for performance with some versions of gcc ... -phil. On 12/23/16, 3:15 AM, Sergey Bylokhov wrote: Hello. Please review the small fix for jdk9. The change add an additional gcc option to the libawt lib to

Re: Freetype enabled in configure.sh, yes still not used

Ditto to what Erik said. If you aren't using freetype with an openjdk build your UI won't (can't!) start. -phil. On 12/15/16, 4:28 AM, Erik Joelsson wrote: Hello, Your attached png files are automatically filtered by the mailing list server so I can't see them. You will need to host them

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

The parts of this which I know about (the client licenses) look fine to me. Some day we should look at whether we still have vestiges of X11 in the Mac code from the BSD port but for now its safer to assume there are .. By this I mean "unix" includes Mac. as a core OS, but not as a desktop

Re: RFR(XXS): 8170954: non-ASCII characters in lcms and harfbuzz break Windows builds on some locales

This is fine by me. These are imported libraries so we just disable the warnings rather than fix them. The only question I had is that US English is the only supported build environment and RE builds will always use that .. everything else is "good luck", Unless something changed to affect

Re: Review Request: JDK-8170424 install build is broken due to the new location of src.zip

+1 -phil. On 11/28/16, 5:03 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170424/webrev.00/ This back out the src.zip change in JDK-8169816 to give time to update the installer properly. Mandy

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

If it is not in the image then there is no point in the file existing. Maybe this could just be a comment at the top of the include file. -phil. On 10/28/16, 12:42 PM, Mandy Chung wrote: On Oct 28, 2016, at 11:32 AM, Pete Brunet wrote: Hi Mandy, That simplifies

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

com <javascript:_e(%7B%7D,'cvml','peter.bru...@oracle.com');>> wrote: On 10/26/16 10:44 PM, Philip Race wrote: > 15http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c; <http://hg.ope

Re: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory

> 15http://hg.openjdk.java.net/jdk9/client/jdk/file/544828ab2a9b/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c;> That URL is definitely not authoritative. I think you need to give a pointer to something more like

Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6

k >> -phil. >> >>> Luckily we have the workaround of setting --disable-warnings-as-errors >>> when this situation occurs. >>> >>> For reference, the compilers Oracle uses are listed in >>> README-builds.md in the top level directory in the forest. &

Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6

case is shift-negative-value a new warning in GCC >> 6? If that's the case it doesn't actually hurt adding it since GCC is >> nice enough to not complain about unknown warning tags. If we do, >> just make sure to specify in a comment that it's specific to GCC >> version 6+. >> &g

Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6

Erik .. please chime in if you disagree with the following The goal here is to have no warnings with the *official* compilers. If you are using something else and get warnings then either fix the *source* or else you need to use --disable-warning-as-errors. Otherwise we'll be suppressing the

  1   2   >