On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
On Tue, 12 Oct 2021 20:39:13 GMT, Andrey Turbanov wrote:
>> StringBuffer is a legacy synchronized class. There are more modern
>> alternatives which perform better:
>> 1. Plain String concatenation should be preferred
>> 2. StringBuilder is a direct replacement to StringBuffer which generally
>
On Tue, 12 Oct 2021 18:11:56 GMT, Cheng Jin wrote:
> Just tried with `System.load()` but still ended up with pretty much the same
> failure given both of them eventually invokes `ClassLoader.loadLibrary` to
> load the library in which case there is no big difference at this point.
Yes and no.
> StringBuffer is a legacy synchronized class. There are more modern
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have
> better performance
>
> In [JDK-8264029](https://bugs.ope
On Tue, 12 Oct 2021 20:33:20 GMT, Naoto Sato wrote:
>> reverted changes in this spec.
>
> Did you modify the PR? I am unable to locate the revert.
Oops. Forgot to push
-
PR: https://git.openjdk.java.net/jdk/pull/5432
On Mon, 11 Oct 2021 21:05:46 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/java/lang/Character.java line 123:
>>
>>> 121: * than U+ are called supplementary characters. The Java
>>> 122: * platform uses the UTF-16 representation in {@code char} arrays and
>>> 123: * in the {
On Tue, 15 Jun 2021 12:15:11 GMT, Сергей Цыпанов wrote:
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be replaced with Long.hashCode(long) as it
>
> -
On Tue, 12 Oct 2021 03:54:14 GMT, Anthony Scarpino
wrote:
>
>
> The changes look good
Thanks much for review! Could you please also review the CSR as well
https://bugs.openjdk.java.net/browse/JDK-8274174?
-
PR: https://git.openjdk.java.net/jdk/pull/5569
On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
On Tue, 12 Oct 2021 15:24:41 GMT, Cheng Jin wrote:
> I tried to load `libc.a` and `libc` this way but neither of them works on AIX.
Sorry - what I meant is - `System::load`, which accepts a full path and
extension. E.g.
System.load("/usr/lib/libc.a");
-
PR: https://git.openjdk.j
On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.jav
This patch improves code coverage on the following classes:
-
com.sun.org.apache.xml.internal.security.algorithms.implementations.IntegrityHmac
- com.sun.org.apache.xml.internal.security.utils.ElementProxy
- com.sun.org.apache.xml.internal.security.keys.KeyInfo
The new tests exercise code blocks
On Tue, 12 Oct 2021 11:16:51 GMT, Maurizio Cimadamore
wrote:
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.jav
This PR contains the API and implementation changes for JEP-419 [1]. A more
detailed description of such changes, to avoid repetitions during the review
process, is included as a separate comment.
[1] - https://openjdk.java.net/jeps/419
-
Commit messages:
- Fix issues with Aarch64
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
> -
On Tue, 12 Oct 2021 15:04:02 GMT, Maurizio Cimadamore
wrote:
> Is libc.a loadable on AIX (e.g. with System.loadLibrary) ?
I tried to load `libc.a` and `libc` this way but neither of them works on AIX.
e.g.
public class StdLibTest {
private static CLinker clinker = CLinker.getInstance()
On Fri, 8 Oct 2021 21:45:21 GMT, Cheng Jin wrote:
> That's what I thought to be the only way around but might need to figure out
> the specifics on AIX.
Is `libc.a` loadable on AIX (e.g. with System.loadLibrary) ? (Sorry I don't
have a machine to test readily available). If so, we might just l
On Sat, 2 Oct 2021 20:05:37 GMT, Andrey Turbanov wrote:
> Cleanup unnecessary String.valueOf calls (and similar) when conversion will
> happen implicitly anyway
LGTM
Hi Andrey - I will sponsor this change.
-
Marked as reviewed by dfuchs (Reviewer).
PR: https://git.openjdk.java.n
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long) as i
22 matches
Mail list logo
