Hi Thomas,
The TLS cipher suites have been decoupled from the ChaCha20/Poly1305 JEP
because of the changes in the new handshake design [1] for our JSSE
provider. From a programmatic/schedule perspective, it made more sense
to get the algorithms in ahead of the TLS cipher suites and then add t
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
Note: I am not a Reviewer. This is not a Review.
I took a look at some of the files that I was working in during my
extension development. I just have a few minor comments:
TransportContext.java, line 428: It's not clear why the outbound
direction is closed here. Consider adding more comments
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
Ping.
Can I please have a review for this test fix?
Thanks in advance!
Ivan
On 3/6/18 1:01 PM, Ivan Gerasimov wrote:
Hello!
The regression test SignatureLength.java was seen to fail on some
Solaris systems.
This is because signature verifier from SunPKCS11-Solaris provider
doesn't alway
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
16 matches
Mail list logo
