Re: pre-submit tests for github PRs

[Philip Race]

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-dev@openjdk.java.net
Subject: 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 22/05/2022 23:58, David Holmes wrote:

GHA tests a range of OpenJDK ports, not just the "mainstream
platforms".

The existing linux-86 failures (and others) are due to the Loom
integration which only fully supports a couple of platforms and
which broke all the other ports upon initial integration. Some
folks in the community have been working through things to fix that.

GHA is configured to cross build for most of these
ports/configurations and they should pass. Running them is another
matter of course. GHA does run some tests on linux-x86 and the
x86_32 port does need work before it can run the tests with --enable-

preview.

Aleksey Shipilëv seems to be making good progress on it.

-Alan

Maybe it makes sense to disable the x86 GHA runs before the
underlying issue is fixed? There's too much noise.

There is a slightly better way to do it:
   https://github.com/openjdk/jdk/pull/8843

Re: pre-submit tests for github PRs

[Philip Race]

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 22/05/2022 23:58, David Holmes wrote:


GHA tests a range of OpenJDK ports, not just the "mainstream 
platforms".


The existing linux-86 failures (and others) are due to the Loom
integration which only fully supports a couple of platforms and which
broke all the other ports upon initial integration. Some folks in the
community have been working through things to fix that.


GHA is configured to cross build for most of these
ports/configurations and they should pass. Running them is another
matter of course. GHA does run some tests on linux-x86 and the x86_32
port does need work before it can run the tests with --enable-preview.
Aleksey Shipilëv seems to be making good progress on it.

-Alan


Maybe it makes sense to disable the x86 GHA runs before the underlying
issue is fixed? There's too much noise.


There is a slightly better way to do it:
  https://github.com/openjdk/jdk/pull/8843

Re: pre-submit tests for github PRs

[Philip Race]

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 ?


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 seem to cause concern in some contributors who can't tell 
what they might have broken


Even weirder is that we test Linux x86 there ?? When it isn't a 
mainstream platform. Why ?

Especially since it seem to be the most common failure.


GHA tests a range of OpenJDK ports, not just the "mainstream platforms".

The existing linux-86 failures (and others) are due to the Loom 
integration which only fully supports a couple of platforms and which 
broke all the other ports upon initial integration. Some folks in the 
community have been working through things to fix that.


David


-phil.

pre-submit tests for github PRs

[Philip Race]

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 seem to cause concern in some contributors who can't tell what 
they might have broken


Even weirder is that we test Linux x86 there ?? When it isn't a 
mainstream platform. Why ?

Especially since it seem to be the most common failure.

-phil.

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

[Philip Race]

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,

There is no issue in JBS with this failure.
We had lanai CI jtreg/JCK test run recently on 23rd October and many of those 
runs were on macOS 10.15.7 and macOS  11.6 systems but I don’t see any 
compilation error reported.

Also from below mail I am not able to get whether issue is related to some 
Xcode version or macOS version. Please clarify.

Thanks,
Jay


On 27-Oct-2021, at 3:04 PM, Vitaly Provodin  
wrote:

Sorry did not complete the previous mail


If JDK is built on Catalina with Xcode 12.2, the tests passed well.




On 27 Oct 2021, at 16:32, Vitaly Provodin  wrote:

Hi all,

it was found out that a lot of AWT & Swing tests failed  on macOS-x64 <=10.15  
with the following message


2021-10-25 05:36:42.170 java[6916:107817] Failed to create pipeline state, error Error 
Domain=CompilerError Code=1 "Function frag_col has a deployment target which is 
incompatible with this OS." UserInfo={NSLocalizedDescription=Function frag_col has a 
deployment target which is incompatible with this OS.}


The issue was observed when JDK17, JDK18 was built on BigSur with Xcode12.5
1. -Dsun.java2d.metal=true & macOS-x64 <=10.15 FAILED
2. -Dsun.java2d.metal=true & macOS-x64 >10.15 PASSED
2. -Dsun.java2d.metal=false & macOS-x64 <=10.15 PASSED
2. -Dsun.java2d.metal=false & macOS-x64 > 10.15 PASSED

If JDK is build on Catalina with Xcode12.2

Not sure if this issue is known. Shoiuld it be reported to JBS?

Thanks,
Vitaly

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

[Philip Race]

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.


-phi.

On 9/15/21 12:47 PM, Andrew John Hughes wrote:

On Tue, 16 Mar 2021 16:56:22 GMT, Phil Race  wrote:


 From a build perspective this partially reverts 
https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps
the harfbuzz sources separate and still supports building and running against a 
system harfbuzz which is only of interest or relevance on Linux.

I ended up having to go this way because its is the least unsatisfactory 
solution.
I did not want us to build a devkit to link against a system linux only to find 
we couldn't use it at runtime
because too many systems have to old a version of harfbuzz.

This solves the Manjaro Linux problem and I've manually verified building 
against a system hardbuxz on Ubuntu 20.10

There are couple of incidental fixes in here too
- "libharfbuzz" should not have been in the EXTRA_HEADERS var when building 
against a system version
- harfbuzz/hb-ucdn is gone and should not be listed as a header directory 
needed to build the bundled copy
- I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502

Phil Race has updated the pull request incrementally with one additional commit 
since the last revision:

   8255790: GTKL: Java 16 crashes on initialising GTKL on Manjaro Linux

You mention that "too many systems have to old a version of harfbuzz".
Is the required version defined somewhere? There's no check in configure for 
either a version or a required symbol:
https://github.com/openjdk/jdk/blob/cbffecc61e4a9ac1172926ef4f20d918d73adde9/make/autoconf/lib-bundled.m4#L291

With undefined symbols also being left to runtime (hence why JDK-8272332 
doesn't show up during build), it seems this could lead to sporadic runtime 
failures if OpenJDK is unknowingly built against a harfbuzz that is too old.

-

PR: https://git.openjdk.java.net/jdk/pull/2982

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

[Philip Race]

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 8.3 (from Debian
buster):

* For target 
support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o:
In file included from 
…/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33:
hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = 
hb_zip_iter_t, hb_filter_iter_t, 
hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, 
find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]':
hb-ot-shape-complex-use-machine.rl:249:11:   required from here
hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, 
hb_filter_iter_t, hb_array_t >, 
find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be 
explicitly initialized in the copy constructor [-Werror=extra]
cc1plus: all warnings being treated as errors

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

[Philip Race]

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 out a 
message that they will mis-parse but it is still worth doing.


Need to figure out the same for JCK ..

-phil.

On 2/11/21 3:12 PM, Phil Race wrote:

On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski  wrote:


I guess you will only see this if `Metal API Validation Enabled`

Which actually begs a question of whether we tested with `Metal API Validation 
Enabled` ?

I submitted https://bugs.openjdk.java.net/browse/JDK-8261620 for this bug.
Could be that there are more such issues but since this crash occurs on start 
up I can't say what else there might be.

-

PR: https://git.openjdk.java.net/jdk/pull/2403

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

[Philip Race]

I can confirm that the autoconf warning disabling is currently still 
needed when building with our standard devkit.


It'll have to be removed at the very end.

In file included from 
./open/src/java.security.jgss/macosx/native/libosxkrb5/SCDynamicStoreConfig.m:27:

.

/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFJNI.h:30:
/System/Volumes/Data/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-macosx_x64/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFException.h:49:1: 
error: method has no return type specified; defaults to 'id' 
[-Werror,-Wmissing-method-return-type]

 - init:(JNIEnv *)env throwable:(jthrowable)throwable;
 ^
  (id)
/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers/JNFException.h:50:1: 
error: method has 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 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 going to try to find out if we can remove that now or have to 
wait until all JNF is removed.


FWIW it looks like you added it here : 
http://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037


If we can roll this into an existing PR that might be easier. If it 
needs to wait for all of them, then we'll play it by ear as to whether 
to add it fo the last man standing or file a new bug.


-phil

On 2/1/21 3:33 AM, Magnus Ihse Bursie wrote:

On 2021-01-29 17:41, Phil Race wrote:
But we can just remove it and prove it - but probably a separate PR 
since it is nothing to do with the desktop module and the autoconf 
code needs to be updated once everything else is in.
Fair enough. Do you have a JBS issue tracking the remaining build 
system fixes for the JNF removal? I looked around but could not find 
one.


/Magnus

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

[Philip Race]

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 going to try to find out if we can remove that now or have to wait 
until all JNF is removed.


FWIW it looks like you added it here : 
http://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037


If we can roll this into an existing PR that might be easier. If it 
needs to wait for all of them, then we'll play it by ear as to whether 
to add it fo the last man standing or file a new bug.


-phil

On 2/1/21 3:33 AM, Magnus Ihse Bursie wrote:

On 2021-01-29 17:41, Phil Race wrote:
But we can just remove it and prove it - but probably a separate PR 
since it is nothing to do with the desktop module and the autoconf 
code needs to be updated once everything else is in.
Fair enough. Do you have a JBS issue tracking the remaining build 
system fixes for the JNF removal? I looked around but could not find one.


/Magnus

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

[Philip Race]

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 should do so ASAP.

-phil.

On 12/23/20 5:04 PM, Sergey Bylokhov wrote:

On Wed, 9 Dec 2020 17:40:34 GMT, Victor Dyakov  wrote:


@kevinrushforth @prrace could you please review?

As we discussed yesterday, it is reviewed but not ready to be approved.
We are waiting for a reply from Apple.

@prrace
We are waiting for it for three months already. If it is possible then not sure 
why other applications did not found any possible ways to force one specific 
GPU. What we are wating for?

@mrserb @prrace  what is a back up plan in case we will not have a reply from 
Apple? (as we do not have it for 4! months). Definitely we need a plan B

CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8258918

-

PR: https://git.openjdk.java.net/jdk/pull/1139

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

[Philip Race]

So maybe the actual *usage* of C++11 features slows it down.

I found this :-
https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98

I really did not even think to measure the build time and I don't
think there's any JDK build parallelism in building 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++ compiler you are using (you don't mention platform) is
slower in this mode.

It's GCC 8 on Debian buster, which defaults to C++14.  And it's
possible to write slow-to-compile C++ in all language modes.

Is the Harfbuzz build parallelized?

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

[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++ 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 to import the current 2.7.2 version of harfbuzz -
an OpenType text shaping library

https://bugs.openjdk.java.net/browse/JDK-8247872

This has passed building and headless and headful automated tests on
all platforms.

Is it just me, or does the new Harfbuzz build *significantly* slower?

It adds about 20 seconds to the build, compared to using the system
Harfbuzz, whereas before it was around 5 seconds.

Re: RFR: 8074844 : Resolve disabled warnings for libfontmanager

[Philip Race]

I left that alone on purpose. I have no way of testing it and whereas 
for the 32 bit
linux case I had an idea of what to fix, for xlc all I could find was it 
came in with
https://bugs.openjdk.java.net/browse/JDK-8154087 and I've no idea what 
the problems were.


SAP or IBM can look 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-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 automated tests and sanity checked manual.


A quick run down of how the warnings map to the changes

   DISABLED_WARNINGS_clang := sign-compare,

   DISABLED_WARNINGS_gcc := sign-compare unused-function 
int-to-pointer-cast,


Sign compare in both of the above are the reason for the majority of 
the changes in freetypeScaler.c

and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or 
test that I was flying in the dark here

using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


   DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
C4244: '=': conversion from 'jlong' to 'long', possible loss of data


  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result 
still unsigned


./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
C2220: the following warning is treated as an error
[ 
./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning 
C4996: 'GetVersion': was declared deprecated


GetVersion isn't needed any more since we aren't likely to be running 
on anything older than XP !


-phil.

RFR: 8074844 : Resolve disabled warnings for libfontmanager

[Philip Race]

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 automated tests and sanity checked manual.


A quick run down of how the warnings map to the changes

  DISABLED_WARNINGS_clang := sign-compare,

  DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast,

Sign compare in both of the above are the reason for the majority of the 
changes in freetypeScaler.c
and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or test that I 
was flying in the dark here
using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


  DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error 
C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
C4244: '=': conversion from 'jlong' to 'long', possible loss of data

 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result still 
unsigned

./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
C2220: the following warning is treated as an error
[ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
warning C4996: 'GetVersion': was declared deprecated

GetVersion isn't needed any more since we aren't likely to be running on 
anything older than XP !

-phil.

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

[Philip Race]

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 is disabled for BOTH 
batter and power
and vice versa. In other words there is no way to express that 
battery power should fall back
to integrated and that you only want discrete when running on the 
adapter.


It is possible to do it manually, in the "power adapter" mode the user 
can disable
"automatic graphics switching", and enable it in the "battery" mode. 


What do you mean by "manually" ?

-phil.

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

[Philip Race]

On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:

On 25.08.2020 05:43, Kevin Rushforth wrote:
Does this only apply when the MacBook is running on battery, or will 
this affect performance even when the laptop is plugged in? If the 
latter, I wonder what Apple's rationale is for including a discrete 
graphics card that isn't used most of the time.


Based on the numbers, I wonder if we should make this change ?


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 is disabled for BOTH batter 
and power
and vice versa. In other words there is no way to express that battery 
power should fall back

to integrated and that you only want discrete when running on the adapter.

-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 ?


Yes, performance is affected for sure:

 - SwingMark:
   OGL_Base: 14000
   OGL_Fix: 24000
   Metal: 18000

 - Here is a j2dbench for the common draw operations(new/old/metal):
   http://cr.openjdk.java.net/~serb/8251854/perf/results.txt

  Summary:
  OGL_base:
Number of tests:  24
Overall average:  4.556306150323041E8
Best spread:  0.16% variance
Worst spread: 4.68% variance
(Basis for results comparison)

  OGL_fix:
Number of tests:  24
Overall average:  1.0086929824044746E8
Best spread:  0.04% variance
Worst spread: 7.89% variance
Comparison to basis:
  Best result:  83.41% of basis
  Worst result: 15.73% of basis
  Number of wins:   0
  Number of ties:   0
  Number of losses: 24

  metal:
Number of tests:  24
Overall average:  8.841681616575797E7
Best spread:  0.08% variance
Worst spread: 5.64% variance
Comparison to basis:
  Best result:  248.11% of basis
  Worst result: 19.1% of basis
  Number of wins:   8
  Number of ties:   2
  Number of losses: 14
==

 - Here is a j2dbench for the common draw operations(newOGL vs metal 
only):

http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
Summary:
  OGL_fix:
Number of tests:  24
Overall average:  2.5871177969681844E7
Best spread:  0.04% variance
Worst spread: 7.01% variance
(Basis for results comparison)

  metal:
Number of tests:  24
Overall average:  2.1896134898150157E7
Best spread:  0.04% variance
Worst spread: 1.98% variance
Comparison to basis:
  Best result:  488.31% of basis
  Worst result: 30.77% of basis
  Number of wins:   14
  Number of ties:   0
  Number of losses: 10

And there's then no way to explicitly request the discrete card on 
a 15/16" MBP.


  I have checked that the discrete card is enabled by the macOS:
  - if the full screen window is set
  - if the second monitor is connected
  Do not know any other ways to enable it.



Should we release note this ?


Yes, I think so.
Note that it does not affect the bundled applications only apps 
running via java launcher.

But some(most?) bundled java applications use this flag already.

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

[Philip Race]

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:

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8251854
Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00

The fix looks good from a build perspective.

(But it highlights the fact that we have no consistent placement of 
those plist files; we should probably address that in a separate fix.)


/Magnus



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:

https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html

The current fix updates an embedded plist.info, so the java will not 
require

discrete graphics by default, same as for any other applications.

Note that the new "metal" pipeline also does not required the 
discrete graphics.


The documentation for NSSupportsAutomaticGraphicsSwitching:
https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching 

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

[Philip Race]

One isn't strictly required, but the code in the file isn't used.

The other (hb-coretext.cc) needs to be excluded on other platforms 
besides macOS.


I think the build must actually strip the directory part and just look for
the filename part, else the build should have failed with the wrong 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 is not found by windows dll loading.
So we need to load it explicitly else the Java class that loads 
fontmanager,dll

will fail to initialize.

At the same time, I'd like to fix a very minor inconsequential pair 
of typoes

that exclude from the build files by the wrong directory pathname.

Phil,

Is the exclude still needed, if the build worked fine without it..?

/Magnus


-phil.

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

[Philip Race]

Done : http://cr.openjdk.java.net/~prr/8250894.1/

Although it makes the webrev noisier ..

-phil.

On 7/31/20, 11:48 AM, Erik Joelsson wrote:

Hello Phil,

Looks good. The only thing I would ask is that you indent everything 
in the else clause in Awt2dLibraries.gmk.


Thanks

/Erik

On 2020-07-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 the libharfbuzz that they distribute with the
platform, as is done for libfreetype. But there is no way to do it.

This fix adds a --with-harfbuzz=system configure option.
The valid values are system and bundled.
If specifying system it checks to see if you have the harfbuzz 
development package installed


Like similar options it is only useful on platforms that distribute
libharfbuzz, so there is no need to try to support windows and macOS 
for this option

and it will fast fail at configure time on those platforms.

I have verified this fix on Ubuntu 20.04 LTS.

-phil.

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

[Philip Race]

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 distribute with the
platform, as is done for libfreetype. But there is no way to do it.

This fix adds a --with-harfbuzz=system configure option.
The valid values are system and bundled.
If specifying system it checks to see if you have the harfbuzz 
development package installed


Like similar options it is only useful on platforms that distribute
libharfbuzz, so there is no need to try to support windows and macOS for 
this option

and it will fast fail at configure time on those platforms.

I have verified this fix on Ubuntu 20.04 LTS.

-phil.

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

[Philip Race]

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:

Bug:
   https://bugs.openjdk.java.net/browse/JDK-8250605

I believe this happens because int-to-pointer-cast is now enabled for 
libfontmanager. Below is the
minimal fix, but I wonder if we should reinstate the disabled warning 
for clang (in the same manner)
and msvc (which warning code that one is?). Or we can wait for 
follow-up bug reports there...


Minimal fix:
   https://cr.openjdk.java.net/~shade/8250605/webrev.01/

Testing: Linux {x86_64, x86_32} builds; jdk-submit (running)

Re: RFR: 8249821: Separate libharfbuzz from libfontmanager

[Philip Race]

Hi,

I noticed the indent problems at 434 & 436 myself once I looked at it as 
a webrev,
so I was already updating the fix with those but I've also fixed the 
rest you pointed out.

I've uploaded a new webrev with all of these resolved :-

http://cr.openjdk.java.net/~prr/8249821.1

-phil

On 7/21/20, 3:03 PM, Erik Joelsson wrote:

Hello Phil,

This looks pretty good, only some style nits.

Awt2dLibraries.gmk

428 and 466: These comments aren't relevant anymore now that harfbuzz 
is its own library.


434: Missed indent of 2

436: Too much indent (should be 2)

459-464: Too much indent

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 have tweaked the disabled warnings so we don't have un-needed 
duplication

but it is not a goal of this fix to resolve them.
There's a bug (JDK-8074844) already filed to resolve them for 
fontmanager and

that should be easier to fix now.

-phil.

RFR: 8249821: Separate libharfbuzz from libfontmanager

[Philip Race]

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 duplication
but it is not a goal of this fix to resolve them.
There's a bug (JDK-8074844) already filed to resolve them for 
fontmanager and

that should be easier to fix now.

-phil.

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

[Philip Race]

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 need to specify a certain 
key in your Info.plist, NSMicrophoneUsageDescription. The value of 
this field is displayed to the user the first time the JDK wants to 
record sound. We also discovered that the way the JDK is laid out in 
the Macos specific bundle format, the global Info.plist is not 
actually considered when looking for this particular key, but rather 
the plist info we embed in the java executable.


This patch adds the new key to all the affected plists (JDK global, 
JRE global and the one being embedded in executables). We also noted 
that the bundle ID and version numbers had an effect on how this key 
was resolved, and to get somewhat better behavior, I'm also unifying 
the embedded values for those keys (which were hard coded today) with 
what we already put in the global Info.plist for the JDK. A followup 
bug where we more fully explore what the CFBundleIdentifier, 
CFBundleVersion and CFBundleShortVersionString values should actually 
be is planned for a later release.


With this fix, it's now verified possible to record sound on a Macos 
Catalina machine.


Webrev: http://cr.openjdk.java.net/~erikj/8246094/webrev.01/index.html

Bug: https://bugs.openjdk.java.net/browse/JDK-8246094

/Erik

Re: build problems with man pages on linux

[Philip Race]

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 16.04 Linux

$ which pandoc
/usr/bin/pandoc

$ pandoc --version
pandoc 1.16.0.2
Compiled with texmath 0.8.4.1, highlighting-kate 0.6.1.
Syntax highlighting is supported for the following languages:
abc, actionscript, ada, agda, apache, asn1, asp, awk, bash, 
bibtex, boo, c,
changelog, clojure, cmake, coffee, coldfusion, commonlisp, cpp, 
cs, css,
curry, d, diff, djangotemplate, dockerfile, dot, doxygen, 
doxygenlua, dtd,
eiffel, email, erlang, fasm, fortran, fsharp, gcc, glsl, 
gnuassembler, go,
haskell, haxe, html, idris, ini, isocpp, java, javadoc, 
javascript, json,
jsp, julia, kotlin, latex, lex, lilypond, literatecurry, 
literatehaskell,
llvm, lua, m4, makefile, mandoc, markdown, mathematica, matlab, 
maxima,
mediawiki, metafont, mips, modelines, modula2, modula3, 
monobasic, nasm,
noweb, objectivec, objectivecpp, ocaml, octave, opencl, pascal, 
perl, php,
pike, postscript, prolog, pure, python, r, relaxng, 
relaxngcompact, rest,
rhtml, roff, ruby, rust, scala, scheme, sci, sed, sgml, sql, 
sqlmysql,
sqlpostgresql, tcl, tcsh, texinfo, verilog, vhdl, xml, xorg, 
xslt, xul,

yacc, yaml, zsh
Default user data directory: /home/prrace/.pandoc
Copyright (C) 2006-2015 John MacFarlane
Web:  http://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.

-phil.

On 6/22/20, 4:49 PM, Jonathan Gibbons wrote:

Phil,

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.

In the interim it seems to have stopped working. I get these errors :

LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_keytool.md_post.tmp' 
failed

Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_rmid.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.rmi-launchers' failed
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_java.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.base-launchers' failed

Could it be related to this fix
changeset:   59638:88ba70c9da28
user:ihse
date:Sat Jun 06 02:04:21 2020 +0200
summary: 8246435: Replace Javascript implementation of pandoc 
filters with Java



In case it is relevant configure always reports ...

checking for pandoc... /usr/bin/pandoc
checking if the pandoc smart extension needs to be disabled for 
markdown... pandoc: unrecognized option `--list-extensions'

Try pandoc --help for more information.

.. but it is not clear .. that has never been a problem before.

-phil

Re: build problems with man pages on linux

[Philip Race]

from Ubuntu 16.04 Linux

$ which pandoc
/usr/bin/pandoc

$ pandoc --version
pandoc 1.16.0.2
Compiled with texmath 0.8.4.1, highlighting-kate 0.6.1.
Syntax highlighting is supported for the following languages:
abc, actionscript, ada, agda, apache, asn1, asp, awk, bash, bibtex, 
boo, c,
changelog, clojure, cmake, coffee, coldfusion, commonlisp, cpp, cs, 
css,
curry, d, diff, djangotemplate, dockerfile, dot, doxygen, 
doxygenlua, dtd,
eiffel, email, erlang, fasm, fortran, fsharp, gcc, glsl, 
gnuassembler, go,
haskell, haxe, html, idris, ini, isocpp, java, javadoc, javascript, 
json,
jsp, julia, kotlin, latex, lex, lilypond, literatecurry, 
literatehaskell,

llvm, lua, m4, makefile, mandoc, markdown, mathematica, matlab, maxima,
mediawiki, metafont, mips, modelines, modula2, modula3, monobasic, 
nasm,
noweb, objectivec, objectivecpp, ocaml, octave, opencl, pascal, 
perl, php,
pike, postscript, prolog, pure, python, r, relaxng, relaxngcompact, 
rest,

rhtml, roff, ruby, rust, scala, scheme, sci, sed, sgml, sql, sqlmysql,
sqlpostgresql, tcl, tcsh, texinfo, verilog, vhdl, xml, xorg, xslt, xul,
yacc, yaml, zsh
Default user data directory: /home/prrace/.pandoc
Copyright (C) 2006-2015 John MacFarlane
Web:  http://pandoc.org
This is free software; see the source for copying conditions.
There is no warranty, not even for merchantability or fitness
for a particular purpose.

-phil.

On 6/22/20, 4:49 PM, Jonathan Gibbons wrote:

Phil,

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.
In the interim it seems to have stopped working. I get these errors :

LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_keytool.md_post.tmp' 
failed

Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_rmid.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.rmi-launchers' failed
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_java.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.base-launchers' failed

Could it be related to this fix
changeset:   59638:88ba70c9da28
user:ihse
date:Sat Jun 06 02:04:21 2020 +0200
summary: 8246435: Replace Javascript implementation of pandoc 
filters with Java



In case it is relevant configure always reports ...

checking for pandoc... /usr/bin/pandoc
checking if the pandoc smart extension needs to be disabled for 
markdown... pandoc: unrecognized option `--list-extensions'

Try pandoc --help for more information.

.. but it is not clear .. that has never been a problem before.

-phil

build problems with man pages on linux

[Philip Race]

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 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_keytool.md_post.tmp' 
failed

Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_rmid.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.rmi-launchers' failed
LauncherCommon.gmk:223: recipe for target 
'/build/linux-x86_64-server-release/support/markdown/BUILD_MAN_PAGES_java.md_post.tmp' 
failed

make/Main.gmk:228: recipe for target 'java.base-launchers' failed

Could it be related to this fix
changeset:   59638:88ba70c9da28
user:ihse
date:Sat Jun 06 02:04:21 2020 +0200
summary: 8246435: Replace Javascript implementation of pandoc 
filters with Java



In case it is relevant configure always reports ...

checking for pandoc... /usr/bin/pandoc
checking if the pandoc smart extension needs to be disabled for 
markdown... pandoc: unrecognized option `--list-extensions'

Try pandoc --help for more information.

.. but it is not clear .. that has never been a problem before.

-phil

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

[Philip Race]

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:
BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says

For Solaris: Add the -std=c++14 compiler option. .

So I am sure there is still some room to update the JEP :-)

Yeah, I have some updates to make.  I also need to do a bit of work on the 
feature lists.

I think the JEP updates are done now.

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

[Philip Race]

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 we will upgrade the harfbuzz 3rd party 
library used by 2D
and it will bring along the need to use C++11 features and I had no plan 
to propose a JEP for that.

So I don't want to be asked why we didn't do one when hotspot did !
So this really ought to be a JDK JEP whilst of course explaining that 
hotspot is expected

to be the primary adopter.

BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
> For Solaris: Add the |-std=c++14| compiler option. .

So I am sure there is still some room to update the JEP :-)

-phil.

On 6/5/20, 12:52 AM, Kim Barrett wrote:

[Changes are only to the build system, but since the changes have jdk-wide
effect I’ve cc’d what I think are the relevant dev lists.]

This change is part of JEP 347; the intent is to target JDK 16.

Please review this change to the building of C++ code in the JDK to
enable the use of C++14 language features.  This change does not make
any code changes to use new features provided by C++11 or C++14.

This requires trimming the supported compiler versions, moving the
minimum supported versions forward (significantly, in some cases).
The new minimums are based on compiler documentation rather than
testing.  It may be that more recent versions are actually required.

This change needs to be tested on platforms not supported by Oracle.
The JEP test plan includes additional Oracle testing beyond what I’ve done.

CR:
https://bugs.openjdk.java.net/browse/JDK-8246032

Webrev:
https://cr.openjdk.java.net/~kbarrett/8246032/open.02/

Testing:
mach5 tier1-5 on Oracle supported platforms.

Performance testing showed no significant changes in either direction.

Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le

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

[Philip Race]

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 about 17 months from now, it'll be history.

-phil

On 5/15/20, 9:12 AM, Magnus Ihse Bursie wrote:

On 2020-05-15 17:33, Erik Joelsson wrote:

Hello Andre,

As far as I'm aware, support for 32 bit on Macosx has not been 
supported by anyone for a very long time. I would assume it far from 
trivial to get it to work.
In fact, I wonder if there *ever* have been 32-bit macOS support in 
OpenJDK. I believe we only inherited a 64-bit port from Apple.


/Magnus


/Erik

On 2020-05-14 17:17, Andre Kovacs wrote:

Dear members,

For compatibility reasons with older 32bit i386 architecture dylibs via
JNI, I'm trying to build a 32bit version of jdk12u on Mac OS X.

I'm using the following configure command:
"bash configure
--with-boot-jdk=/Library/Java/JavaVirtualMachines/openjdk12/Contents/Home 


--with-target-bits=32"

But I'm getting the following build errors when I try to build
macosx-x86-client-release and macosx-x86-server-release:
"ERROR: Build failed for target 'default (exploded-image)' in 
configuration

'macosx-x86-client-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-client_libjvm_objs_abstractInterpreter.o:
In file included from
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/abstractInterpreter.cpp:33: 


In file included from
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/share/interpreter/interp_masm.hpp:31: 

/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/interp_masm_x86.hpp:171:5: 


error: call to member function 'movptr' is ambiguous
 movptr(Address(rbp, frame::interpreter_frame_last_sp_offset *
wordSize), (int32_t)NULL_WORD);
 ^~
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1554:8: 


note: candidate function
   void movptr(Address dst, intptr_t src);
^
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1556:8: 


note: candidate function
   void movptr(Address dst, Register src);
^
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/src/hotspot/cpu/x86/macroAssembler_x86.hpp:1540:8: 

note: candidate function not viable: no known conversion from 
'Address' to

'ArrayAddress' for 1st argument
... (rest of output omitted)

* All command lines available in
/Users/andre/Documents/OpenJDK/jdk12u-390566f1850a/build/macosx-x86-client-release/make-support/failure-logs. 


=== End of repeated output ==="

Thank you in advance for your time.

Regards,
Andre

Re: macOS hardened runtime issue - missing entitlements

[Philip Race]

Yes, we've read that page too :-)
The microphone is the only one that I am sure OpenJDK Java APIs need.
I don't think access to the calendar or address book is needed since
I expect it implies using macOS APIs we do not expose.

-phil.

On 5/13/20, 9:15 AM, Adrián Ruiz Arroyo wrote:
I mentioned the camera as an example: there might be other 
resources with restricted access and accessible through Java APIs that 
are being blocked, but I’ve only confirmed the microphone as I use it 
everyday for testing.


There is a list of resources here: 
https://developer.apple.com/documentation/security/hardened_runtime, 
at "Topics/Resource Access”. Don’t know which of these resources have 
a corresponding Java API that may be failing to work under the 
hardened runtime. I’ve read some of these resources are just really 
directories (i.e. Calendars, Address Book) that contain sensible 
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 5/13/20, 1:18 AM, Adrián Ruiz Arroyo wrote:

Hello,

I filled an issue a few days ago 
(https://github.com/AdoptOpenJDK/openjdk-build/issues/1720<https://github.com/AdoptOpenJDK/openjdk-build/issues/1720> 
<https://github.com/AdoptOpenJDK/openjdk-build/issues/1720%3Chttps://github.com/AdoptOpenJDK/openjdk-build/issues/1720%3E>) 
about restrictions on access to some resources when running a Java 
.jar (tested microphone, but suspect there are more resources 
involved, like camera):


Since upgrading to the hardened runtime version of the JDK, I can 
no longer access microphone input using the standard Java Sound 
API, only silence is captured when running my .jar file using the 
command line. While checking Console.app, I found that TCC is 
blocking microphone access in the background because of a missing 
entitlement:


Prompting policy for hardened runtime; service: 
kTCCServiceMicrophone requires entitlement 
com.apple.security.device.audio-input but it is missing for 
ACC:{ID: net.java.openjdk.cmd, PID[2161], auid: 501, euid: 501, 
binary path: 
'/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java'}, 
REQ:{ID: com.apple.tccd, PID[154], auid: 0, euid: 0, binary path: 
'/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd'}

This causes microphone access to be blocked without any user action:

Policy disallows prompt for ACC:{ID: net.java.openjdk.cmd, 
PID[2161], auid: 501, euid: 501, binary path: 
'/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java'}, 
REQ:{ID: com.apple.tccd, PID[154], auid: 0, euid: 0, binary path: 
'/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd'}; 
access to kTCCServiceMicrophone denied
This does not happen with file access: a dialog to provide access 
to "Documents" and "Downloads" appears when trying to access a file 
there.
The missing entitlements means the hardened runtime will block any 
access to some resources without showing a dialog for the user to 
“Accept” or “Deny” it. Moreover, macOS doesn’t allow adding 
permissions manually, so I found no way to bypass this. The only 
solution that I can think of right now is to add the required 
entitlements on JRE’s compilation so that access to this resources 
can be allowed or denied. Meanwhile, the workaround I found is to 
return to a version of JRE not using the hardened runtime, as this 
versions do show the dialog.


Thank you for your time!

Re: macOS hardened runtime issue - missing entitlements

[Philip Race]

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 
(https://github.com/AdoptOpenJDK/openjdk-build/issues/1720)
 about restrictions on access to some resources when running a Java .jar (tested 
microphone, but suspect there are more resources involved, like camera):


Since upgrading to the hardened runtime version of the JDK, I can no longer 
access microphone input using the standard Java Sound API, only silence is 
captured when running my .jar file using the command line. While checking 
Console.app, I found that TCC is blocking microphone access in the background 
because of a missing entitlement:

Prompting policy for hardened runtime; service: kTCCServiceMicrophone requires 
entitlement com.apple.security.device.audio-input but it is missing for 
ACC:{ID: net.java.openjdk.cmd, PID[2161], auid: 501, euid: 501, binary path: 
'/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java'},
 REQ:{ID: com.apple.tccd, PID[154], auid: 0, euid: 0, binary path: 
'/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd'}
This causes microphone access to be blocked without any user action:

Policy disallows prompt for ACC:{ID: net.java.openjdk.cmd, PID[2161], auid: 
501, euid: 501, binary path: 
'/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java'},
 REQ:{ID: com.apple.tccd, PID[154], auid: 0, euid: 0, binary path: 
'/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd'}; 
access to kTCCServiceMicrophone denied
This does not happen with file access: a dialog to provide access to "Documents" and 
"Downloads" appears when trying to access a file there.

The missing entitlements means the hardened runtime will block any access to 
some resources without showing a dialog for the user to “Accept” or “Deny” it. 
Moreover, macOS doesn’t allow adding permissions manually, so I found no way to 
bypass this. The only solution that I can think of right now is to add the 
required entitlements on JRE’s compilation so that access to this resources can 
be allowed or denied. Meanwhile, the workaround I found is to return to a 
version of JRE not using the hardened runtime, as this versions do show the 
dialog.

Thank you for your time!

RFR: 8242325: Remove VIS version of medialib

[Philip Race]

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 into it.

Since the library isn't loaded by default, things should still work as 
before.
Build still works - on SPARC and other platforms, and all headless 
client tests pass on Solaris.


-phil.

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

[Philip Race]

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 mailing list(s) are for this change.
It definitely isn't a core-libs change. I think build-dev may be better.


Previous changes to these configs were discussed here, so I have send 
it here as well.




I am also unclear when this failure handler is invoked and how all 
this machinery works.


It is only useful for headful tests and so I'd only want it enabled 
in such a case.
And we disable the failure handlers in the headful test jobs anyway 
because they seem
focused on taking pointless core dumps ...> So we need something that 
can be used with headful tests only and doesn't involve

re-enabling the other handlers.
It could be useful for other tests as well and may be able to identify 
problems such as:

 - Suggestions "to open under debugger" from the native asserts
 - Various error dialogs from the OS
And it does not spend much resources compared to current handlers.



Also why exclude Windows ? No easy way to get the screenshot ?


There is no command-line program that can take a screenshot on windows 
by default




-phil.

On 12/11/19 1:00 AM, Sergey Bylokhov wrote:

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233827
Fix: http://cr.openjdk.java.net/~serb/8233827/webrev.01

This change adds the "screen capture on the test failure" feature on 
macOS and Linux.
 - On Linux, it is implemented by the "gnome-screenshot" command(in 
case of
   multiscreen+xineramathe whole big screen will be saved to the 
"screen.png" file).
 - On macOS it is implemented by the "screencapture" command, note 
that I have
   used 1 file per screen, if the number of screens less than 5, 
other files will be ignored.

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

[Philip Race]

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 seems to be a bug in the new jtreg version, so need to hold off 
on this.


/Erik

On 2019-08-22 14:22, Erik Joelsson wrote:
For some notoriously unstable client tests, we need the ability to 
automatically retry them a few times. This can be achieved with a 
simple loop around running jtreg from RunTest.gmk and by using the 
-status:error,fail parameter on the retry runs. This parameter was 
fixed to actually work in this way in jtreg 4.2 b15.


Bug: https://bugs.openjdk.java.net/browse/JDK-8230067

Webrev: http://cr.openjdk.java.net/~erikj/8230067/webrev.01/index.html

/Erik

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

[Philip Race]

> 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,  this incremental webrev contains the JNLPConverter code, which 
it should not.


I believe otherwise it is an accurate incremental webrev of the 
jpackage changes since EA-5.


/Andy

On 11/26/2019 4:53 PM, Phil Race wrote:

Andy,

I am puzzled by what I see here
> The webrev at [3] shows the changes since EA-06 (Build 
13-jpackage+1-49 ) up to the current point.


> [3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/

This includes the JNLPConverter which isn't what I expected to see and
(correctly) isn't in the cumulative webrev 

Since [3] seemed like the most obvious thing to do a review of the 
recent
changes I'd like to be sure it has the correct content and I am not 
sure it does ...


-phil.

On 11/26/19 1:36 PM, Kevin Rushforth wrote:

This all looks good.

+1

-- Kevin


On 11/26/2019 12:56 PM, Erik Joelsson wrote:

(adding build-dev)

Build changes look good.

/Erik

On 2019-11-20 09:37, Andy Herrick wrote:
I posted new composite webrev [7], and git patch [8] after pushing 
fix for JDK-8234402 [6].


[7] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/

[8] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-11.git.patch

/Andy

On 11/19/2019 3:13 PM, Kevin Rushforth wrote:
I took the "git diff" patch [5] that you uploaded yesterday, 
applied it, and verified that it is the same as what is in the 
JDK-8200758-branch branch of the sandbox. It builds and runs fine 
for me.


I ran jcheck and it found the following three files with 
whitespace errors that will need to be fixed before you push:


src/jdk.incubator.jpackage/linux/classes/jdk/incubator/jpackage/internal/PackageProperty.java:49: 
Trailing whitespace
src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/ToolProviderFactory.java:35: 
Trailing whitespace
test/jdk/tools/jpackage/share/AddLauncherBase.java:137: Trailing 
whitespace


The second of these will go away with the fix for JDK-8234402 
[6], so you don't need to do anything there. Once the fix for 
JDK-8234402 is pushed to sandbox, I presume you will update the 
webrev, right?


Pending the fix for JDK-8234402 and the needed white-space fixes, 
this is a +1 from me (although I am not a jdk Project Reviewer, 
so you will need at least one review from someone who is).


-- Kevin

[5] http://cr.openjdk.java.net/~herrick/8212780/JDK-EA-10.git.patch
[6] https://bugs.openjdk.java.net/browse/JDK-8234402


On 11/13/2019 4:23 PM, Andy Herrick wrote:
Please review  changes for [1] which is the implementation bug 
for JEP-343.


The webrev at [2] is the total cumulative webrev of changes for 
the jpackage tool, currently in the JDK-8200758-branch branch of 
the open sandbox repository.


The webrev at [3] shows the changes since EA-06 (Build 
13-jpackage+1-49 ) up to the current point.


The latest EA (Build 14-jpackage+1-49 ) is posted at [4].

Please send feedback to core-libs-...@openjdk.java.net


[1] https://bugs.openjdk.java.net/browse/JDK-8212780

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-10/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.06-10/

[4] http://jdk.java.net/jpackage/

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

[Philip Race]

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 Suenaga wrote:

Thanks Erik!

I uploaded new webrev, and it passed all tests on submit repo 
(mach5-one-ysuenaga-JDK-8220074-1-20191113-0112-6660052).


   http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.01/

Yasumasa


On 2019/11/13 3:04, Erik Joelsson wrote:

Hello,

There is no need to do compiler version checks like this. We just 
add all the necessary warning disabling for all versions. GCC will 
not fail or warn for invalid -W-no... flags and we use this feature 
for this very reason. We don't think it's feasible to track warnings 
per compiler versions..


/Erik

On 2019-11-12 06:48, Yasumasa Suenaga wrote:

Hi all,

Please review this change:

  JBS: https://bugs.openjdk.java.net/browse/JDK-8220074
  webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8220074/webrev.00/

I saw some -Wstringop-truncation warnings in LCMS when I build 
OpenJDK with GCC 9.2.1 on Fedora 31.
They are LCMS problems, thus we should avoid them to disable these 
warnings.


This change has been tested on submit repo 
(mach5-one-ysuenaga-JDK-8220074-20191112-1334-6642576).



Thanks,

Yasumasa

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

[Philip Race]

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 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. I 
see the line below which you probably emulated also uses them, but 
they really should just be normal braces.


/Erik

On 2019-05-24 14:03, Phil Race wrote:

bug: https://bugs.openjdk.java.net/browse/JDK-8224778
webrev : http://cr.openjdk.java.net/~prr/8224778/

With this fix the test can find the demo jar in its traditional 
place as before,

and now also where it is placed by JIB to be invoked from RunTests.gmk

-phil

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

[Philip Race]

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. I see 
the line below which you probably emulated also uses them, but they 
really should just be normal braces.


/Erik

On 2019-05-24 14:03, Phil Race wrote:

bug: https://bugs.openjdk.java.net/browse/JDK-8224778
webrev : http://cr.openjdk.java.net/~prr/8224778/

With this fix the test can find the demo jar in its traditional place 
as before,

and now also where it is placed by JIB to be invoked from RunTests.gmk

-phil

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

[Philip Race]

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  changes for [1] which is the implementation bug for 
JEP-343.


The webrev at [2] is the total cumulative webrev of changes for the 
jpackage tool, currently in the JDK-8200758-branch branch of the open 
sandbox repository.


The webrev at [3] shows the changes from EA-05 to EA-06.
sorry - the links are reversed from what is stated above. [2] is the 
incremental webrev since EA 05, [3] is the cumulativewebrev

/Andy


The latest EA-6 (build 49) is posted at [4].

Please send feedback to core-libs-...@openjdk.java.net


[1] https://bugs.openjdk.java.net/browse/JDK-8200758

[2] http://cr.openjdk.java.net/~herrick/8212780/webrev.05-06/

[3] http://cr.openjdk.java.net/~herrick/8212780/webrev.ea6/

[4] http://jdk.java.net/jpackage/


/Andy

RFR: 8222362: Upgrade to Freetype 2.10.0

[Philip Race]

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 regression tests run
Verified manually with Font2DTest & SwingSet2
The license is the same - just a version update is needed.

A couple of new build warnings needed to be disabled and
there was a build problem on Windows, so one change
in AwtLibraries.gmk is to deal with this error :


 >  
t:\workspace\build\windows-x64\support\native\java.desktop\libfreetype\freetype.lib
 : fatal error LNK1136: invalid or corrupt file
 >  Awt2dLibraries.gmk:602: recipe for target 
'/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll'
 failed
 >  make[3]: *** 
[/cygdrive/t/workspace/build/windows-x64/support/modules_libs/java.desktop/fontmanager.dll]
 Error 1

The problem is that freetype.lib is empty (0 bytes)
I inferred this was because for some reason there was no longer anything being 
exported.

Hunting sound the source diff I found this :

src/java.desktop/share/native/libfreetype/include/freetype/config/ftconfig.h.udiff.html

-#if defined( _WIN32 )&&  ( defined( _DLL ) || defined( DLL_EXPORT ) )
+#if defined( _WIN32 )&&  defined( DLL_EXPORT )
#define FT_EXPORT( x )  __declspec( dllexport )  x


Since we were are passing /MD to VC++ cl.exe will define _DLL for us, but
now freetype no longer looks for it.
 
This can be tracked back to a change in freetype build so that it relies on

an explicit define of DLL_EXPORT set up in the vcxproj file.
The comment as to why is below although I don't really understand if the 
reference
to static builds is meant to be a justification. My best guess is that they
are trying to say that even if _DLL is defined sometimes you maybe don't want/ 
need to
exports ymbols so we are now going to make you say so explicitly using 
DLL_EXPORT.

>We no longer use predefined _DLL, which can be defined for static 
builds too with /MD.

>We use DLL_EXPORT and DLL_IMPORT instead, following libtool convention.

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/builds/windows/vc2010/freetype.vcxproj?id=4b97ab98a8e90ae5403058b73c345974247bf01e

https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/include/freetype/config/ftconfig.h?id=4b97ab98a8e90ae5403058b73c345974247bf01e


So my fix is to add the same manual define to our build as used by freetype.

-phil.

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

[Philip Race]

> 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: https://bugs.openjdk.java.net/browse/JDK-8217707
webrev: http://cr.openjdk.java.net/~aivanov/8217707/webrev.0/

Description:
Splash screen functionality is broken in 32 bit Windows. It's because 
the functions in splashscreen.dll are exported with decorated names 
now, yet they're looked up by the undecorated names.


The easiest way to reproduce the problem is to run SwingSet2:
java -jar SwingSet2.jar


Fix:
The fix removes JNICALL (__stdcall) declarations from splash screen 
functions. Thus the functions are exported undecorated.


I've run SplashScreen jtreg tests, all tests pass.

This is a follow-up fix to
https://bugs.openjdk.java.net/browse/JDK-8201226
https://bugs.openjdk.java.net/browse/JDK-8202476
which re-enabled 32 bit Windows post removal of mapfiles / compiler 
options.



Thank you in advance.

Regards,
Alexey

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

[Philip Race]

Oh yes we should :-). Good catch.
The license isn't changed so its a small matter of changing what version 
we list in the file.

http://cr.openjdk.java.net/~prr/8210782.1

-phil.

On 2/28/19, 4:58 PM, Sergey Bylokhov wrote:

Hi, Phil.
Should we update the "harfbuzz.md" file as well?

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 (external) C++ library used by OpenJDK for 
OpenType text layout.


In this large upgrade
- Many files were renamed following the pattern of 
"hb-foo-private.cc" becoming "hb-foo.cc"

- Many new files were added
- A couple of files were deleted.

There are two additional changes on top of this
I needed to import a published but un-released fix to enable building 
with Oracle Studio 12.6 on Solaris
See 
https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978
I needed to reapply a fix made in JDK as JDK-8218965 that mirrors 
upstream to support building with the latest AIX compilers
See 
https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d
This doesn't show up as a "diff" in the JDK webrev which demonstrates 
that it is correctly re-applied as previously.


There are two JDK files changed :
(1)
- The makefile has been updated to disable several new warnings.
- To prevent harfbuzz from enabling warnings that were disabled - and 
avoid unknown pragma warnings we now define


-DHB_NO_PRAGMA_GCC_DIAGNOSTIC


See hb.hh for what harfbuzz is doing there, but without this -D 
option we cannot
disable warnings from the build since they are enabled in the code 
itself.


(2)
- A couple of harfbuzz APIs were deprecated so I needed to make code 
changes in hb-jdk-font.cc to use

the new API.

I have tested that this builds cleanly with all the current devkits 
(via the build servers) and that it also builds

with the in progress work to provide a gcc 8.2 devkit for Linux
I have also run all the related automated tests and performed some 
manual testing too.


-phil.

RFR: 8210782: Upgrade HarfBuzz to the latest 2.3.1

[Philip Race]

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 
OpenType text layout.


In this large upgrade
- Many files were renamed following the pattern of "hb-foo-private.cc"  
becoming "hb-foo.cc"

- Many new files were added
- A couple of files were deleted.

There are two additional changes on top of this
I needed to import a published but un-released fix to enable building 
with Oracle Studio 12.6 on Solaris
See 
https://github.com/harfbuzz/harfbuzz/commit/1e06282105a2d579aab32094cc7abc10ed231978
I needed to reapply a fix made in JDK as JDK-8218965 that mirrors 
upstream to support building with the latest AIX compilers
See 
https://github.com/harfbuzz/harfbuzz/commit/5c2bb1de8de31fecf0dae2ef905b896e42d39f1d
This doesn't show up as a "diff" in the JDK webrev which demonstrates 
that it is correctly re-applied as previously.


There are two JDK files changed :
(1)
- The makefile has been updated to disable several new warnings.
- To prevent harfbuzz from enabling warnings that were disabled - and 
avoid unknown pragma warnings we now define


-DHB_NO_PRAGMA_GCC_DIAGNOSTIC


See hb.hh for what harfbuzz is doing there, but without this -D option 
we cannot

disable warnings from the build since they are enabled in the code itself.

(2)
- A couple of harfbuzz APIs were deprecated so I needed to make code 
changes in hb-jdk-font.cc to use

the new API.

I have tested that this builds cleanly with all the current devkits (via 
the build servers) and that it also builds

with the in progress work to provide a gcc 8.2 devkit for Linux
I have also run all the related automated tests and performed some 
manual testing too.


-phil.

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

[Philip Race]

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 engineers
2. hotspot developers
3. java library developers

Category 1 doesn't care about edit-compile-debug cycle - they just
want to build a reliable high-performance jdk without pitfalls.  This
is the VAST MAJORITY of users, for whom we should design defaults in
configure.
Category 2 wants debug info and maybe incremental linking.  They might
cheat and rebuild only libjvm.so and drop that one file into a
previously built jdk as part of their development cycle.
Category 3 doesn't care about native debug symbols at all

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

[Philip Race]

+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, I don't see anything important ...

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

[Philip Race]

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 ?


I don't see anything that is important enabled by that option.


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"
which is also controlled by PNG_SET_OPTION_SUPPORTED, it also may 
affect some other options

which will be added later.


As I said, I don't see anything important ...


So the current fix adds the new property, as if it was added by the 
pnglib maintainer,
and reuses this property for our purpose(comment default define in 
"pnglibconfig.h"

and enable it in some cases in makefile).

BTW the small clarification for other questions in the thread:
  the changes in upstream library is in "png.h" file only, the 
"pnglibconf.h" is our config on how

to build the lib.



Right, that is why I suggested confining the change to that file.

-phil.

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

[Philip Race]

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 Joelsson wrote:
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
Webrev: http://cr.openjdk.java.net/~serb/8212680/webrev.00

On Solaris we faced the bug which was fixed in macOS already:
  https://bugs.openjdk.java.net/browse/JDK-8196803

The problem is that there is a call to "inflateValidate" function in 
pngrutil.c[1], guarded by a preprocessor check of ZLIB_VERNUM being 
high enough and by the "PNG_IGNORE_ADLER32". If we compile this call 
in and link to the newer version of zlib, we will get link errors if 
the code is executed on an older Mac/Solaris/ with an older version 
of zlib.


The bug can be reproduced on "old" Solaris 11.3, which was not 
updated for a while(since 2015).


We can fix it by requiring some "OS Patches and Package Updates", but 
since it was
reproduced on macOS, and potentially can occur on other platforms, I 
have decided
to fix it in the code. The new property is introduced to the libpng 
"PNG_ADLER32_SUPPORTED",
which control the usage of "PNG_IGNORE_ADLER32" and as a result 
control the call to "inflateValidate"[1].
This new property is set in the makefile when we build "bundled" 
versions of libpng+zlib only.


This was reported upstream, and the future version of libpng may have 
some similar solution.


[1] 
http://hg.openjdk.java.net/jdk/jdk/file/396dfb0e8ba5/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c#l457

Re: [12] Gcc 8.1 HarfBuzz library compilation issues

[Philip Race]

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 sources we get from upstream.
It is a maintenance nightmare.

-phil

On 11/20/18, 6:48 AM, Simon Tooke wrote:

On 2018-11-20 5:31 a.m., Magnus Ihse Bursie wrote:

On 2018-11-19 22:22, Simon Tooke wrote:


Hello,

I've been looking at compiling the JDK with GCC 8.1, and trying to fix
issues upstream as I find them.

Nice! If you find issues in the JDK source code per se, please let us
know. :) Sooner or later, we'll have to support gcc 8 properly anyway,
might just as well try to clear the path already.

I noticed yesterday that
https://bugs.openjdk.java.net/browse/JDK-8213153 from Dmitry Chuyko is
also working on GCC 8.  I am not sure how far down the rabbit hole he
is, but I (with the kind assistance of Severin Gehwolf since I'm not a
committer) am submitting a series of patches to move towards that. I
have a JDK tree compiling with 8.1, but it still has to disable warnings
in more places than I feel comfortable with.


/Magnus

For example the version of HarfBuzz shipped in the JDK has some issues
with template specialization and with clearing a struct via memset()
(thus bypassing C++ member access restrictions).

I've had changes to address these issues accepted upstream [1], and I
was wondering if it is appropriate for me to file an issue to backport
those fixes (I have a patch ready) or do you prefer to wait until
HarfBuzz is upgraded to the latest version during the natural course of
JDK development.

(Be aware that the JDK is on a 1.7 version, while these fixes are in a
2.X version).

Thanks,
-Simon

[1] https://github.com/harfbuzz/harfbuzz/pull/1334

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

[Philip Race]

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 > DTrace_PrintFunction 
/scratch/opt/mach5/mesos/work_dir/866342db-c7dc-4a92-a1ef-94525de45f66/workspace/build/solaris-sparcv9-debug/support/native/java.desktop/libawt_xawt/XToolkit.o
jib > DAssert_Impl 
/scratch/opt/mach5/mesos/work_dir/866342db-c7dc-4a92-a1ef-94525de45f66/workspace/build/solaris-sparcv9-debug/support/native/java.desktop/libawt_xawt/XlibWrapper.o
jib > DTrace_VPrintln 
/scratch/opt/mach5/mesos/work_dir/866342db-c7dc-4a92-a1ef-94525de45f66/workspace/build/solaris-sparcv9-debug/support/native/java.desktop/libawt_xawt/XToolkit.o

jib > ld: fatal: symbol referencing errors
jib > Awt2dLibraries.gmk:327: recipe for target 
'/scratch/opt/mach5/mesos/work_dir/866342db-c7dc-4a92-a1ef-94525de45f66/workspace/build/solaris-sparcv9-debug/support/modules_libs/java.desktop/libawt_xawt.so' 
failed
jib > make[3]: *** 
[/scratch/opt/mach5/mesos/work_dir/866342db-c7dc-4a92-a1ef-94525de45f66/workspace/build/solaris-sparcv9-debug/support/modules_libs/java.desktop/libawt_xawt.so] 
Error 2

jib > make[3]: *** Waiting for unfinished jobs
jib > make/Main.gmk:215: recipe for target 'java.desktop-libs' failed
jib > make[2]: *** [java.desktop-libs] Error 2

On 20/11/2018 4:27 am, volker.simo...@gmail.com wrote:

Changeset: b7192ab3fdf5
Author:simonis
Date:  2018-11-19 19:25 +0100
URL:   http://hg.openjdk.java.net/jdk/jdk/rev/b7192ab3fdf5

8214007: Fix sun.awt.nativedebug on X11 platforms
Reviewed-by: erikj, ihse

! make/lib/Awt2dLibraries.gmk

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

[Philip Race]

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 a jdk-submit run?

No. Please push. If there are any issues I'll follow up.

Thanks,
David


I'm about to call it a day, and since jdk-submit takes 4-6 hours, that
would mean someone else would have to push the fix.

..Thomas
On Mon, Nov 19, 2018 at 10:13 PM Thomas Stüfe  wrote:

Hi all,

may I please have a quick review. We want to backout 8214007 for now
since it breaks Solaris.

https://bugs.openjdk.java.net/browse/JDK-8214075

http://cr.openjdk.java.net/~stuefe/webrevs/8214075-backout-8214007/webrev.00/webrev/

Thanks, Thomas

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

[Philip Race]

+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.

Bug: https://bugs.openjdk.java.net/browse/JDK-8213906

Webrev: http://cr.openjdk.java.net/~erikj/8213906/webrev.01/


Looks good.

Tim

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

[Philip Race]

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 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/
https://bugs.openjdk.java.net/browse/JDK-8213944

Change JDK-8210863 removed the Xrandr.h/randr.h headers from the
OpenJDK sources but forgot to add a configure check for the Xrandr
extension which is now a build dependency.

The change also broke the AIX build. AIX never supported Xrandr, but
that was only detected at runtime, when the JDK was unable to
dynamically load libXrand.so. Now, without Xrandr.h/randr.h in the
source tree any more, we have to conditionally compile some parts of
src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c such
that it doesn't require the definitions and declarations from
Xrandr.h/randr.h any more.

Thank you and best regards,
Volker

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

[Philip Race]

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/
https://bugs.openjdk.java.net/browse/JDK-8213944

Change JDK-8210863 removed the Xrandr.h/randr.h headers from the
OpenJDK sources but forgot to add a configure check for the Xrandr
extension which is now a build dependency.

The change also broke the AIX build. AIX never supported Xrandr, but
that was only detected at runtime, when the JDK was unable to
dynamically load libXrand.so. Now, without Xrandr.h/randr.h in the
source tree any more, we have to conditionally compile some parts of
src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c such
that it doesn't require the definitions and declarations from
Xrandr.h/randr.h any more.

Thank you and best regards,
Volker

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

[Philip Race]

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 being public because they are all in a module and not exported.

I would put them all under share/classes/jdk/jpackagers/internal/ and
save a directory level.


That isn't how the rest of the JDK is organised.
Platform specific classes are split where you have "share" in the path 
above.

So whilst the other issues are more arguable I don't think the build team
would like platform specific classes under share. There is already an
objection to that for the native files.

To the "too many files in one package/directory" point.
I think that might happen at the directory level if Andy went through with
his suggestion but I don't think it will happen with what I proposed and
we probably should get some benefit from being able to make classes + 
methods

package private.

So I think what I proposed is about right ..

phil


$.02, Roger


On 11/13/2018 03:46 PM, Andy Herrick wrote:

I agree with this and would take it further.

1 file is in ./share/classes/jdk/jpackager/internal/builders - why 
not just ./share/classes/jdk/jpackager/internal


2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why 
not just in ./share/classes/jdk/jpackager/internal


1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux - 
why not just ./linux/classes/jdk/jpackager/internal


1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
why not just ./macosx/classes/jdk/jpackager/internal


1 file is in 
./windows/classes/jdk/jpackager/internal/builders/windows - why not 
just ./windows/classes/jdk/jpackager/internal


then just move the associated resources -

Basically put everything except Main in same package - everything 
would be easier to find, and we could make almost all methods 
package-private (the only exception would be the few things called by 
Main, and the ToolProvider.



On 11/13/2018 2:54 PM, Phil Race wrote:
Question .. why is "mac", "linux" and "windows" necessary in the 
package name here ?


 src/jdk.jpackager/macosx/classes/jdk/jpackager/internal/mac/MacAppBundler.java 

 src/jdk.jpackager/windows/classes/jdk/jpackager/internal/builders/windows/WindowsAppImageBuilder.java 

src/jdk.jpackager/linux/classes/jdk/jpackager/internal/linux/LinuxRpmBundler.java 



There's not likely to be a clash, so is there some other reason not 
to want these

in the same package as the shared internals like
src/jdk.jpackager/share/classes/jdk/jpackager/internal/Param.java

?

-phil.


I agree with this and would take it further.

1 file is in ./share/classes/jdk/jpackager/internal/builders - why 
not just ./share/classes/jdk/jpackager/internal


2 files are in ./share/classes/jdk/jpackager/internal/bundlers - why 
not just in ./share/classes/jdk/jpackager/internal


1 file is in ./linux/classes/jdk/jpackager/internal/builders/linux - 
why not just ./linux/classes/jdk/jpackager/internal


1 file is in ./macosx/classes/jdk/jpackager/internal/builders/mac - 
why not just ./macosx/classes/jdk/jpackager/internal


1 file is in 
./windows/classes/jdk/jpackager/internal/builders/windows - why not 
just ./windows/classes/jdk/jpackager/internal


then just move the associated resources -

Basically put everything except Main in same package - everything 
would be easier to find, and we could make almost all methods 
package-private (the only exception would be the few things called by 
Main, and the ToolProvider.


/Andy

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

[Philip Race]

BTW there were also a few minor grammar issues in javadoc
eg

  41  * the option named "-singleton" must be specified on jpackager command 
line.

"the jpackager"


  84  * Registers {@code SingleInstanceListener} for current process.
and
  96  * Registers {@code SingleInstanceListener} for current process.

and
 122  * Unregisters {@code SingleInstanceListener} for current process.
 123  * If the {@code SingleInstanceListener} object is not registered, or
 124  * {@code slistener} is {@code null}, then the unregistration is 
skipped.


"the current 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/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. Probably it only makes sense or gets used
when the API is used from a running desktop application.

I might ask if we need this at all, but I definitely think it should
not be required on all platforms if needed only for Mac even if
we might want it on windows in a future version.

Do we not envisage cases where you need the runtime API for
some kind of daemon service for which there should be a singleton ?
Do you really want to force the desktop module to be dragged along
in such a case ?

I think we should remove this dependency even if it means losing a
MacOS feature at least for now.


1.) we could remove that functionality (I don't even really 
understand the use case for it), and remove the two arg 
registerSingleInstance method from the public interface, and remove 
the requires statement in module-info.java.


I was thinking remove it as above since since even the javadoc for 
that method

feels obliged to say it is just for macos :-

  95 /**
  96  * Registers {@code SingleInstanceListener} for current 
process.
  97  * If the {@code SingleInstanceListener} object is already 
registered, or
  98  * {@code slistener} is {@code null}, then the registration 
is skipped.

  99  *
 100  * @param slistener the listener to handle the single 
instance behaviour.
 101  * @param setFileHandler if {@code true}, the listener is 
notified when the
 102  * application is asked to open a list of files. If 
OS is not MacOS,

 103  * the parameter is ignored.
 104  */


yuck. If such optional functionality is needed it needs to be done via
adding a "doesPlatformSupportFileHandler() method rather than saying 
the above.


-phil.


OK - I filed JDK-8213756 
<https://bugs.openjdk.java.net/browse/JDK-8213756> to handle removing 
this API, fixing the call to new SingleInstanceImpl() to be wrapped in 
synchronized null check, and fixing comments you referred to .


/Andy




or ...

2.) we could move that functionality to a platform dependent class, 
having dummy methods of setOpenFileHandler in the windows and linux  
platform dependent class.  Then we could add a 
module-info.java.extra in src/jdk.jpackager.runtime/macos/classes 
with that requires statement.


/Andy



-phil.

On 11/11/18, 2:40 PM, Andy Herrick wrote:

On 11/9/2018 5:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation 
of the Java Packager Tool (jpackager) as described in JEP 343: 
Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
initial set of automated tests, and contains fixes to the 
following issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the 
next few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 F

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

[Philip Race]

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. Probably it only makes sense or gets used
when the API is used from a running desktop application.

I might ask if we need this at all, but I definitely think it should
not be required on all platforms if needed only for Mac even if
we might want it on windows in a future version.

Do we not envisage cases where you need the runtime API for
some kind of daemon service for which there should be a singleton ?
Do you really want to force the desktop module to be dragged along
in such a case ?

I think we should remove this dependency even if it means losing a
MacOS feature at least for now.


1.) we could remove that functionality (I don't even really understand 
the use case for it), and remove the two arg registerSingleInstance 
method from the public interface, and remove the requires statement in 
module-info.java.


I was thinking remove it as above since since even the javadoc for that 
method

feels obliged to say it is just for macos :-

  95 /**
  96  * Registers {@code SingleInstanceListener} for current process.
  97  * If the {@code SingleInstanceListener} object is already registered, 
or
  98  * {@code slistener} is {@code null}, then the registration is skipped.
  99  *
 100  * @param slistener the listener to handle the single instance 
behaviour.
 101  * @param setFileHandler if {@code true}, the listener is notified 
when the
 102  * application is asked to open a list of files. If OS is not 
MacOS,
 103  * the parameter is ignored.
 104  */


yuck. If such optional functionality is needed it needs to be done via
adding a "doesPlatformSupportFileHandler() method rather than saying the above.

-phil.


or ...

2.) we could move that functionality to a platform dependent class, 
having dummy methods of setOpenFileHandler in the windows and linux  
platform dependent class.  Then we could add a module-info.java.extra 
in src/jdk.jpackager.runtime/macos/classes with that requires statement.


/Andy



-phil.

On 11/11/18, 2:40 PM, Andy Herrick wrote:

On 11/9/2018 5:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation 
of the Java Packager Tool (jpackager) as described in JEP 343: 
Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
initial set of automated tests, and contains fixes to the following 
issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the 
next few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 File name is not passed to main() via file 
association on OS X

JDK-8212538 Determine standard way to determine if a Modular jar
JDK-8213558 Create more unit tests
Note: The above issues are targeted to 'internal' - meaning we 
expect to resolve them in the sandbox before the initial push to JDK12.
Issues targeted to '12' are expected to be fixed after the initial 
push.


/Andy


Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

please send feedback to core-libs-...@openjdk.java.net

/Andy Herrick

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

[Philip Race]

  74
  75 static String getTmpDir() {
  76 String os = System.getProperty("os.name").toLowerCase();
  77 if (os.contains("win")) {
  78 return System.getProperty("user.home")
  79 + "\\AppData\\LocalLow\\Sun\\Java\\JPackager\\tmp";
  80 } else if (os.contains("mac") || os.contains("os x")) {
  81 return System.getProperty("user.home")
  82 + "/Library/Application 
Support/Oracle/Java/JPackager/tmp";
  83 } else if (os.contains("nix") || os.contains("nux")
  84 || os.contains("aix")) {
  85 return System.getProperty("user.home") + 
"/.java/jpackager/tmp";
  86 }
  87
  88 return System.getProperty("java.io.tmpdir");


This seems unduly complex, and I don't understand the implication of
supporting AIX .. or some unknown "Unix", when packager is targeted
only at mac, linux + windows.

I think its sufficient to look for the strings windows, macos and linux.
And if you want a persistent 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 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 application.

I might ask if we need this at all, but I definitely think it should
not be required on all platforms if needed only for Mac even if
we might want it on windows in a future version.

Do we not envisage cases where you need the runtime API for
some kind of daemon service for which there should be a singleton ?
Do you really want to force the desktop module to be dragged along
in such a case ?

I think we should remove this dependency even if it means losing a
MacOS feature at least for now.

-phil.

On 11/11/18, 2:40 PM, Andy Herrick wrote:

On 11/9/2018 5:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation 
of the Java Packager Tool (jpackager) as described in JEP 343: 
Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
initial set of automated tests, and contains fixes to the following 
issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the 
next few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 File name is not passed to main() via file 
association on OS X

JDK-8212538 Determine standard way to determine if a Modular jar
JDK-8213558 Create more unit tests
Note: The above issues are targeted to 'internal' - meaning we 
expect to resolve them in the sandbox before the initial push to JDK12.
Issues targeted to '12' are expected to be fixed after the initial 
push.


/Andy


Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

please send feedback to core-libs-...@openjdk.java.net

/Andy Herrick

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

[Philip Race]

SingleInstanceService. registerSingleInstance() says

If the {@code SingleInstanceListener} object is already registered, or
  98  * {@code slistener} is {@code null}, then the registration is skipped.


I don't see how that can be working as every call to

registerSingleInstanceForId creates a new instance and assigns
it to the static variable.

 114 instance = new SingleInstanceImpl();

Shouldn't this be wrapped in a synchronized null check ?

And what is the contract for equality of a SingleInstanceListener.

The API defines it as an interface but says nothing more .

And I'm not sure what is meant by the 2nd part of this below :-

36 /**
  37  * This method should be implemented by the application to
  38  * handle the single instance behaviour - how should the application
  39  * handle the arguments when another instance of the application is
  40  * invoked with params.

It is phrased like a question without a question mark.

Is it supposed to mean more like :

36 /**
  37  * This method must be implemented by the application to
  38  * handle the single instance behaviour. For example it will
  * need to resolve cases 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 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 application.

I might ask if we need this at all, but I definitely think it should
not be required on all platforms if needed only for Mac even if
we might want it on windows in a future version.

Do we not envisage cases where you need the runtime API for
some kind of daemon service for which there should be a singleton ?
Do you really want to force the desktop module to be dragged along
in such a case ?

I think we should remove this dependency even if it means losing a
MacOS feature at least for now.

-phil.

On 11/11/18, 2:40 PM, Andy Herrick wrote:

On 11/9/2018 5:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation of 
the Java Packager Tool (jpackager) as described in JEP 343: 
Packaging Tool <https://bugs.openjdk.java.net/browse/JDK-8200758>


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
initial set of automated tests, and contains fixes to the following 
issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the 
next few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 File name is not passed to main() via file 
association on OS X

JDK-8212538 Determine standard way to determine if a Modular jar
JDK-8213558 Create more unit tests
Note: The above issues are targeted to 'internal' - meaning we expect 
to resolve them in the sandbox before the initial push to JDK12.

Issues targeted to '12' are expected to be fixed after the initial push.

/Andy


Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

please send feedback to core-libs-...@openjdk.java.net

/Andy Herrick

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

[Philip Race]

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 application.

I might ask if we need this at all, but I definitely think it should
not be required on all platforms if needed only for Mac even if
we might want it on windows in a future version.

Do we not envisage cases where you need the runtime API for
some kind of daemon service for which there should be a singleton ?
Do you really want to force the desktop module to be dragged along
in such a case ?

I think we should remove this dependency even if it means losing a
MacOS feature at least for now.

-phil.

On 11/11/18, 2:40 PM, Andy Herrick wrote:

On 11/9/2018 5:25 PM, Andy Herrick wrote:
This is an update to the Request For Review of the implementation of 
the Java Packager Tool (jpackager) as described in JEP 343: Packaging 
Tool 


This refresh renames the packages used to jdk.jpackager and 
jdk.jpackager.runtime, removes the JNLPConverter demo, adds an 
initial set of automated tests, and contains fixes to the following 
issues:


JDK-8213324 jpackager deletes existing app directory without warning
JDK-8213166 jpackager --argument arg is broken
JDK-8213163 --app-image arg does not work creating exe installers
JDK-8212089 Prepare packager for localization
JDK-8212537 Create method and class description comments for main 
functionality

JDK-8213332 Create minimal automated tests for jpackager
JDK-821 Fix issues found in jpackager with automated tests
JDK-8213394 Stop using Log.info() except for expected output.
JDK-8213345 Secondary Launchers broken on mac.
JDK-8213156 rename packages for jpackager
JDK-8213244 Fix all warnings in jpackager java code
JDK-8212143 Remove native code that supports UserJvmOptionsService
JDK-8213162 Association description in Inno Setup cannot contain 
double quotes


The following additional issues are targeted to be address in the 
next few weeks:

JDK-8212936 Makefile and other improvements for jpackager
JDK-8212164 resolve jre.list and jre.module.list
JDK-8213392 Enhance --help and --version
JDK-8208652 File name is not passed to main() via file 
association on OS X

JDK-8212538 Determine standard way to determine if a Modular jar
JDK-8213558 Create more unit tests
Note: The above issues are targeted to 'internal' - meaning we expect 
to resolve them in the sandbox before the initial push to JDK12.

Issues targeted to '12' are expected to be fixed after the initial push.

/Andy


Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.2/

please send feedback to core-libs-...@openjdk.java.net

/Andy Herrick

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

[Philip Race]

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 .. 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 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 like a lot of work, but it won't be disproportionate 
and I've made the same
request for similar reviews and without it, it is hard to review the 
changes.


For example (and I do mean just example)
http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html

why would that not be #ifdef instead ?

3) Testing .. did you run at least all our jtreg tests to make sure 
you didn't break

some behaviour ..

-phil.

On 9/29/18, 8:18 PM, Krishna Addepalli wrote:


Hi All,

Please review a fix for JDK-8074824: 
https://bugs.openjdk.java.net/browse/JDK-8074824


Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 
<http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>


Most of the warnings have been fixed for Linux, Mac and Windows.

Thanks,

Krishna

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

[Philip Race]

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 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 like a lot of work, but it won't be disproportionate 
and I've made the same
request for similar reviews and without it, it is hard to review the 
changes.


For example (and I do mean just example)
http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html

why would that not be #ifdef instead ?

3) Testing .. did you run at least all our jtreg tests to make sure 
you didn't break

some behaviour ..

-phil.

On 9/29/18, 8:18 PM, Krishna Addepalli wrote:


Hi All,

Please review a fix for JDK-8074824: 
https://bugs.openjdk.java.net/browse/JDK-8074824


Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 
<http://cr.openjdk.java.net/%7Ekaddepalli/8074824/webrev01/>


Most of the warnings have been fixed for Linux, Mac and Windows.

Thanks,

Krishna

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

[Philip Race]

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 like a lot of work, but it won't be disproportionate 
and I've made the same
request for similar reviews and without it, it is hard to review the 
changes.


For example (and I do mean just example)
http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html

why would that not be #ifdef instead ?

3) Testing .. did you run at least all our jtreg tests to make sure you 
didn't break

some behaviour ..

-phil.

On 9/29/18, 8:18 PM, Krishna Addepalli wrote:


Hi All,

Please review a fix for JDK-8074824: 
https://bugs.openjdk.java.net/browse/JDK-8074824


Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ 



Most of the warnings have been fixed for Linux, Mac and Windows.

Thanks,

Krishna

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

[Philip Race]

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.
So if there is an actual logic error in medialib, I'd prefer to fix it.
If the issue is a false positive, I'd be OK to disable the warning, but 
wrapped

in a platform-specific manner. So is it a real error here ?

-phil.

On 8/30/18, 3:37 PM, Brian Burkhalter wrote:

Hi Andrew,

As noted in the issue comments, the fdlibm C code is obsolescent and 
eventually to be superseded by equivalent Java implementations. As for 
the mediaLib code being moribund I cannot speak but am copying 2d-dev 
which owns java.desktop.


Thanks,

Brian

On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>> wrote:



Thanks Magnus,
Yes, these libraries are moribound it seems, hence their preference 
for compile options..

Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 






From: Magnus Ihse Bursie >
To: Andrew Leonard >, Brian Burkhalter 
mailto:brian.burkhal...@oracle.com>>
Cc: core-libs-...@openjdk.java.net 
, build-dev 
mailto:build-dev@openjdk.java.net>>

Date: 30/08/2018 13:49
Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux




Andrew,

If you want to make changes to the build system (files in make/*),
please always include build-dev in the reviews.

From a build point, this fix looks okay. My general preference is to
fix shady code instead of disabling warnings, but in this case it's in
two libraries that are either external or moribound, so if the
maintainer's of the respective libraries want to avoid code changes, I
accept that.

/Magnus


On 2018-08-30 14:18, Andrew Leonard wrote:
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 


> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com 


>
>
>
>
> From:   Brian Burkhalter >
> To: Andrew Leonard >
> Cc: core-libs-...@openjdk.java.net 


> Date:   28/08/2018 15:52
> Subject:Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>
>
>
> Hi Andrew,
>
> It was suggested that it would be preferable to dial down the 
compilation

> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
>
> Thanks,
>
> Brian
>
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>>

> wrote:
>
> We have discovered issues with gcc 7.3 on zLinux, combined with 
OpenJDK's

> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>   - validating loop test array bounds
>   - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 


>
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
>
> I'd like to request a sponsor for this fix please?
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU

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

[Philip Race]

The only comment I have is about this

-  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0
+  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0

I suppose these platform defines are harmless and un-referenced unless building 
for
the specified platform. Seems like the ARM one has been harmless for an x64 
build
so we could for now assume the PPC one is too.
Or you could use jdk-submit to prove this :-)

-phil.


On 8/8/18, 12:59 AM, Baesken, Matthias wrote:


Hello ,

please review this small adjustment for  the build of libsplashscreen 
,  especially the libpng parts .


Back then,  we had to fix the  build of  the libpng parts  in 
libsplashscreen  on linux ppc64le   with  “8195615 : libsplashscreen 
linux ppc64le build error after libpng update”  .


However this introduced a small adjustment to pngpriv.h  that needs to 
be kept every time libpng  is updated   (happened recently when Phil 
updated the lib).


So I better want to remove the adjustment  to pngpriv  from   8195615 
,  and instead change the build settings to fix the compilation  on 
linuxppc64 le .


Webrev/bug :

http://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, Martin ; 2d-...@openjdk.java.net; 
Simonis, Volker ; Lindenmaier, Goetz 

*Subject:* Re: libsplashscreen compilation on ppc64 ( le) - was : RE: 
RFR 8195615 : libsplashscreen linux ppc64le build error after libpng 
update


Works for me. Include build-dev on the review.
And splashscreen is considered an AWT feature so it should be awt-dev 
not 2d-dev

although you may want to reference back to this earlier exchange.

-phil.

On 8/7/18, 8:04 AM, Baesken, Matthias wrote:

Hello,  should  I  prepare a change  setting the 
-DPNG_POWERPC_VSX=0   flag  in the makefile  (see below) ?


Might  make future  libpng updates  more simple .

Best regards, Matthias

*From:*Baesken, Matthias
*Sent:* Donnerstag, 2. August 2018 17:28
*To:* 'Phil Race' 
<mailto:philip.r...@oracle.com>; Doerr, Martin
 <mailto:martin.do...@sap.com>
*Cc:* Simonis, Volker 
<mailto:volker.simo...@sap.com>; Lindenmaier, Goetz
 <mailto:goetz.lindenma...@sap.com>
*Subject:* RE: RFR 8195615 : libsplashscreen linux ppc64le build
error after libpng update - was : RE: jdk-hs ppc64le build error,
probably related to libpng update

Hi Phil,  I added  -DPNG_POWERPC_VSX=0   to   Awt2dLibraries.gmk 
for the  sphlashscreen library build,  and removed  (uncommented)

the workaround  in pngpriv.h .

Build on the head of   jdk11  was fine  on  my  linux ppc64le  
test machine .


Best regards, Matthias

Diff:

/open_jdk/jdk11> hg diff

diff -r 26cca23c165a make/lib/Awt2dLibraries.gmk

--- a/make/lib/Awt2dLibraries.gmk   Thu Aug 02 09:49:04 2018 +0200

+++ b/make/lib/Awt2dLibraries.gmk   Thu Aug 02 16:50:09 2018 +0200

@@ -794,7 +794,8 @@

 LIBSPLASHSCREEN_EXCLUDE_SRC_PATTERNS := unix

   endif

-  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE
-DPNG_ARM_NEON_OPT=0

+  # disable ppc64 opts

+  LIBSPLASHSCREEN_CFLAGS += -DSPLASHSCREEN -DPNG_NO_MMX_CODE
-DPNG_ARM_NEON_OPT=0 -DPNG_POWERPC_VSX=0

   ifeq ($(OPENJDK_TARGET_OS), macosx)

 LIBSPLASHSCREEN_CFLAGS += -DWITH_MACOSX

diff -r 26cca23c165a
src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h

---
a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.hThu
Aug 02 09:49:04 2018 +0200

+++
b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.hThu
Aug 02 16:50:09 2018 +0200

@@ -290,12 +290,12 @@

#  endif

#endif /* PNG_MIPS_MSA_OPT > 0 */

-#ifdef PNG_POWERPC_VSX_API_SUPPORTED

+/* #ifdef PNG_POWERPC_VSX_API_SUPPORTED */

#if PNG_POWERPC_VSX_OPT > 0

#  define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx

#  define PNG_POWERPC_VSX_IMPLEMENTATION 1

#endif

-#endif

+/* #endif */

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

[Philip Race]

> 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 Guido's suggestion.

I'll push it tomorrow if every one is OK with that.

-phil.

On 5/31/18, 10:33 AM, Phil Race wrote:


I've grabbed the bug from Thomas and re-opened it

https://bugs.openjdk.java.net/browse/

Your webrev was stripped so I've uploaded here :

http://cr.openjdk.java.net/~prr/8200052/

It looks fine to me but I am a bit hazy about who to give attribution 
for the fix ..
It is small enough to not require an OCA so there's no issue there if 
we attribute

it to the IJG guy.

-phil.

On 05/31/2018 06:31 AM, Adam Farley8 wrote:
An attachment in the email has been found to contain executable code 
and has been removed.


File removed : webrev.zip, zip,html,js

Hi Phil,

As requested:



FYI: I've also contacted Guido, confirmed that the fix worked, and asked
him to go ahead with merging the fix into his code base.

Best Regards

Adam Farley


Phil Race  wrote on 30/05/2018 18:06:19:

> From: Phil Race 
> To: Adam Farley8 
> Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> , build-dev  d...@openjdk.java.net>, Magnus Ihse Bursie
> , "Thomas Stüfe" 


> Date: 30/05/2018 18:07
> Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix
> compile warning in jchuff.c
>
> Thank you for persevering with this. Please submit a webrev with this
> change .. I think you can leave out the change to jerror.h in the 
jpeg6b case.

>
> -phil.

> On 05/30/2018 09:08 AM, Adam Farley8 wrote:
> Hi Phil,
>
> I spoke with the jpegclub rep "Guido", and he was very helpful.
>
> He agreed to accept a code change, but recommended an error instead
> of a while check.
>
> -- Line 808:
> <   while (bits[j] == 0)
> < j--;
> ---
> >   while (bits[j] == 0) {
> > if (j == 0)
> >   ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW);
> > j--;
> >   }
> --
>
> This makes sense to me, and I verified that it prevents the error.
>
> He says:
> 
> For the release version I would replace the specific
> JERR_HUFF_CLEN_OVERFLOW by the more general
> JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this
> requires a change in jerror.h:
>
> -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow")
> +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out 
of bounds")

>
> The next version (9d) is planned for release in January 2020.
> A pre-release package will be provided in 2019 on http://
> jpegclub.org/reference/reference-sources/, I will send you a 
notification.

> 
>
> While we *could* make the jerror.h change, I suggest we don't for
> now. If we merge from upstream in January 2020, we'll get that
> change anyway when the time comes.
>
> So what do you say to including the dashed change referenced above
> to fix our problem now, safe in the knowledge that upstream will be
> similarly modified (except with the new error type).
>
> Best Regards
>
> Adam Farley
>
> P.S. I'm holding off on giving Guido the green light until after
> people say if they're happy with the error-enabled version of the fix.
>
> Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28:
>
> > From: Adam Farley8/UK/IBM
> > To: Phil Race 
> > Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> > , build-dev  > d...@openjdk.java.net>, Magnus Ihse Bursie
> > , "Thomas Stüfe" 


> > Date: 14/05/2018 11:06
> > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix
> > compile warning in jchuff.c
> >
> > Hi Phil,
> >
> > Would an acceptable compromise be to deliver the source code change
> > and send the code to the upstream community, allowing them to include
> > the fix if/when they are able?
> >
> > I believe Magnus was advocating this idea as well. See below.
> >
> > Best Regards
> >
> > Adam Farley
> >
> > > Same here. I would like to have this fix in, but do not want to go
> > > over Phils head.
> > >
> > > I think Phil was the main objector, maybe he could reconsider?`
> > >
> > > Thanks, Thomas
> > >
> > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie
> > >  wrote:
> > > > I don't object, but it's not build code so I don't have the 
final say.

> > > >
> > > > /Magnus
> > > >
> > > >
> > > > On 2018-04-25 17:43, Adam Farley8 wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Does anyone have an objection to pushing this tiny change in?
> > > >
> > > > It doesn't break anything, it fixes a build break on two 
supported

> > > > platforms, and it seems
> > > > like we never refresh the code from upstream.
> > > >
> > > > - Adam
> > > >
> > > >> I also advocate the source code fix, as Make isn't meant to
> use the sort
> > > >> of logic 

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

[Philip Race]

 # 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 that
are not suitable in some way but it did not matter before ..

-phil

On 5/24/18, 3:26 PM, Erik Joelsson wrote:
Now that we have support for building with VS2017, it's time to change 
the default compiler picked up by the configure script to VS2017.


Oracle is also changing the version used internally, by updating 
jib-profiles.js


Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8203795

/Erik

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

[Philip Race]

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: 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
 - Tests in sun/applet were removed and TEST.ROOT/TEST.groups were 
updated

 - Small update in make file was done

We still have a few classes in sun.applet package which are related 
to the client security, sound. I think that we can drop it as well at 
some point.

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

[Philip Race]

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 unix/X11InputMethod <-class unix/XInputMethod

Now we have

   abstract class unix/X11InputMethodBase

/\

   /   \

  /  \

 /\

  abstract class unix/X11InputMethodabstract class 
aix/X11InputMethod

  \/
   \  /
\/
  class unix/XInputMethod



I have submitted a build job with this patch to make sure it all builds 
on Linux & Solaris ..

and it was all fine.

But testing for this would have to be manual, and I don't have cycles 
for that.

So I'll have to accept that the testing done by IBM was enough

So only minor comments ...
http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java.sdiff.html

 730 case 0: //None of the value is set by Wnn

"value is " ->  "values are " ?


http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html

why did you move

  26 #ifdef HEADLESS
  27 #error This file should not be included in headless library
  28 #endif


I think it should be first. It is also missing from the equivalent AIX file but 
that is
up to you .. I really didn't look any further at the AIX files.

.. and there seems no point to moving around some of the other includes
except to make the webrev harder to read :-)

But good job cleaning up a lot of the formatting of the native code.

-phil.





On 5/18/18, 4:59 AM, Langer, Christoph wrote:

Hi all,

Here is an updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/
Can someone from the graphics/awt team please have a look at that change? 
Especially checking that we don't break non-AIX platforms? Thanks in advance.

@Ichiroh: Thanks for your review and tests. Adressing your points:


resetCompositionState() was missing in
src/java.desktop/aix/classes/sun/awt/X11InputMethod.java
==
==
--- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java  Wed May
09 09:05:32 2018 +0900
+++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java  Mon
May
14 21:25:50 2018 +0900
@@ -56,6 +56,21 @@
   }

   /**
+ * Reset the composition state to the current composition state.
+ */
+protected void resetCompositionState() {
+if (compositionEnableSupported&&  haveActiveClient()) {
+try {
+/* Restore the composition mode to the last saved
composition
+   mode. */
+setCompositionEnabled(savedCompositionState);
+} catch (UnsupportedOperationException e) {
+compositionEnableSupported = false;
+}
+}
+}
+
+/**
* Activate input method.
*/
   public synchronized void activate() {
==

Good catch. I've incorporated that in my new webrev.


Otherwise,
we could not find out any functional difference on Linux.
we could not find out any functional difference between our modified code and 
your code on AIX.

By code check, we found following difference.
==
==
--- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
Wed May 09 09:05:32 2018 +0900
+++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c
Mon May 14 21:25:50 2018 +0900
@@ -248,6 +248,10 @@
"flushText",
"()V");
   JNU_CHECK_EXCEPTION_RETURN(env, NULL);
+if ((*env)->ExceptionOccurred(env)) {
+(*env)->ExceptionDescribe(env);
+(*env)->ExceptionClear(env);
+}
   /* IMPORTANT:
  The order of the following calls is critical since
"imInstance" may
  point to the global reference itself, if
"freeX11InputMethodData" is called
==

Did you remove this code intentionally ?

Yes, I removed that one intentionally. There is no point in doing the Exception 
check/clearing after a call to JNU_CHECK_EXCEPTION_RETURN(env, NULL);


Otherwise, I think the other changes were acceptable.



Thanks and Best regards
Christoph

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

[Philip Race]

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, Erik Joelsson wrote:

Build changes look good.

/Erik


On 2018-05-16 15:52, Phil Race wrote:

Webrev: http://cr.openjdk.java.net/~prr/8191522/
Bug: https://bugs.openjdk.java.net/browse/JDK-8191522

The Lucida fonts have never been part of OpenJDK but many places in 
the code
and tests reference them. There are even a couple of stray fonts.dir 
files that

probably should not have been in there.

This fix cleans up as much of this as we are also intending to no 
longer ship

these fonts with Oracle JDK as it converges with OpenJDK.

There is one minor build change in here, so I've included the build 
list.


-phil.

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

[Philip Race]

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 5/14/18, 3:06 AM, Adam Farley8 wrote:

Hi Phil,

Would an acceptable compromise be to deliver the source code change
and send the code to the upstream community, allowing them to include
the fix if/when they are able?

I believe Magnus was advocating this idea as well. See below.

Best Regards

Adam Farley

> Same here. I would like to have this fix in, but do not want to go
> over Phils head.
>
> I think Phil was the main objector, maybe he could reconsider?`
>
> Thanks, Thomas
>
> On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie
>  wrote:
> > I don't object, but it's not build code so I don't have the final say.
> >
> > /Magnus
> >
> >
> > On 2018-04-25 17:43, Adam Farley8 wrote:
> >
> > Hi All,
> >
> > Does anyone have an objection to pushing this tiny change in?
> >
> > It doesn't break anything, it fixes a build break on two supported
> > platforms, and it seems
> > like we never refresh the code from upstream.
> >
> > - Adam
> >
> >> I also advocate the source code fix, as Make isn't meant to use 
the sort

> >> of logic required
> >> to properly analyse the toolchain version string.
> >>
> >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 
4.8.6,

> >> and Make doesn't
> >> seem to do substring stuff unless you mess around with shells.
> >>
> >> Plus, as people have said, it's better to solve problem x (or work 
around

> >> a specific
> >> instance of x) than to ignore the exception, even if the ignoring 
code is

> >> toolchain-
> >> specific.
> >>
> >> - Adam Farley
> >>
> >> > On 2018-03-27 18:44, Phil Race wrote:
> >> >
> >> >> As I said I prefer the make file change, since this is a change 
to an

> >> >> upstream library.
> >> >
> >> > Newtons fourth law: For every reviewer, there's an equal and 
opposite

> >> > reviewer. :)
> >> >
> >> > Here I am, advocating a source code fix. As Thomas says, the 
compiler
> >> > complaint seems reasonable, and disabling it might cause us to 
miss other

> >> > future errors.
> >> >
> >> > Why can't we push the source code fix, and also submit it upstream?
> >> >
> >> > /Magnus
> >> >
> >> >
> >> > I've looked at jpeg-9c and it still looks identical to what we 
have in

> >> > 6b, so this code
> >> > seems to have stood the test of time. I'm also unclear why the 
compiler

> >> > would
> >> > complain about that and not the one a few lines later
> >> >
> >> >
> >> >  819   while (bits[i] == 0)  /* find largest codelength 
still in

> >> > use */
> >> >  820 i--;
> >> >
> >> > A push to jchuff.c will get blown away if/when we upgrade.
> >> > A tool-chain specific fix in the makefile with an appropriate 
comment is

> >> > more targeted.
> >>
> >> Phil,
> >>
> >> Returning to this.
> >>
> >> While I understand your reluctance to patch upstream code, let me 
point
> >> out that we have not updated libjpeg a single time since the JDK 
was open
> >> sourced. We're using 6b from 27-Mar-1998. I had a look at the 
Wikipedia page
> >> on libjpeg, and this is the latest "uncontroversial" version of 
the source.
> >> Versions 7 and up have proprietary extensions, which in turn has 
resulted in
> >> multiple forks of libjpeg. As it stands, it seems unlikely that we 
will ever

> >> replace libjpeg 6b with a simple upgrade from upstream.
> >>
> >> I therefore maintain my position that a source code fix would be 
the best

> >> way forward here.
> >>
> >> /Magnus
> >>
> >> >
> >> >
> >> > -phil.
> >> >
> >> >
> >> > On 03/27/2018 05:44 AM, Thomas Stüfe wrote:
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > just a friendly reminder. I would like to push this tiny fix 
because
> >> > tripping over this on our linux s390x builds is annoying (yes, 
we can

> >> > maintain patch queues, but this is a constant error source).
> >> >
> >> >
> >> > I will wait for 24 more hours until a reaction. If no serious 
objections
> >> > are forcoming, I want to push it (tier1 tests ran thru, and me 
and Christoph

> >> > langer are both Reviewers).
> >> >
> >> >
> >> > Thanks! Thomas
> >> >
> >> >
> >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas Stüfe 


> >> > wrote:
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > may I please have another review for this really trivial change. It
> >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good 
idea to fix

> >> > this.
> >> >
> >> >
> >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052
> >> > webrev:
> >> > 
http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ 
 


> >> >
> >> >
> >> > This was contributed by Adam 

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

[Philip Race]

+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: 
http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ 




Please note that I also filed an issue which covers addressing these 
warnings in the Right(tm) way (and then removing the disabling of the 
warnings):


https://bugs.openjdk.java.net/browse/JDK-8202051


I have tested this with VS2017, and will also verify that it works 
with the existing toolchain version (used at Oracle).


Cheers,
Mikael

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

[Philip Race]

+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:
 - The appletviewer launcher was removed from jdk/bin
 - The man pages were removed
 - Two tests which used appletviewer launcher directly were removed

Note that the appletviewer was deprecated in in jdk9:
https://bugs.openjdk.java.net/browse/JDK-8074165

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

[Philip Race]

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 someone outside will 
step up to maintain.
Not as different as AIX .. or as much effort perhaps .. but if someone 
will do that I expect patches would not be refused.


-phil.

On 3/9/18, 11:55 PM, Thomas Stüfe wrote:
I attempted to test the 32bit build but that seems to have bitrotted, 
I ran into errors not having anything to do with your change.

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

[Philip Race]

It is correct as is ..

-phil.

On 3/9/18, 3:49 PM, Sergey Bylokhov wrote:

I am not an expert here, but the LICENSE.TXT is a little bit different.
It states that "This means  that *you* must choose  *one* of the  two 
licenses described below,.".
So I do not know should we select the 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/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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official 
OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a 
pain

inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : 
--with-freetype=bundled
The other valid option being "system" which, is of however never 
not valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the 
preferred rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor 
rasterization differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on 
Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

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

[Philip Race]

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 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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

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

[Philip Race]

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

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

[Philip Race]

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 patch directly against that.

Its not "critical" for 10 which is in RDP2 already and 9 is going EOSL 
in less than 3 months  ...


-phil.

On 1/23/18, 9:18 AM, Adam Farley8 wrote:

>On 01/23/2018 05:25 PM, Adam Farley8 wrote:
>>> SLE-11:*  doesn't even have OpenJDK-8 and is also going to be out 
of support

>>> next year  anyway.
>>
>> Does this mean the gcc version will change? If you have hard 
information on

>> this, I'd appreciate the URL.
>
>I'm not sure what you mean. SLE12-SP3 ships gcc-4.8.x while SLE-15 will
>ship gcc-7, see:
>
>> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__build.opensuse.org_package_view-5Ffile_SUSE-3ASLE-2D15-3AGA_gcc_gcc.spec-3Fexpand-3D1=DwIC-g=jf_iaSHvJObTbx-siA1ZOg=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho=dIGHRmVpTLUCdNXpk5OeZoRTr4KMZfiyFp7leAxQ1x4=kvSfKGn4zfKUDx14bZlDZsWrY3uorXE_6lBuTmOMchw= 
 


>
>Is that what you mean when you say the gcc version is changing?

Apologies, I was unclear. I was asking if the minimum gcc version on 
David's
website was likely to change when SLE11 went out of service. From what 
you're
telling me, the sles 11 bit on the site will likely be updated to sles 
12,
and the gcc version won't change (as you're saying SLE12 ships with 
4.8.x).


>
>> If the minimum gcc version for 10 or 11 is above 4.8.5 across all 
platforms,
>> then I agree, but I don't have that information, so I figured I'd 
ask to

>> cover all of the JDK versions, to be safe.
>
>I don't know what the minimum version is at the moment, to be honest. 
I haven't
>tried building OpenJDK-10 or OpenJDK-11 on SLE-12:SP3 yet. I could do 
that

>if that's important.
>
>> Even if the gcc version does change, adding 4.8.5-specific code 
shouldn't

>> break anything.
>
>It most likely doesn't break anything. But it leaves workaround in the 
code

>base which we could potentially forget to clean out later when it is no
>longer needed.

Agreed. I was hedging my bets on the gcc version not changing. Be good 
if we had
some reliable intel on the minimum gcc version that we could use to 
make a

decision.

>
>> What do you think?
>
>My opinion is that the codebase for OpenJDK-11 should be kept clean 
because
>we are working on getting rid of unnecessary cruft. But this decision 
isn't
>up to me, of course. I'm just arguing that I consider the chances that 
someone

>will try OpenJDK-11 on SLE-12:SP3 or even SLE-11:SP4 very low.
>
>Adrian

A reasonable opinion. I may disagree with your conclusions, but you 
present

your arguments well.

Could others on this email chain act as tie breaker on the jdk10+11 
matter please?


Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

[Philip Race]

> 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 option I can think of.


And bear in mind build-dev is not the keeper of the JPEG libraries. 
2d-dev is the right place.


-phil.

On 1/17/18, 6:07 AM, Adam Farley8 wrote:

If this is the consensus, then perhaps we should consider setting
--disable-warnings-as-errors by default (in the code), rather than
depending on the user using an option which is not part of the formal
build instructions.

I'm not sure why.

Because the default build instructions don't work in this scenario, and
if all the effort to impliment a clone-config-make model was intended to
encourage more users to attempt a local build (in order to try their hand
at a fixing a bug themselves or something) it makes sense to me to try
to maintain a scenario where OpenJDK can build to completion across a wide
variety of toolchains.


Building OpenJDK from source isn't exactly something
that is done by normal users. If someone is willing to hack on the

OpenJDK

code base, I would assume they know about -Werror and similar options and
how to control them.

I don't agree. Someone should not have to be familiar with gcc options in
order to fix a typo, or change some Java code. And besides, we have a
clear
and simple four-step build process (clone, get source, configure, make).
Why would we want people to have to fail their build and experiment with
different options, when we can fix the problem right here and now.


I mean, yes, you can change that to have -Werror turned off by default,
but having the compiler complain less is usually a bad idea.

In general, yes. In this one compile it's breaking the build.

David suggested disabling this warning. The simplest way I see to do this
is to change Awt2dLibraries.gmk.

The code is here:

$(eval $(call SetupNativeCompilation,BUILD_LIBJAVAJPEG, \
 LIBRARY := javajpeg, \
 OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \
 SRC := $(LIBJAVAJPEG_SRC), \
 INCLUDE_FILES := $(BUILD_LIBJAVAJPEG_INCLUDE_FILES), \
 OPTIMIZATION := HIGHEST, \

Switching the OPTIMIZATION to LOW will solve this at a stroke.

Best Regards

Adam farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

[Philip Race]

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 is accessed under the windows check:
http://hg.openjdk.java.net/jdk/client/file/ecaa3569ec3d/src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java#l223 




String lafName = UIManager.getLookAndFeel().getClass().getName();
IS_WIN = 
lafName.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");





-phil.

On 11/28/2017 09:28 AM, Erik Joelsson wrote:

From a build point of view, this looks great.

/Erik


On 2017-11-27 18:27, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk10. This is the second attempt to move 
windows L from non-windows platforms. The first attempt 
JDK-6461834[1] was reverted because of JDK-8184813[2].
The root cause of those issue was fixed in JDK-8075255[3], and now 
we can move it again.


Bug: https://bugs.openjdk.java.net/browse/JDK-8189656
Webrev can be found at: 
http://cr.openjdk.java.net/~serb/8189656/webrev.02


The fix contains a few parts:
 - The code related to win l was moved from the "share" to the 
"windows" folder
 - The platform-specific export was moved from module-info.java to 
module-info.java.extra
 - A number of tests which use windows L were marked as 
windows-specific
 - The stub "ThemeReader.java" which was used to build win w on 
unix was removed.


[1] https://bugs.openjdk.java.net/browse/JDK-6461834
[2] https://bugs.openjdk.java.net/browse/JDK-8184813
[3] https://bugs.openjdk.java.net/browse/JDK-8075255

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

[Philip Race]

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.

On 11/29/17, 2:48 PM, Erik Joelsson wrote:
When building macosx openjdk and enabling bundling of freetype (which 
is usually not the default), the makefiles will copy the library in, 
but libfontmanager will not be able to link to it at runtime. This is 
caused by a peculiarity on macosx where a library that is being linked 
to specifies the rpath to use in any library that links to it. At 
Oracle we currently link to the libfreetype in x11 from Quartz, which 
is located in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager 
we build will only look in that location at runtime.


This patch adds a new build step, using the install_name_tool which 
can rewrite this rpath to where you actually have a dependency on your 
system. In this case right next to libfontmanager in the same 
directory. I also changed the import logic that copies in libfreetype 
so that it doesn't a .6 at the end on macosx.


This patch does not change the defaults for bundling of freetype, nor 
does it change how Oracle bundles freetype. That may come later.


Bug: https://bugs.openjdk.java.net/browse/JDK-8139653

Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/

/Erik

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

[Philip Race]

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 Oracle would invest in and not sure who would
do it and keep it working .. whilst ensuring the VC code is still needed.

-phil.

On 11/4/17, 4:26 PM, Andrew Sun wrote:

Hi everyone,

I'm just wondering if OpenJDK could be modified to build on Windows using
MSYS2 (free Windows development environment that includes MinGW-w64 and
GCC). Currently MSYS2's MinGW-w64 toolchain (including GCC) is unsupported
for building OpenJDK, and Visual Studio is required; however, on Linux, GCC
is supported.
Would there be any implications to such a method? If not, I would be very
pleased. MSYS2 uses PKGBUILDs similar to the ones on Arch Linux. Adding a
MinGW-w64 PKGBUILD for mingw-w64-jdk*version*-openjdk would be very
beneficial to the MSYS2 project.

Thanks,

Andrew Sun

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

[Philip Race]

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 henceforth rely on finding it in the build environment for
Linux and Solaris.

The build has been tested on all platforms.

The updated generated-configure.sh is not shown here since its
diff is not useful (easy to read) but will be checked in as part of the fix.

-phil.

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

[Philip Race]

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 updates the build procedure for creating the linux devkit by 
adding fontconfig to the sysroot, as well as bumping the devkit 
version to one with fontconfig included.


Phil, could you test this patch with your changes and see if it 
works. I have tried it locally myself after removing fontconfig.h and 
updating the include to get the one from the system, but it would be 
good to get confirmation from you.


Webrev: http://cr.openjdk.java.net/~erikj/8189119/webrev.01/

Looks good to me.

/Magnus


Bug: https://bugs.openjdk.java.net/browse/JDK-8189119

/Erik

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

[Philip Race]

+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 require msvcr100.dll, 
while the rest of OpenJDK is built with Visual Studio 2013 and 
subsequently require msvcr120.dll.


I have built new freetype binaries, using Visual Studio 2013, from 
the latest available freetype source, 2.7.1. We have verified that 
the OpenJDK builds using these binaries are behaving equally to those 
with the old binary, except for not requiring msvcr100.dll. This 
patch changes the jib-profiles configuration for JDK 9 to use the new 
freetype binaries.


Bug: https://bugs.openjdk.java.net/browse/JDK-8177135

Patch:

diff -r c38c6b270ccc common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -910,7 +910,7 @@
 freetype: {
 organization: common.organization,
 ext: "tar.gz",
-revision: "2.3.4+1.0",
+revision: "2.7.1-v120+1.0",
 module: "freetype-" + input.target_platform
 }
 };

/Erik


Looks good to me.

/Magnus

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

[Philip Race]

+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
+++ b/common/autoconf/version-numbers
@@ -25,7 +25,7 @@

 # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_MAJOR=9
+DEFAULT_VERSION_MAJOR=10
 DEFAULT_VERSION_MINOR=0
 DEFAULT_VERSION_SECURITY=0
 DEFAULT_VERSION_PATCH=0


/Erik

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

[Philip Race]

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 need to update the boot JDK to be JDK 9?


Certainly at some point.  A good number of refactorings need to wait 
until the boot JDK is upgraded. On the other hand, there is an 
argument for JDK 9 being a bit further along before using it for 
bootstrapping. 

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

[Philip Race]

That's fine.

-phil.

On 12/26/16, 7:06 AM, Sergey Bylokhov wrote:

If there are no objections I’ll push this version:
http://cr.openjdk.java.net/~serb/8140266/webrev.01/make/lib/Awt2dLibraries.gmk.sdiff.html 
<http://cr.openjdk.java.net/%7Eserb/8140266/webrev.01/make/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/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 
improve some graphics operations: 20%.


This option is a part of -03.

|-fgcse-after-reload|
   When -fgcse-after-reload is enabled, a redundant load elimination
   pass is performed after reload. The purpose of this pass is to
   clean up redundant spilling.

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Note that if -03 will be enabled directly via OPTIMIZATION flag 
then the performance will not be improved.


Bug: https://bugs.openjdk.java.net/browse/JDK-8140266
Webrev can be found at: 
http://cr.openjdk.java.net/~serb/8140266/webrev.00

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

[Philip Race]

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 improve 
some graphics operations: 20%.


This option is a part of -03.

|-fgcse-after-reload|
When -fgcse-after-reload is enabled, a redundant load elimination
pass is performed after reload. The purpose of this pass is to
clean up redundant spilling. 

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Note that if -03 will be enabled directly via OPTIMIZATION flag then 
the performance will not be improved.


Bug: https://bugs.openjdk.java.net/browse/JDK-8140266
Webrev can be found at: http://cr.openjdk.java.net/~serb/8140266/webrev.00

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

[Philip Race]

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 somewhere and 
link if we are to see them.


AFAIK, we can't build OpenJDK on Linux without freetype so the claim 
that freetype is not used seems weird. I know for sure that it's used 
at build time at least. For questions on how the graphics works, I 
think 2d-dev is the correct mailing list. I think that's where you 
need to continue your investigation.


/Erik


On 2016-12-15 13:10, Artur Rataj wrote:

Hello.

The default OpenJDK in Ubuntu does not seem to use Freetype (see the
attached a.png, b.png). Yet I know that it is possible that OpenJDK uses
freetype because Android Studio is distributed with one (see c.png).

I want Freetype, and thus I attempted to compile the newest stable 
OpenJDK

from source.

bash ./configure --with-freetype=../freetype 
--with-cups=/usr/include/cups

--with-x=/usr/include/X11/extensions --with-jvm-variants=server
--with-target-bits=64 --with-debug-level=release`

checking if we can compile and link with freetype... yes
checking if we should bundle freetype... yes

A simple test of running Netbeans with the resulting JDK shows, that
freetype is still not used, though. The same Netbeans ran using the 
Android

Studio-provided JDK does use Freetype (again, c.png).

I would thus like to ask you how to build OpenJDK so that it actually 
uses

Freetype by default?

Best regards,
Artur

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

[Philip Race]

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 
technology

for our port.

-phil.

On 12/7/16, 1:28 PM, Mandy Chung wrote:

This proposes to organize license files by module in source, JMOD,
and run-time image.

A summary of the proposal:
1. Organize third party notices by module in the source as follows:
 src/$MODULE/{share,$OS}/legal/*

The `legal` directory contains one file for each third party
library in the module, for example,
 src/java.base/share/legal/asm.md
   unicode.md
   zlib.md

The proposed template for this file is described in [1] and JEP 201
will be updated to reflect this proposed source layout.

2. Introduce a new LEGAL_NOTICES section in JMOD format. A new jmod
option `—-legal-notices` is added to package legal notices in
a JMOD file.

3. At jlink time, jlink will copy all legal notices from JMOD files
to the `legal` directory in the run-time image.  A plugin is
added to de-duplicate the legal notices if the filename and the
content matches that may reduce the image footprint.

4. THIRD_PARTY_README in the top-level directory of each repo is removed.
Manual edit to this file, multiple copies is no longer needed.

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169925/webrev.00/

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8169925

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

[Philip Race]

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 that.

-phil.

On 12/8/16, 6:26 PM, David Buck wrote:

Hi!

Please review this trivial makefile change to disable a problematic 
warning.


bug report: https://bugs.openjdk.java.net/browse/JDK-8170954
webrev: http://cr.openjdk.java.net/~dbuck/jdk8170954_ver00/

Cheers,
-Buck

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

[Philip Race]

+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

[Philip Race]

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 things.  The new patch is at:
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/

Looks better.

I only notice now that the readme.html is in the include directory.  That 
should be in the documentation as you proposed earlier.  I don’t think it 
should be copied to the image.

Mandy

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

[Philip Race]

But it still needs to say "jdk9/jdk9" not jdk9/client or jdk9/dev.

-phil.

On 10/26/16, 9:27 PM, Anirvan Sarkar wrote:

Hi,

If you replace the hex number with 'tip' then it will always point to 
the latest version.


Something like 
http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c 
<http://hg.openjdk.java.net/jdk9/client/jdk/file/tip/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c>


Regards,
Anirvan Sarkar

On Thursday 27 October 2016, Pete Brunet <peter.bru...@oracle.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.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

http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c
  
<http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c>

Looks like that hex number in there is the Mercurial long revision
number of the tip so that's going to keep changing.  I'm not aware
of a "latest" link.  Maybe some other reader will know.

But I am not sure about that either .. it may need to be split between the 
main URL and the location in the repo.

-phil


On 10/26/16, 7:24 PM, Pete Brunet wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/  
<http://cr.openjdk.java.net/%7Eptbrunet/JDK-8167213/webrev.03/>

The change is to AccessBridgeCalls.c.  The license has been changed from
GPL2 to BSD.  This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code.  Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository.  Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik


On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/  
<http://cr.openjdk.java.net/%7Eptbrunet/JDK-8167213/webrev.02/>

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll.
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no
longer
be provided the JAB API documentation will be updated to instruct a
user
how to create an equivalent of AccessBridgeCalls.c.  The documentation
will also contain a reference to the JAB 2.0.2 download

http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html
  
<http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html>

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev.  Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/  
<http://cr.openjdk.java.net/%7Eptbrunet/JDK-8167213/webrev.01/>

Rather than removing the files needed by Assistive Technology
developers
we have to provide them in JDK.  However since there is a .c file
in the
group of files the files were moved from the include directory to a
new
javaaccessbridge directory.

On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:

On 2016-10-14 17:51, Pete Brunet wrote:

Please review the following.

The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from
the built
JRE/JDK images.  They are not used much and they can be obtained
online
via the OpenJDK web site.  The pubs will be updated to mention the
location of the files.

Since there is a .c file in this group of files the direc

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

[Philip Race]

>

  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
http://hg.openjdk.java.net/jdk9/jdk9/jdk/src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.c

But I am not sure about that either .. it may need to be split between the main 
URL and the location in the repo.

-phil



On 10/26/16, 7:24 PM, Pete Brunet wrote:

Please review the latest update at
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.03/

The change is to AccessBridgeCalls.c.  The license has been changed from
GPL2 to BSD.  This is because the file was originally unlicensed prior
to being bundled into the JDK and the compiled .obj is linked to by
vendors creating proprietary code.  Vendors will be instructed to
download AccessBridgeCalls.c from the OpenJDK repository.  Also the
include/use of AccessBridgeDebug.h/cpp has been removed.

Please also review readme.html which has been added to
.../jdk/include/win32/bridge.

Pete

On 10/25/16 6:48 AM, Alexandr Scherbatiy wrote:

The fix looks good to me.

Thanks,
Alexandr.

On 10/24/2016 1:18 PM, Erik Joelsson wrote:

The last change looks good and simple to me.

/Erik


On 2016-10-21 06:55, Pete Brunet wrote:

Please see the latest update
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.02/

The fix now is to simply remove the copy of the AccessBridgeCalls.c
file
into the JDK.

AccessBridgeCalls.c is the implementation of the documented Java Access
Bridge API and is a set of wrapper functions that hides the
complications related to interfacing to JAB's WindowsAccessBridge*.dll.
In the past users of the API would compile and link to
AccessBridgeCalls.c/obj.

Since the interface implementation of AccessBridgeCalls.c will no
longer
be provided the JAB API documentation will be updated to instruct a
user
how to create an equivalent of AccessBridgeCalls.c.  The documentation
will also contain a reference to the JAB 2.0.2 download
http://www.oracle.com/technetwork/java/javase/downloads/jab-2-0-2-download-354311.html

which does contain AccessBridgeCalls.c and which is compatible with the
current API and related calls into WindowsAccessBridge*.dll.

Pete

On 10/18/16 12:28 PM, Pete Brunet wrote:

I've updated the webrev.  Please see
http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.01/

Rather than removing the files needed by Assistive Technology
developers
we have to provide them in JDK.  However since there is a .c file
in the
group of files the files were moved from the include directory to a
new
javaaccessbridge directory.

On 10/17/16 2:43 AM, Magnus Ihse Bursie wrote:

On 2016-10-14 17:51, Pete Brunet wrote:

Please review the following.

The .h files and .c file provided to allow Assistive Technology to
interface to the Java Access Bridge API are being removed from
the built
JRE/JDK images.  They are not used much and they can be obtained
online
via the OpenJDK web site.  The pubs will be updated to mention the
location of the files.

Since there is a .c file in this group of files the directory
structure
has been changed slightly to remove the include directory.

There was one file missing from the group of files needed by
developers
and that was moved from the common to the bridge directory.

The make was updated in response to the above.

Bug: https://bugs.openjdk.java.net/browse/JDK-8167213

Webrev: http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.00/

Build changes looks good to me.

/Magnus

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

[Philip Race]

On 8/24/16, 2:48 AM, Erik Joelsson wrote:
> Hello,
>
>
> On 2016-08-23 18:12, Phil Race wrote:
>> On 08/23/2016 08:47 AM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> I do agree that maintaining the list of disabled warnings will be
>>> impossible unless we have a structured way of tracking for which
>>> compiler versions we disable what. Ideally we should be able to easily
>>> add conditions for when certain warnings should be disabled. We are
>>> unfortunately lacking that today and at least I don't have the
>>> bandwidth to fix that anytime soon.
>>>
>>> The official compilers are only really official for Oracle. The
>>> OpenJDK can (and should) be buildable with a much wider range of
>>> compiler versions.
>> I agree there. This is fortunately not an "unbuildable" situation.
>> The only other option I can think of which may or may not be palatable
>> is to explicitly
>> check the compiler version and add that disabled warning only for that
>> exact compiler version.
>> There'd still be some maintenance as that compiler version became either
>> official .. or obsolete ..
>>
>> Is there precedent (or any kind of support) for that ?
> What I had in mind was a structured way of adding conditionals for
> some kind of ranges of compiler versions, or at least something like
> 6.*, or "greater than 4.9.3". It's pretty simple today to check for
> exact compiler versions but then we end up with a lot of changes when
> minor versions are bumped. I don't think that would be worth it.
>
> In this particular 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+.

OK lets allow this with a comment and hope it does not set a trend.
I'd be largely unwilling to do it if it were not for the fact that someday
I presume we'll be using gcc6 ...

If there is a chance that - someday - you will get around to that
"structured way", maybe a comment could be added that follow a
standard format we devise so if this is requested for some other
compiler you are able to grep and find all the ones to fix.
Although this one makefile is probably the place to look so may
be it is not really needed.
The comment also ought to be phrased in a way that it is
apparent the disabled warning should be left alone.

-phil.

>
> /Erik
>> -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.
>>>
>>> So for now at least, I think Phil is right.
>>>
>>> /Erik
>>>
>>> On 2016-08-23 17:11, Philip Race wrote:
>>>> 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 warnings for a whole range
>>>> of compilers and no one will know what the set is and these
>>>> bugs will become 'unfixable' and a continual chore of churn.
>>>> It will be something we should address as we move *official*
>>>> compilers.
>>>>
>>>> In fact the warning you want to suppress is one I just got rid of (the
>>>> suppression)
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
>>>> I don't think we want to add it back unless the *official* compilers
>>>> object
>>>> .. I am sure that official list is documented somewhere.
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I've fixed several warnings when we build OpenJDK with GCC 6 in
>>>>> JDK-8160294.
>>>>> However, I encountered shift-negative-value warnings at jdhuff.c
>>>>> on my
>>>>> Fedora 24 (GCC 6.1.1):
>>>>> --
>>>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
>>>>>
>>>>>
>>>>> warning: left shift of negative value [-Wshift-negative-value]
>>>&g

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

[Philip Race]

On 8/24/16, 5:31 AM, Yasumasa Suenaga wrote:
> Hi Erik, Phil,
>
> Thank you for replying.
> I understand background of JDK-8074827.
>
>> In this particular case is shift-negative-value a new warning in GCC 6?
>
> Yes, this feature is implemented GCC 6:
> https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/

I see. I tracked down the commit so yes, this seems to be the case.
>
> BTW, why is libjavajpeg only enabled these warnings?
> For example, liblcms is disabled format-nonliteral, type-limits, and
> misleading-indentation.

We only disable the warnings that are observed .. not all warnings else
we might as
well turn off warnings completely.
>
> I agree compiler warnings is very useful to fix. However, I think a
> part of source of libjavajpeg is third-party (developed by Independent
> JPEG Group).
> According to [1], warnings in this library should be suppressed.

Yes. FWIW this is the most stable 3rd party library we have - by a long
way -
so it *could* be argued that tweaking it isn't likely to get lost any
time soon
but I'd still prefer to keep the source as it came.
>
> If all binaries which are included in JDK/JRE should be enabled all
> compiler warnings, I think LCMS and any other libraries should be fixed.

Well you would *have* to get upstream to resolve it.
But it is whack-a-mole. As you have discovered new compilers
generate new warnings .. and it is not monotonic either.

-phil.
>
> Which policy is correct?
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004495.html
>
>
> On 2016/08/24 18:48, Erik Joelsson wrote:
>> Hello,
>>
>>
>> On 2016-08-23 18:12, Phil Race wrote:
>>> On 08/23/2016 08:47 AM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> I do agree that maintaining the list of disabled warnings will be
>>>> impossible unless we have a structured way of tracking for which
>>>> compiler versions we disable what. Ideally we should be able to easily
>>>> add conditions for when certain warnings should be disabled. We are
>>>> unfortunately lacking that today and at least I don't have the
>>>> bandwidth to fix that anytime soon.
>>>>
>>>> The official compilers are only really official for Oracle. The
>>>> OpenJDK can (and should) be buildable with a much wider range of
>>>> compiler versions.
>>> I agree there. This is fortunately not an "unbuildable" situation.
>>> The only other option I can think of which may or may not be palatable
>>> is to explicitly
>>> check the compiler version and add that disabled warning only for that
>>> exact compiler version.
>>> There'd still be some maintenance as that compiler version became
>>> either
>>> official .. or obsolete ..
>>>
>>> Is there precedent (or any kind of support) for that ?
>> What I had in mind was a structured way of adding conditionals for
>> some kind of ranges of compiler versions, or at least something like
>> 6.*, or "greater than 4.9.3". It's pretty simple today to check for
>> exact compiler versions but then we end up with a lot of changes when
>> minor versions are bumped. I don't think that would be worth it.
>>
>> In this particular 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+.
>>
>> /Erik
>>> -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.
>>>>
>>>> So for now at least, I think Phil is right.
>>>>
>>>> /Erik
>>>>
>>>> On 2016-08-23 17:11, Philip Race wrote:
>>>>> 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 warnings for a whole range
>>>>> of compilers and no one will know what the set is and these
>>>>> bugs will

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

[Philip Race]

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 warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official* compilers.

In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers object
.. I am sure that official list is documented somewhere.

-phil.


On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I've fixed several warnings when we build OpenJDK with GCC 6 in
> JDK-8160294.
> However, I encountered shift-negative-value warnings at jdhuff.c on my
> Fedora 24 (GCC 6.1.1):
> --
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> :
> --
>
> I think these warnings are available from JDK-8074827.
> This issue enables warnings to fix in the source code.
> However, in review of JDK-8160294, I heared that warnings in IJG JPEG
> library should just be suppressed:
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
>
>
> So I think they should be suppressed and we should fix as below:
> --
> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
> @@ -490,7 +490,7 @@
> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
> $(LIBJAVA_HEADER_FLAGS) \
> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
> - DISABLED_WARNINGS_gcc := clobbered, \
> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> --
>
> If it is correct, I file it to JBS and upload webrev.
> Do you think about it?
>
>
> Thanks,
>
> Yasumasa
>
>