There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
in Javadoc.
In detail:
src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
Unnecessary import
src/java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java:
typo
On Tue, 15 Sep 2020 07:47:54 GMT, Christoph Langer wrote:
> There are some little flaws in LdapDNSProvider and auxilliary classes, mostly
> in Javadoc.
>
> In detail:
> src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java:
> Unnecessary import
>
On Sat, 21 Nov 2020 23:21:15 GMT, Christoph Langer wrote:
>> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
>> leaking socket resources after JDK-8224829.
>>
>> The close method calls duplexCloseOutput() and duplexCloseInput(). In case
&
There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
leaking socket resources after JDK-8224829.
The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
an exception in any of these methods, the call to closeSocket() is bypassed,
and the underlying
On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer wrote:
> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
> leaking socket resources after JDK-8224829.
>
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
> an e
On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer wrote:
> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
> leaking socket resources after JDK-8224829.
>
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
> an e
On Wed, 2 Dec 2020 18:01:04 GMT, Xue-Lei Andrew Fan wrote:
>> Christoph Langer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Small test improvement
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSoc
The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on
AIX.
It tests that when a DNS server is unreachable it fails quickly with a
PortUnreachableException due to ICMP Destination Unreachable packets received
and not having to wait for the full timeout interval.
On Wed, 18 Nov 2020 07:46:33 GMT, Matthias Baesken wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains one commit:
>>
>> Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java
On Mon, 16 Nov 2020 22:28:08 GMT, Christoph Langer wrote:
> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on
> AIX.
>
> It tests that when a DNS server is unreachable it fails quickly with a
> PortUnreachableException due to ICMP Destination Unre
On Tue, 17 Nov 2020 03:33:58 GMT, Jie Fu wrote:
>> Christoph Langer has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains one commit:
>>
>> Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not
rivate
> exclude list for AIX. I suggest this test update to be the final solution.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains one commit:
Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not
;
> Secondly, I'm proposing to improve exception handling a bit. So in case
> there's an IOException on the path of duplexClose, it is caught and logged.
> But the real close moves to the finally block since it should be done
> unconditionally.
Christoph Langer has updated the p
;
> Secondly, I'm proposing to improve exception handling a bit. So in case
> there's an IOException on the path of duplexClose, it is caught and logged.
> But the real close moves to the finally block since it should be done
> unconditionally.
Christoph Langer has updated the pull r
On Fri, 4 Jun 2021 14:10:20 GMT, Matthias Baesken wrote:
>> Hello, please review this small Sonar finding.
>> Sonar reports a potential NULL pointer dereference here :
>> https://sonarcloud.io/project/issues?id=shipilev_jdk=c=AXck8CPLBBG2CXpcnh_z=false=MAJOR=BUG
>> "Access to field 'item'
On Fri, 5 Feb 2021 15:23:59 GMT, Matthias Baesken wrote:
> 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 :
>
>
On Mon, 8 Feb 2021 13:41:17 GMT, Alan Bateman wrote:
>> 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 :
>>
>>
On Tue, 9 Feb 2021 08:30:54 GMT, Matthias Baesken wrote:
>> 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 :
>>
>>
On Thu, 25 Feb 2021 15:40:00 GMT, Matthias Baesken wrote:
>> Sonar reports a finding in args.c, where a file check is done .
>> Stat performs a check on file, and later fopen is called on the file .
>>
>> The coding could be slightly rewritten so that the potential issue is
>> removed (however
On Thu, 25 Feb 2021 16:39:25 GMT, Matthias Baesken wrote:
>> src/java.base/share/native/libjli/args.c line 378:
>>
>>> 376: if (st.st_size > MAX_ARGF_SIZE) {
>>> 377: JLI_ReportMessage(CFG_ERROR10, MAX_ARGF_SIZE);
>>> 378: reportAndExit(NULL, NULL);
>>
>> This
On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken wrote:
>> Sonar reports a finding in args.c, where a file check is done .
>> Stat performs a check on file, and later fopen is called on the file .
>>
>> The coding could be slightly rewritten so that the potential issue is
>> removed (however
On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken wrote:
> Sonar reports a finding in args.c, where a file check is done .
> Stat performs a check on file, and later fopen is called on the file :
> https://sonarcloud.io/project/issues?id=shipilev_jdk=c=AXck8CL0BBG2CXpcnhtM=false=VULNERABILITY
>
On Tue, 23 Feb 2021 14:23:59 GMT, Matthias Baesken wrote:
> > This looks good in general. Do you know whether there's a jtreg test that
> > stresses arg files?
>
> There are tests dealing with args files at test/jdk/tools/launcher/ , e.g.
> there is test/jdk/tools/launcher/ArgsFileTest.java .
On Tue, 23 Feb 2021 14:30:17 GMT, Matthias Baesken wrote:
>> Sonar reports a finding in args.c, where a file check is done .
>> Stat performs a check on file, and later fopen is called on the file :
>>
On Tue, 9 Feb 2021 14:33:22 GMT, Matthias Baesken wrote:
> JDK-8261422: Adjust problematic String.format calls in
> jdk/internal/util/Preconditions.java outOfBoundsMessage
As we're potentially formatting any "Number" type here, theoretically floats
could be passed which would result in an
This is a proposal to relax the test and throw a SkippedException in such
> cases.
Christoph Langer has updated the pull request incrementally with one additional
commit since the last revision:
Update copyright year
-
Changes:
- all: https://git.openjdk.java.net/jdk/
On Mon, 15 Feb 2021 13:27:36 GMT, Christoph Langer wrote:
> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
> still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
> Big Sur 11.2.1, and where the JDK was built wit
After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
Big Sur 11.2.1, and where the JDK was built with xcode < 12.
java.lang.Error: 11.2 != 11.2.1
This is a proposal to relax the test and throw
On Mon, 15 Feb 2021 13:27:36 GMT, Christoph Langer wrote:
> After the fix for JDK-8253702, the test java/lang/System/OsVersionTest.java
> still fails on BigSur versions that have a patch version (> 1), e.g. on macOS
> Big Sur 11.2.1, and where the JDK was built wit
On Mon, 15 Feb 2021 14:06:31 GMT, Roger Riggs wrote:
> Given the lack of veracity from the os...
> Perhaps check that `swVersion.startsWith(osVersion) == true` (if the whole
> string doesn't match).
>
> I'm hopeful that when JDK 17 is released the toolchain has been upgraded and
> this patch
On Thu, 11 Feb 2021 19:30:02 GMT, Kevin Rushforth wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> optimize case of 10.16 and SYSTEM_VERSION_COMPAT is set
>
> Looks good.
Thanks for the fix! This is probably the
This is a proposal to relax the test and throw a SkippedException in such
> cases.
Christoph Langer has updated the pull request incrementally with one additional
commit since the last revision:
Simplify the coding, use startsWith comparison
-
Changes:
- all: https://git.openjd
On Fri, 19 Feb 2021 10:35:21 GMT, Christoph Langer wrote:
> The fix for JDK-8261753 introduced a ',' after the copyright years which is
> not the expected format for SAP copyrights.
This pull request has now been integrated.
Changeset: efbaedeb
Author:Christoph Langer
URL:
The fix for JDK-8261753 introduced a ',' after the copyright years which is not
the expected format for SAP copyrights.
-
Commit messages:
- JDK-8262018
Changes: https://git.openjdk.java.net/jdk/pull/2642/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2642=00
Issue:
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
I have added this to our internal
On Wed, 22 Sep 2021 17:41:18 GMT, Roger Riggs wrote:
>> The Mac OS specific code to determine the os.version property in
>> java_props_macosx.c is updated
>> to replace the code extracting the version from the SystemVersion.plist by
>> reading the version using t\
>> he hidden link:
>
> Roger
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote:
> The OS detection code of the JDK/JVM should recognize the new Windows 11. For
> details see :
>
> https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
> OS build number is : 22000.194 for 21H2 (original
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the
On Wed, 17 Nov 2021 18:48:14 GMT, Volker Simonis wrote:
> In JDK 9, function objects implemented as anonymous inner classes in
> java.util.regex.Pattern have been replaced by lambda functions (see
> [JDK-8151481](https://bugs.openjdk.java.net/browse/JDK-8151481)). This led to
> a significant
On Wed, 16 Feb 2022 09:30:46 GMT, Volker Simonis wrote:
> Currently, `InflaterInputStream::read()` first does a native call to the
> underlying zlib `inflate()` function and only afterwards checks if the
> inflater requires input (i.e. `Inflater::needsInput()`) or has finished
> inflating
On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen wrote:
> Hi all,
>
> This PR addresses the performance issue that is described in JDK-8287162.
>
> With this fix, the ZipFileSystem methods: initOwner, initGroup, and
> initPermissions will not be invoked unless
On Wed, 11 May 2022 19:20:15 GMT, Lance Andersen wrote:
>> This augments the ZipException upon rejecting a Zip File containing entry
>> names with "." or ".." elements.
>>
>> It furthermore tries to clean up & compact the logic for detecting "." and
>> ".." and it adds a method
On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer wrote:
> This augments the ZipException upon rejecting a Zip File containing entry
> names with "." or ".." elements.
>
> It furthermore tries to clean up & compact the logic for detecting ".&qu
On Thu, 12 May 2022 15:07:29 GMT, Sean Mullan wrote:
> A more descriptive title for the bug report would be helpful.
Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/8655
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to
On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen wrote:
> > > @LanceAndersen @AlanBateman do you think adding the entry name in the
> > > exception in ZipFileSystem is ok? If so, should it maybe go into a
> > > different patch?
> >
> >
> > It should be okay as this is the name of an entry in
This augments the ZipException upon rejecting a Zip File containing entry names
with "." or ".." elements.
It furthermore tries to clean up & compact the logic for detecting "." and ".."
and it adds a method IndexNode:nameAsString() to return the node name as a
String.
-
Commit
On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer wrote:
> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors
> when the classpath
> contains jar files with . or .. in its name. The error message, however, does
> not help to find
> the culprit. This co
After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors
when the classpath
contains jar files with . or .. in its name. The error message, however, does
not help to find
the culprit. This could be improved.
-
Commit messages:
- JDK-8286444
Changes:
50 matches
Mail list logo
