Hello.
Please review fix for jdk11.
Bug: https://bugs.openjdk.java.net/browse/JDK-8200149
Webrev can be found at: http://cr.openjdk.java.net/~serb/8200149/webrev.00
CSR: https://bugs.openjdk.java.net/browse/JDK-8200190
The client code has a "com.sun.awt.AWTUtilities" class which at some
point i
On 2018-03-23 17:05, mandy chung wrote:
This is a very good change and no more mapfile to maintain!!
Thank you!
Please do file JBS issues for the component teams to clean up their
exports.
I have now filed:
https://bugs.openjdk.java.net/browse/JDK-8200191 -- for java.base
https://bugs.ope
On 2018-03-23 18:24, Volker Simonis wrote:
Hi Magnus,
thanks for addressing this long standing issue! I haven't looked at
the changes, but just want to share some general and historical notes:
- Compiling with "-fvisibility=hidden" which hides all symbols expect
the ones explicitly exported wit
On 2018-03-23 18:33, Phil Race wrote:
There are a lot of changes in the desktop libraries.
Well, yes and no. While there are multiple touched files, the resulting
native shared libraries that are built have very minimal changes in
them. (That's the view point from the build guy, you know :))
On 2018-03-23 19:01, Phil Race wrote:
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html
The variable definitions here are now misaligned.
No, they are not. That's just an artifact of webrev, which
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/src/java.desktop/share/native/libmlib_image/mlib_image_proto.h.udiff.html
The variable definitions here are now misaligned.
..and added 2d-dev since many of these native changes are in 2d.
-phil.
On 03/23/2018 10:33 AM, Ph
There are a lot of changes in the desktop libraries.
Doing mach5 tier1/2/3 testing is not nearly sufficient to cover those since
only tier3 has any UI tests and it barely uses anything that's touched here.
So since testing seems to be wise, then I think you should do a
jtreg desktop group run on L
Hi Magnus,
thanks for addressing this long standing issue! I haven't looked at
the changes, but just want to share some general and historical notes:
- Compiling with "-fvisibility=hidden" which hides all symbols expect
the ones explicitly exported with
"__attribute__((visibility("default")))" ha
This is a very good change and no more mapfile to maintain!!
Please do file JBS issues for the component teams to clean up their
exports.
Mandy
On 3/23/18 7:30 AM, Erik Joelsson wrote:
I have looked at the build changes and they look good.
Will you file followups for each component team to
On 23/03/2018 15:15, Magnus Ihse Bursie wrote:
:
Very much so, yes. I've found a lot of dubious exports, everything from global
variables (yuck!) to functions that does not seem to be used anymore, to lots
of strange exports.
The changes looks good to me and I think we should follow this up wit
> 23 mars 2018 kl. 15:45 skrev Alan Bateman :
>
>> On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
>> With modern compilers, we can use compiler directives (such as
>> _attribute__((visibility("default"))), or __declspec(dllexport)) to control
>> symbol visibility, directly in the source code. T
On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so w
I have looked at the build changes and they look good.
Will you file followups for each component team to look over their
exported symbols, at least for the libraries with $(EXPORT_ALL_SYMBOLS)?
It sure looks like there is some technical debt laying around here.
/Erik
On 2018-03-23 06:56, M
With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so we had to resort to
using mapfiles (also known a
Just a gentle reminder. Requesting again to review the changes.
Thanks,
Dipak
From: Shashidhara Veerabhadraiah
Sent: 20 March 2018 09:26
To: Patrick Chen ; Dipak Kumar
Cc: awt-dev@openjdk.java.net
Subject: Re: [8u-backport] Review request for 8195738 : scroll
poistion in ScrollPane is
15 matches
Mail list logo
