Runtime paths for awt*.so on Solaris

Hello, While going through the makefiles for native libraries in the jdk, I noticed that there are a couple of runtime paths set in the link command lines that don't seem to be used, specifically: libawt.so: -R/usr/dt/lib$(OPENJDK_TARGET_CPU_ISADIR) -R$(OPENWIN_LIB)$(OPENJDK_TARGET_CPU_ISADI

RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris

Hello, (including 2d-dev/awt-dev because I'm changing linker flags on desktop libs.) In preparation for upgrading compilers and build platforms, we would like to get better separation between the two. At least on Linux and Solaris this is certainly possible. Some work for this was already do

Re: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris

th is set. But since toolchain path will be prepended just below, we don't need that precaution, and we can just set it always. Apart from that, it looks great! /Magnus On 2014-03-26 11:32, Erik Joelsson wrote: Hello, (including 2d-dev/awt-dev because I'm changing linker flags

Re: RFR: JDK-8038340: Cleanup and fix sysroot and devkit handling on Linux and Solaris

2014-03-26 12:32, Erik Joelsson wrote: Thanks, here is a new webrev: http://cr.openjdk.java.net/~erikj/8038340/webrev.root.02/ Looks good to me. /Magnus

Re: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg

On 2014-05-22 02:49, Omair Majid wrote: * Andrew Hughes [2014-05-21 20:23]: - Original Message - * Andrew Hughes [2014-05-21 12:22]: I'm not keen on the hardcoding of '-ljpeg' + LIBJPEG_LIBS := -ljpeg There's no pkg-config files for it. Any suggestions on how to get something gen

Re: RFR [9] Modular Source Code

Hello, The basic rule for the new source layout is that for each library, there is a directory where all sources for that library go. This was hard to apply to libawt and friends since as you say, some files go in libawt on windows and libawt_xawt on linux and solaris. For now, I put those in

Re: RFR: 8056216 : Remove "sun" directory layer from libawt and common

Looks good to me. Thanks for fixing this! /Erik On 2014-09-18 22:42, Phil Race wrote: https://bugs.openjdk.java.net/browse/JDK-8056216 http://cr.openjdk.java.net/~prr/8056216/ This is all just removing the sequence "sun/" from various pathnames. Aside from the make file changes there are over

Re: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework

Hello, These changes look ok to me. With these changes, configure will unconditionally fail if trying to use XCode 5. I know we don't officially support using XCode 5 for JDK 8, but aren't people working around it with some patches? How hard would it be to make it at least build? /Erik On

Re: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework

I'm happy with that answer. Thanks! /Erik On 2015-01-12 17:25, David DeHaven wrote: Or rather, the point of this exercise is to eliminate the hacks to get it to build with Xcode 5 (I'm not sure if anyone was truly successful with that). It's far better to just build with Xcode 4.6.3, and with

Re: [9] Review Request: 8056298 Separate java.awt.datatransfer from the desktop module

The makefile change looks good to me. /Erik On 2015-01-13 12:40, Sergey Bylokhov wrote: Hi, Alan. On 12.01.2015 23:42, Alan Bateman wrote: Thanks for doing this. I think it looks okay except for modules.xml where it looks like there may be a few issues. 1. You've updated the definition of ja

Re: [8u60] RFR: 8043340: [macosx] Fix hard-wired paths to JavaVM.framework

Hello, This looks good to me. Thanks for the detailed table! /Erik On 2015-01-14 04:09, David DeHaven wrote: The --with-xcode-path argument is optional, you should also be able to build with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I leave MAS managed Xcode (curr

RFR: JDK-8072107: New dependency introduced by deploy.dll and awt.dll (msvcp100.dll)

Hello, Please review this small fix for a big problem. In JDK-8042707, I tired, but apparently failed, to keep the build functioning with VS2010 just like before. The mistake affecting awt.dll was a misspelled variable in flags.m4. I have built with this change and verified that msvcp100.dll

Re: [9] Review Request: 8039269 images/cursors should not be in ${java.home}/lib

Hello Sergey, The build changes look ok to me. It's unfortunate that you had to explicitly exclude the file from CompileProperties, but I don't see a better solution at this time. Ideally, I would like to see a different file name extension for properties files being compiled than to those be

Re: [9] Review Request: 8039269 images/cursors should not be in ${java.home}/lib

Build changes still look good. /Erik On 2015-02-16 12:57, Sergey Bylokhov wrote: Hello, Here is an updated version of the fix: http://cr.openjdk.java.net/~serb/8039269/webrev.01 - alan.bate...@oracle.com wrote: On 13/02/2015 18:01, Sergey Bylokhov wrote: Hello. Please review the fix fo

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line options to grep so that the command line could be copied to the shell for debugging in the future? Also, how hard would

Re: RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

Thanks, looks good! /Erik On 2015-03-06 17:14, Magnus Ihse Bursie wrote: On 2015-03-04 14:31, Erik Joelsson wrote: Hello, Really nice to finally see this patch getting done! Only one comment: flags.m4: In the grep expression, could you move the extra [] outside of the actual command line

Re: RfR JDK-8055831 Open Source Java Access Bridge

Hello Pete, In general this looks good. However, to better fit with our intended source code file layout, I would prefer if the source was organized by the names of the libraries being built, and this would be a good time to get it done properly. Something like this: jdk.accessibility/window

Re: RfR JDK-8055831 Open Source Java Access Bridge

On 2015-03-24 14:08, Magnus Ihse Bursie wrote: JavaAccessBridge.DEF is pretty empty. I'll see if the build will work without it. WinAccessBridge.DEF seems like it might be needed. What do you think? Is it accessed by the compiler? Unless it is given as input to the compiler or linker co

Re: RfR JDK-8055831 Open Source Java Access Bridge

Actually, I just noticed that we are indeed setting -def: to the linker. Please leave the .def files in the patch. /Erik On 2015-03-24 15:55, Erik Joelsson wrote: On 2015-03-24 14:08, Magnus Ihse Bursie wrote: JavaAccessBridge.DEF is pretty empty. I'll see if the build will work wi

Re: RfR JDK-8055831 Open Source Java Access Bridge

Hello Peter, The new source layout and Lib-jdk.accessibility.gmk look much better. Thanks! Regarding the .def files, I was mistaken and missed that they were referenced in the LDFLAGS, they were indeed used in the build so no reason to remove them. /Erik On 2015-03-24 22:36, Pete Brunet w

Re: RFR: JDK-8074859 Turn on warnings as error

Looks good to me. /Erik On 2015-04-17 14:52, Magnus Ihse Bursie wrote: With JDK-8074096, the number of warnings in the product was reduced to a minimum. This enables the next step, which is turning on the respective compiler flags that turns warnings into errors. In the long run, this is the

Re: RfR JDK-8077296 RE build fails on non-Win builds when attempting to build Win only javadoc

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

Re: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition

The configure change looks good. Can't comment on the code changes. /Erik On 2015-12-16 14:50, Magnus Ihse Bursie wrote: There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. This patch is provided by Timo Kinnunen . I am sponsoring this patch.

Re: RFR: JDK-8145596 Enable debug symbols for all libraries

Looks good to me. Note that this patch will conflict with the quick fix I did in jdk9/hs, so you will need to either wait for my patch, push in a forest that has my patch, or make sure the integrator can handle it correctly. /Erik On 2015-12-17 14:43, Magnus Ihse Bursie wrote: For historical

RFR: JDK-8151770: 9-client windows builds failed from 2016-03-11

Hello, The build is currently broken on Windows in jdk9/client. This patch reverts some and cleans up the makefile changes made in JDK-8145174. I have verified that it builds on Windows and Linux and am just starting a JPRT job to verify the rest. Looking through the review thread for JDK-81

Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows

Build changes look ok. /Erik On 2016-03-15 15:08, Alexander Scherbatiy wrote: On 15/03/16 16:56, Rajeev Chamyal wrote: Hello All, Please review the updated webrev. http://cr.openjdk.java.net/~rchamyal/8145173/webrev.04/ Alexandr : I have build code with VS2013 and I didn't get any errors yo

Re: [9] Review request for JDK-8145173 HiDPI splash screen support on Windows

Build changes are still good. /Erik On 2016-03-23 11:46, Alexander Scherbatiy wrote: On 23/03/16 13:56, Rajeev Chamyal wrote: Hello Alexandr, I have updated the webrev as per review comments. http://cr.openjdk.java.net/~rchamyal/8145173/webrev.06/ The fix looks good to me. Thanks, A

Re: RFR(xs): 8153727: AIX jdk build broken after 8145174

Looks good to me. /Erik On 2016-04-07 12:40, Thomas Stüfe wrote: Hi Volker, On Thu, Apr 7, 2016 at 12:27 PM, Volker Simonis wrote: Hi Thomas, thanks for doing this fix. It looks good. I've also forwarded your request to build-dev as this is a build change. Just one question: do we pass

Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless

Build change looks good. /Erik On 2016-04-20 13:30, Ajit Ghaisas wrote: Adding build-dev. -Original Message- From: Ajit Ghaisas Sent: Wednesday, April 20, 2016 2:28 PM To: awt-dev@openjdk.java.net Subject: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless Hi,

Re: Fix for JDK-8074829 : Resolve disabled warnings for libawt_headless

I believe at least one of the disabled warnings was specific to building on arm or arm64. You will need to verify those platforms as well before removing the gcc disabled warnings. /Erik On 2016-04-20 15:04, Erik Joelsson wrote: Build change looks good. /Erik On 2016-04-20 13:30, Ajit

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

- From: Mandy Chung Sent: Wednesday, June 08, 2016 3:09 PM To: Daniil Titov Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; build-infa-...@openjdk.java.net; awt-dev; Kevin Rushforth Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method That’s right. It r

Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

regards, Daniil -Original Message- From: Mandy Chung Sent: Thursday, June 09, 2016 9:23 AM To: Daniil Titov Cc: Erik Joelsson; David Dehaven; Stuart Marks; build-dev; build-infa-...@openjdk.java.net; awt-dev; Kevin Rushforth Subject: Re: Review Request: 8156960 Deprecate

Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

Hello, I'm happy with the makefile changes, unless anyone else could come up with a solution for any of the remaining warnings. /Erik On 2016-06-23 09:09, Ajit Ghaisas wrote: Hi, Bug : https://bugs.openjdk.java.net/browse/JDK-8074824 (Resolve disabled warnings for libawt_xawt) As

Re: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt

Looks good. /Erik On 2016-10-27 11:02, Ajit Ghaisas wrote: Hi, Fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the 'deprecated' warnings from libawt_xawt. Now, only removing warning suppression from makefile remains. This webrev does

Re: RFR: 8196509: Linux UI applications broken by the build change for JDK-8196218

Looks good. /Erik On 2018-01-31 09:11, Phil Race wrote: Adding build-dev and 2d-dev. -phil. On 01/31/2018 09:10 AM, Phil Race wrote: All UI apps are broken on Linux : Bug : https://bugs.openjdk.java.net/browse/JDK-8196509 Webrev: http://cr.openjdk.java.net/~prr/8196509/ The fix (for now)

Re: RFR: JDK-8198844 Clean up GensrcX11Wrappers

Hello, In xlibtypes.txt comment, should it be sizes-64.txt? Generating both 32 and 64 seems a bit outdated at this point. Surely this is a remnant of bundling 64 and 32 bit together on Solaris in the past? Perhaps someone in 2d can answer this? Would be nice to be able to clean up that part a

Re: RFR: JDK-8198844 Clean up GensrcX11Wrappers

-02 00:02, Erik Joelsson wrote: Hello, In xlibtypes.txt comment, should it be sizes-64.txt? Yes, good catch. Generating both 32 and 64 seems a bit outdated at this point. Surely this is a remnant of bundling 64 and 32 bit together on Solaris in the past? Perhaps someone in 2d can answer

Re: RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good split between common and library specific. /Erik On 2018-03-14 18:12, Magnus Ihse Bursie wrote: I forgot to add the client mailing lists as recipients. Sorry. (Not sure if "sou

Re: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

nd I can't work out how the files in there are used. If they are for a BSD port of OpenJDK where is rest of the support for that ? On 03/15/2018 07:20 AM, Erik Joelsson wrote: Looks good to me. I tried cleaning this up before but failed to find a reasonable split, but this seems like a good

Re: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

ays available on Linux (but most likely if ALSA is not available, libjsound does not provide any functionality, so I suppose libjsoundalsa stuff can be moved to libjsound as well) --alex /Magnus -phil. On 03/15/2018 10:21 AM, Erik Joelsson wrote: Digging a bit, those files came with the

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

I have looked at the build changes and they look good. Will you file followups for each component team to look over their exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)? It sure looks like there is some technical debt laying around here. /Erik On 2018-03-23 06:56, M

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

Build changes still look good to me. /Erik On 2018-03-28 03:31, Magnus Ihse Bursie wrote: On 2018-03-28 01:52, Weijun Wang wrote: On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie wrote: https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth There is only one function t

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hello Severin, I'm ok with this solution for now. Could you please reduce the indentation on line 652. In the build system we like 4 spaces for continuation indent [1] /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2018-04-09 06:39, Severin Gehwolf wrote: Hi,

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Looks good. Thanks! /Erik On 2018-04-10 04:25, Severin Gehwolf wrote: Hi Erik, On Mon, 2018-04-09 at 09:20 -0700, Erik Joelsson wrote: Hello Severin, I'm ok with this solution for now. Thanks for the review! Could you please reduce the indentation on line 652. In the build syst

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

On 2018-04-10 04:30, Severin Gehwolf wrote: On Mon, 2018-04-09 at 15:39 +0200, Severin Gehwolf wrote: Hi, Could somebody please review this build fix for libfontmanager.so. The issue for us is that with some LDFLAGS the build breaks as described in bug JDK-8196218. However, we cannot link to a

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

Hello Volker, The change looks good, but now that we no longer link against libawt_headless, we should also remove the make dependency a few lines down. (Should have been done already for Solaris.) /Erik On 2018-04-13 06:28, Volker Simonis wrote: Hi, can I please have a review for this ti

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

n Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: Hello Volker, The change looks good, but now that we no longer link against libawt_headless, we should also remove the make dependency a few lines down. (Should have been done already for Solaris.) /Erik On 2018-04-13 06:28, Volker Simonis

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

net/~simonis/webrevs/2018/8201524.v1 Regards, Volker On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: Hello Volker, The change looks good, but now that we no longer link against libawt_headless, we should also remove the make dependency a few lines down. (Should have been done already f

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

moved. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 <http://cr.openjdk.java.net/%7Esimonis/webrevs/2018/8201524.v1> > > Regards, > Volker > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson

Re: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Looks good. /Erik On 2018-05-03 04:33, Severin Gehwolf wrote: Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,de

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

Hello, It looks like what you are trying to achieve is to override awt_InputMethod.c with an OS specific version of that file. We have a construct for this in SetupNativeCompilation that should handle it automatically, if you just list the source dirs in priority order. I would suggest levera

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

-Original Message- From: Erik Joelsson [mailto:erik.joels...@oracle.com] Sent: Freitag, 4. Mai 2018 17:45 To: Langer, Christoph ; awt- d...@openjdk.java.net Cc: build-...@openjdk.java.net; ppc-aix-port-...@openjdk.java.net Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT

Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors

Build changes look good. /Erik On 2018-05-16 09:18, Sergey Bylokhov wrote: Looks fine. cc build-dev to review changes in the make file. On 14/05/2018 14:01, Alan Snyder wrote: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 https://bugs.openjdk.java.net/browse/JDK-8194327

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

Build changes look good. /Erik On 2018-05-21 19:39, Sergey Bylokhov wrote: Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 Description:  - Implementation of the AppletViewer was removed  

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Build change looks ok, but the validity of disabling the warning needs review from someone else. /Erik On 2018-06-05 00:47, Baesken, Matthias wrote: Hi Christoph, thank's for the review . Could I have a second one for example from the awt or build-dev reviewers ? Best Regards, Matthias

Re: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically

Hello Magnus, Very nice refactoring! JdkNativeCompilation.gmk line 126-127 looks a bit long. There is an extra space on 126. Also, why not addprefix for adding -I instead of clunky foreach? Not that I care greatly, but I usually prefer that construct. Otherwise looks good. /Erik On 2018-0

Re: RFR (XL): JDK-8204572 SetupJdkLibrary should setup SRC and -I flags automatically

Looks good. /Erik On 2018-06-08 01:50, Magnus Ihse Bursie wrote: On 2018-06-07 23:20, Erik Joelsson wrote: Hello Magnus, Very nice refactoring! Thanks! JdkNativeCompilation.gmk line 126-127 looks a bit long. There is an extra space on 126. Also, why not addprefix for adding -I instead

Re: RFR: 8205494: Convert or remove all AWT applet demos

Looks good. /Erik On 2018-06-21 15:09, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8205494 Webrev : http://cr.openjdk.java.net/~prr/8205494/ This removes all the old 1990's vintage applet demos which can't be run anymore. If any are interesting enough to turn into main pr

Re: 8209520: Build fails when native code coverage is enabled

Hello, On 2018-08-30 02:22, Magnus Ihse Bursie wrote: On 2018-08-24 00:44, Igor Ignatev wrote: Hi Leonid, We have never supported native code coverage builds with warnings enabled as errors. There are bugs in gcc which cause false positive warnings, so it was decided to ignore all warnings

Re: 8209520: Build fails when native code coverage is enabled

On 2018-08-31 01:20, Magnus Ihse Bursie wrote: These are two different arguments for turning off warnings for code coverage: 1) gcc is producing incorrect warnings 2) the warnings might be correct, but we are going to treat such bugs as low priority I understand and accept 1, but I do not

Re: RFR: JDK-8056217 Remove awt_makecube.cpp

Looks good to me. /Erik On 2018-09-05 05:19, Magnus Ihse Bursie wrote: As per the discussion in JDK-8056217, the file awt_makecube.cpp (which is not compiler nor used) should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8056217 Change: $ hg status R src/java.desktop/windows/nat

Re: RFR: JDK-8210944 Stop replacing -MD with -MT in libwindowsaccessbridge

Looks good. /Erik On 2018-09-20 00:05, Magnus Ihse Bursie wrote: Currently, we are filtering out -MD and replacing it with -MT when building libwindowsaccessbridge. This has just been a way to replicate the behavior of old build system, and there's no point in doing so. In fact, it is recom

Re: RFR: JDK-8211029 Have a common set of enabled warnings for all native libraries

Looks good. /Erik On 2018-09-24 01:18, Magnus Ihse Bursie wrote: With JDK-8210988, the foundation is in place for a more systematic way of handling warnings across all native libraries (hotspot and the JDK libraries alike). With this patch, make sure we enable all warnings equally for all

Re: RFR: JDK-8210705 Stop exporting all symbols on macosx

Looks good. /Erik On 2018-09-24 02:00, Magnus Ihse Bursie wrote: For historical reasons, we have exported all symbols on macosx. This was an issue that probably arise with the very first macosx port, and the complication that we then used map files with a format that Xcode did not support.

Re: RFR: JDK-8210705 Stop exporting all symbols on macosx

Looks even better. /Erik On 2018-09-24 10:33, Magnus Ihse Bursie wrote: On 2018-09-24 17:43, Erik Joelsson wrote: Looks good. Thanks. I realized there's one more part where we still export all symbols on macosx, and that's the launchers. Here's an updated webrev that h

Re: RFR(XXS): 8214007: Fix sun.awt.nativedebug on X11 platforms

Looks ok to me. /Erik On 2018-11-16 10:08, Volker Simonis wrote: Hi, can I please have a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214007/ https://bugs.openjdk.java.net/browse/JDK-8214007 AWT supports some kind of native logging which can be enab

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

Looks ok to me if we are fine with making changes to libpng source. I thought this was usually not something we wanted to do with upstream sources. /Erik On 2018-11-28 15:11, Sergey Bylokhov wrote: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8212680

Re: RFR: JDK-8215296 do not disable c99 on Solaris

On 2018-12-13 02:11, Magnus Ihse Bursie wrote: -D_XPG6 ?? To be honest, I'm not completely sure about this. Without this define, the build failed with the following error message: Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications This was tri

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Looks good. I would put in a "the" before "operating system". /Erik On 2019-10-25 03:27, Dmitry Markov wrote: Hello, Could you review the fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232880 webrev: ht

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

No need for new webrev. /Erik On 2019-10-25 06:45, Dmitry Markov wrote: Thank you for the review, Erik! I will update the fix as you suggested before push if you do not mind. Thanks, Dmitry On 25 Oct 2019, at 14:00, Erik Joelsson wrote: Looks good. I would put in a "the" before

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

On 2019-10-25 08:42, Alexey Ivanov wrote: Hi Dmitry, Apple uses macOS to refer to its operating system, so should we also use it instead of former OS X? For HTML version, I would suggest using the following markup Ctrl +F1 for the keyboard shortcut. [1] The HTML is generated from the mark

Re: [15] Review Request: 8235975 Update copyright year to match last edit in jdk repository for 2014/15/16/17/18

Build files look good. /Erik On 2019-12-24 19:22, Sergey Bylokhov wrote: Hello. Here is an updated version:   Bug: https://bugs.openjdk.java.net/browse/JDK-8235975   Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch   Fix: http://cr.openjdk.java.net/~serb/8235975/we

Re: RFR: JDK-8241463 Move build tools to respective modules

Looks good. /Erik On 2020-03-23 12:03, Magnus Ihse Bursie wrote: The build tools (small java tools that are run during the build to generate source code, or data, needed in the JDK) have historically been placed in the "make" directory. This maybe made sense long time ago, but does not do so

Re: RFR(S) : 8240904 : Screen flashes on test failures when running tests from make

Looks ok to me. Would it be possible to break up the long lines a bit to improve readability? Backslash escape for newlines should work in properties files. /Erik On 2020-04-15 22:22, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8240904/webrev.00 35 lines changed: 26 ins; 0 de

Re: RFR(S) : 8240904 : Screen flashes on test failures when running tests from make

r On Apr 16, 2020, at 6:17 AM, Erik Joelsson <mailto:erik.joels...@oracle.com>> wrote: Looks ok to me. Would it be possible to break up the long lines a bit to improve readability? Backslash escape for newlines should work in properties files. /Erik On 2020-04-15 22:22, Igor Ignatye

Re: RFR: 8255798: Remove dead headless code in CompileJavaModules.gmk

On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie wrote: > The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not > exist anymore. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1031

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

On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in > all cases, see

Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v2]

On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. make/modules/java.desktop

Re: RFR: 8259343: [macOS] Update JNI error handling in Cocoa code. [v3]

On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote: >> Proposed updates to JNI error handling. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8259343: [macOS] Update JNI error handling in Cocoa code. Build changes look good.

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

On 2021-01-29 02:56, Magnus Ihse Bursie wrote: On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race wrote: This completes the desktop module JNF removal * remove -framework JavaNativeFoundation from make files * remove #import from all source files. If needed add import of JNIUtilities.h to get

Re: RFR: 8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language codes to current

On Mon, 17 May 2021 16:55:35 GMT, Naoto Sato wrote: > Please review the changes to the subject issue. java.util.Locale class has a > long-standing issue for those obsolete ISO 639 languages where its > normalization ends up in the obsolete codes. This change intends to flip the > normalization

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

-11-29 15:54, Fredrik Öhrström skrev: 2012-11-29 15:36, Erik Joelsson skrev: I just submitted a patch to build-infra for the dual generation on all platforms since it breaks comparisons between old and new build. In general, we can't change behavior in new build without also changing th

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

Here is a new webrev with my sorts incorporated. This has been baking for quite a while in build-infra now and seems to be working. http://cr.openjdk.java.net/~erikj/8004151/webrev.jdk.04/ /Erik On 2012-12-07 11:05, Erik Joelsson wrote: (resending to full recepients list) I just hit another

Re: Review Request: 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable (AWT folks look here!)

-> ones Thanks, David On 19/01/2013 12:05 AM, Erik Joelsson wrote: Here is a new webrev with my sorts incorporated. This has been baking for quite a while in build-infra now and seems to be working. http://cr.openjdk.java.net/~erikj/8004151/webrev.jdk.04/ /Erik On 2012-12-07 11:05, E

Re: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Build part of changes looks ok. I can't comment on the AWT part. /Erik On 2013-09-11 11:24, Leonid Romanov wrote: Hello, Please review a fix for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol. bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 webrev: http

Re: [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Build part looks ok. /Erik On 2013-10-01 07:39, dmitry markov wrote: Hello, Could you review a back-port of 7129133 to JDK 7u, please? The back-port and the main fix integrated into jdk8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 webrev for jdk7u: http://cr.

Re: RFR: 8025673: Disable X11 AWT toolkit

Hello David, From a build point of view, the changes look fine to me. /Erik On 2013-10-21 01:56, David DeHaven wrote: CCing: build-dev, macosx-port-dev, hotspot-dev Request for review of JDK-8025673: https://bugs.openjdk.java.net/browse/JDK-8025673 Proposed changes: http://cr.openjdk.java.ne

Re: RFR: 8016096: [macosx] jawt_md.h shipped with jdk is outdated

Hello David, From a build point of view, the changes look fine to me. /Erik On 2013-10-21 01:53, David DeHaven wrote: CCing: build-dev, macosx-port-dev Request for review of JDK-8016096: https://bugs.openjdk.java.net/browse/JDK-8016096 Proposed changes: http://cr.openjdk.java.net/~ddehaven/8

Re: RFR: 8025673: Disable X11 AWT toolkit

Still looks good to me. /Erik On 2013-10-22 05:34, David DeHaven wrote: Updated webrev for JDK (hotspot change is the same): http://cr.openjdk.java.net/~ddehaven/8025673/jdk.1/ Changes since last version: - Moved to jdk8/build/jdk to save someone a merge headache, moved changes to CompileNati

Re: RFR: Allow using a system installed libpng

At least to me this looks good, but better let Magnus and Andrew have their say too. /Erik On 2014-02-14 18:27, Omair Majid wrote: * Andrew Hughes [2014-02-13 23:59]: As I said in the previous e-mail, the minimum I'd be happy with is if the current patch was updated so settings weren't being

Review: Removing GenerateNativeHeader where not needed

The build infra project added the use of the annotation GenerateNativeHeader. It was addded to java classes without native methods that were listed in the old makefiles as needing headers generated for them. It was noted then that some of those classes didn't actually need native headers. To cl