Hello,
I am working on a port of DragonBox to Java. If there is interest in
contributing this is most welcome.
Suminda
On Fri, 5 Feb 2021 at 21:51, Raffaello Giulietti <
raffaello.giulie...@gmail.com> wrote:
> Hello,
>
> as a reminder, a Java implementation of Schubfach [1] intended to
> replac
A quick fix to remove isStandalone's dependency on pretty-print.
-
Commit messages:
- 8261209: isStandalone property: remove dependency on pretty-print
Changes: https://git.openjdk.java.net/jdk/pull/2442/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2442&range=00
Is
On Fri, 27 Nov 2020 18:50:19 GMT, Ivan Šipka wrote:
> @iignatev could you please review? Thank you.
>
> note to self:
> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java
> test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java
> test/jdk/java/lang/Thread/
> Could I get the following change reviewed please? It fixes a problem (in
> JEP380) on Windows where some file operations on Unix domain sockets were not
> working and led to the feature being disabled on Windows 2019 Server in JDK
> 16. So, the fix re-enables the feature on all versions of Win
When a class is compiled against a version of an annotation that is later
loaded in an incompatible manner where an enum-typed member is changed into an
annotation or vice versa, the reflection API currently throws a
`NullPointerException` upon accessing the member. Instead an
`AnnotationTypeMi
On Fri, 5 Feb 2021 21:09:37 GMT, Alex Menkov wrote:
> JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
> The fix un-problemlists RemovingUnixDomainSocketTest and changes
> serviceability tests to use
> OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings inste
On Thu, 4 Feb 2021 18:30:57 GMT, Joe Darcy wrote:
>> Recent revisions of the IEEE 754 floating-point standard have added guidance
>> on how typical math library methods (sin, cos, tan, etc.) should behave in
>> terms of their general quality of implementation as well as on special
>> values.
>
JDK-8258917 fixed non-java launchers ("wrong launcher" VM warning for tools).
The fix un-problemlists RemovingUnixDomainSocketTest and changes serviceability
tests to use OutputAnalyzer.stderrShouldBeEmptyIgnoreDeprecatedWarnings instead
of stderrShouldBeEmptyIgnoreVMWarnings
-
Comm
On Fri, 29 Jan 2021 21:33:40 GMT, Alexey Semenyuk wrote:
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++ cod
On Thu, 4 Feb 2021 22:17:12 GMT, Naoto Sato wrote:
> Please review this fix. The bug was revealed while porting CLDR v39 into the
> JDK, where they switch the Norwegian Bokmal from "nb" to "no". [1] Some
> regression tests started failing with it because COMPAT provider's "nb"
> resource was u
On Fri, 5 Feb 2021 17:44:21 GMT, Alexey Semenyuk wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of C++
On Fri, 5 Feb 2021 17:11:24 GMT, Stuart Marks wrote:
>> A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).
>> This is an enhancement to update jlink's usage of `Collections.toList()` to
>> `Stream.toList()`.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHe
On Fri, 5 Feb 2021 17:44:21 GMT, Alexey Semenyuk wrote:
>> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>>
>> The fix splits Linux app launcher in app launcher and launcher shared lib.
>> App launcher is pure C and doesn't have C++ code. App launcher lib
>> incorporates bulk of C++
On Mon, 1 Feb 2021 18:35:54 GMT, Alexey Semenyuk wrote:
>>> "common" was perfectly enough until this change. Unfortunately we cant just
>>> drop new C sources in "common" dir because we don't want them to be
>>> compiled with g++. That is why need new common directory
>>> (applauncherlibcommon
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++ code from app launcher.
> At startup app launcher loads launc
On Thu, 4 Feb 2021 22:45:10 GMT, Ian Graves wrote:
> A subtask [JDK-8260559](https://bugs.openjdk.java.net/browse/JDK-8260559).
> This is an enhancement to update jlink's usage of `Collections.toList()` to
> `Stream.toList()`.
Aside from the simplification issues, the Collectors.toList() =>
S
On Tue, 2 Feb 2021 18:35:51 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>
>> 91: CPU_MARVELL
Hello,
as a reminder, a Java implementation of Schubfach [1] intended to
replace the current slow and expensive OpenJDK (Double|Float)::toString
algorithm has been discussed, presented and contributed to this mailing
list in several posts. The last implementation is available in pre-Skara
web
On Wed, 3 Feb 2021 23:29:30 GMT, Gerard Ziemski wrote:
>> using ` ```c `
>> https://docs.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks
>>
>> I was wrong about `SIGFPE` / `EXC_MASK_ARITHMETIC`, it's used on i386,
>> x86_64:
>> https://github.com/openjdk/jdk/blob/2
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
On Fri, 5 Feb 2021 03:00:05 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comments and copyright.
>
> src/hotspot/share/classfile/javaClasses.cpp line 4415:
>
>> 4413:
>> 4414: // Thi
On Fri, 5 Feb 2021 12:26:27 GMT, Anton Kozlov wrote:
>> Marked as reviewed by ihse (Reviewer).
>
>> I haven't got a MacOS AArch64 system right now. Is it possible to
>> enable W^X in Linux in order to kick the tyres?
>
> I've just got rid of asserts that fired on Linux sometime :) As for W^X lik
Hello,
Currently in jdk/internal/vm/VMSupport.java , we create a JarFile without a
related finally clause or try with resources. That should better be changed.
See also the Sonar check result :
https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&open=AXcqM8zf8sPJZZzON5qG&resolved=
I have been reading previous threads, the original bug request, and exploring
the javadoc and implementation of toList() on Stream in JDK 16. I don’t want to
waste time rehashing previous discussions, but I want to understand and
prioritize the motivation of this change, and propose what I b
On 2/5/21 4:51 AM, Magnus Ihse Bursie wrote:
On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote:
Anton Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
support macos_aarch64 in hsdis
make/autoconf/flags.m4 line 140:
138:
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++ code from app launcher.
> At startup app launcher loads launc
> Fix for https://bugs.openjdk.java.net/browse/JDK-8254702
>
> The fix splits Linux app launcher in app launcher and launcher shared lib.
> App launcher is pure C and doesn't have C++ code. App launcher lib
> incorporates bulk of C++ code from app launcher.
> At startup app launcher loads launc
Thanks Don for a detailed email. I concur with your reservations and
worries.
My biggest worry is that the unmodifiable nature of return type while
giving no compile time indications leave issues to be encountered at
runtime.
Now it is up for argument that there should be tests which fail and these
On Mon, 25 Jan 2021 22:48:50 GMT, Chris Plummer wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Refactor CDS disabling
>> - Redo builsys support for aarch64-darwin
>
> src/jdk.hotspot.agent/macosx/native/libsapr
> Please review the implementation of JEP 391: macOS/AArch64 Port.
>
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
> windows/aarch64.
>
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks
> JDK-8253817, JDK-8253818)
On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote:
> Could I get the following change reviewed please? It fixes a problem (in
> JEP380) on Windows where some file operations on Unix domain sockets were not
> working and led to the feature being disabled on Windows 2019 Server in JDK
> 16.
On Fri, 5 Feb 2021 09:57:54 GMT, Magnus Ihse Bursie wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>
On Fri, 5 Feb 2021 12:03:30 GMT, Daniel Fuchs wrote:
>> Could I get the following change reviewed please? It fixes a problem (in
>> JEP380) on Windows where some file operations on Unix domain sockets were
>> not working and led to the feature being disabled on Windows 2019 Server in
>> JDK 16
On Fri, 5 Feb 2021 09:52:11 GMT, Michael McMahon wrote:
> Could I get the following change reviewed please? It fixes a problem (in
> JEP380) on Windows where some file operations on Unix domain sockets were not
> working and led to the feature being disabled on Windows 2019 Server in JDK
> 16.
On Fri, 5 Feb 2021 09:49:11 GMT, Andrew Haley wrote:
>> I reviewed bsd_aarch64.cpp digging bit deeper and left some comments.
>
>> > Umm, so how does patching work? We don't even know if other threads are
>> > executing the code we need to patch.
>>
>> I thought java can handle that scenario in
On Wed, 3 Feb 2021 20:01:15 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
Could I get the following change reviewed please? It fixes a problem (in
JEP380) on Windows where some file operations on Unix domain sockets were not
working and led to the feature being disabled on Windows 2019 Server in JDK 16.
So, the fix re-enables the feature on all versions of Windows tha
On Tue, 2 Feb 2021 21:20:52 GMT, Daniel D. Daugherty wrote:
>> Anton Kozlov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> support macos_aarch64 in hsdis
>
> make/autoconf/flags.m4 line 140:
>
>> 138: else
>> 139: MACOSX_VERS
On Thu, 4 Feb 2021 23:05:56 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Thu, 4 Feb 2021 14:23:56 GMT, Claes Redestad wrote:
> This patch resolves a potential memory leak in
> Java_java_lang_ClassLoader_defineClass0
>
> I've not figured a good way to write a regression test. A crude way to
> manually verify the leak and the fix is provided by the added microbenc
On Thu, 4 Feb 2021 17:07:01 GMT, Thomas Stuefe wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dial back cleanups and focus patch on the bug at hand
>
> Looks good!
@tstuefe, @ChrisHegarty, @mlchung - thanks for
On Thu, 4 Feb 2021 21:04:51 GMT, Liam Miller-Cushon wrote:
>> Thanks, I was missing context here. I now realize this patch is fixing a bug
>> related to
>> [JDK-8254023](https://bugs.openjdk.java.net/browse/JDK-8254023)--when the
>> handling of annotations without `@Target` was updated to allo
> Please review this fix to add `ElementType.MODULE` to the default list of
> annotation targets, to allow annotations without an explicit `@Target` to be
> used on module declarations.
Liam Miller-Cushon has refreshed the contents of this pull request, and
previous commits have been removed. T
43 matches
Mail list logo
