On 24/08/2021 07:50, Andrey Turbanov wrote:
Hello.
I found a few internal classes in the JDK codebase which don't have
proper javadoc, but have dangling javadoc-like comments.
Dangling Javadoc comments are ignored by the javadoc tool and IDE.
Perhaps it was intentional to not add proper javadoc t
On Fri, 20 Aug 2021 00:09:01 GMT, Calvin Cheung wrote:
>> Please review this change for adding a `jlink` command line option
>> `--generate-cds-archive` for generating CDS archives as a post processing
>> step during the creation of a custom JDK image.
>>
>> Details can be found in the corresp
On 23/08/2021 05:45, David Holmes wrote:
:
@wangweij there are many tests that can call setSecurityManager() and will
presumably need to be fixed before this switch can be applied. And all testing
will need to be updated to require jtreg 6.1 (which no longer uses the SM) once
it is released.
On Sat, 21 Aug 2021 11:23:54 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 128:
>>
>>> 126: * null
>>> 127: * None
>>> 128: * Always throws {@code UnsupportedOperationException}
>>
>> Not sure "Always" is needed, could just be "Throws UOE"
>
On 20/08/2021 17:03, Laird Nelson wrote:
On Fri, Aug 20, 2021 at 3:13 AM Alan Bateman <mailto:alan.bate...@oracle.com>> wrote:
I think you are asking for an overload that specifies a class
literal as
a type token to avoid an explicit cast at the use-sites.
Yes, tha
On 19/08/2021 15:32, Laird Nelson wrote:
:
To recap in brief: being able to do:
Frob frob = someNamingContext.lookup("frob", Frob.class);
would be very convenient, e.g. via something like:
// Proposed new default method in javax.naming.Context
default T lookup(Name name, Class type)
On 19/08/2021 22:52, Alan Snyder wrote:
I’ve been looking for some specification of what happens when a file request is
made using a path that is too long (whatever that means to the underlying
system).
I have not found one.
Is there one?
My opinion is that silent truncation should not happen.
On 19/08/2021 17:10, Igor Ignatyev wrote:
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
On 18/08/2021 22:44, Naoto Sato wrote:
On 8/18/21 2:03 PM, Simon Nash wrote:
I am the developer of a fairly large application that uses file I/O
extensively. In most cases, the charset should be UTF-8 and I have
used an explicit charset parameter on all method invocations where
this applies. I
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
Marked as reviewed by alanb (Reviewer).
---
On Tue, 17 Aug 2021 16:03:47 GMT, Brian Burkhalter wrote:
>> This change proposes to exclude `/run/user` mounts from the test when run on
>> Linux as they can "disappear" while the test is running.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit sinc
On Tue, 17 Aug 2021 02:48:35 GMT, Brian Burkhalter wrote:
> This change proposes to exclude `/run/user` mounts from the test when run on
> Linux as they can "disappear" while the test is running.
Marked as reviewed by alanb (Reviewer).
The change looks okay but I suspect a similar change will
On Sun, 15 Aug 2021 16:51:59 GMT, Roman Kennke wrote:
> Having followed both #4263 and this PR from the sidelines, may I ask why for
> #4263 much more rigorous testing is asked but not here? E.g. test for NPE,
> random-sized files/buffers, random position, return value, comprehensive JMH
> tes
On Fri, 13 Aug 2021 19:20:48 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On 15/08/2021 14:29, Brian Goetz wrote:
For the third time: This discussion illustrates why the PR was
premature; the design was not agreed upon first. High-level design
discussions (i.e., "is this a good design", "is this a good idea at
all", "are we solving the right problem", "does it need
On Fri, 13 Aug 2021 19:20:48 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On Fri, 13 Aug 2021 14:53:45 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On Thu, 12 Aug 2021 19:27:42 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the fix for JDK-8263940 to address an issues when the default
>> file system provider is packaged as JAR file on class path.
>>
>> The patch also addresses the `@bug` line for JDK-8271194
>>
>> Mach5 Tier1
On Fri, 13 Aug 2021 14:32:41 GMT, Roman Kennke wrote:
> Is this what you have been asking @mkarg in #4263 to do? Optimize
> transferTo() only for FileInputStream? Would it interfere with #4263?
#4263 is the input stream returned by Channels.newInputStream where the source
may be a FileChannel
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed i
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On Thu, 12 Aug 2021 21:07:53 GMT, Brian Burkhalter wrote:
>> Please consider this request to add an override
>> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
>> if the parameter is a `FileOutputStream`.
>
> Brian Burkhalter has updated the pull request incremental
On Thu, 12 Aug 2021 01:16:04 GMT, Brian Burkhalter wrote:
> Please consider this request to add an override
> `java.io.FileInputStream.transferTo(OutputStream)` with improved performance
> if the parameter is a `FileOutputStream`.
Changes requested by alanb (Reviewer).
src/java.base/share/cla
On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed i
On Wed, 11 Aug 2021 21:40:52 GMT, Claes Redestad wrote:
>> In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to
>> avoid potentially getting two bounds checks in the UTF-16 case. Problem is
>> this optimization cause a regression since `StringUTF16.charAt(..)` checks
>> `
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("U
On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote:
> Yes, while I don't know exactly which changes resolved JDK-6764325, it's
> clear from the microbenchmarks added for #2102 that it's no longer an issue -
> at least not in the mainline.
Thanks for checking and for closing that issue.
--
On Wed, 11 Aug 2021 14:26:32 GMT, Claes Redestad wrote:
> In #4738 we removed the `checkIndex(value, count)` call in `ASB.charAt` to
> avoid potentially getting two bounds checks in the UTF-16 case. Problem is
> this optimization cause a regression since `StringUTF16.charAt(..)` checks
> `inde
On Mon, 9 Aug 2021 18:10:52 GMT, Alan Bateman wrote:
> I think I fixed all requested changes. Anymore comments on this PR?
I've looked through the latest revision. Is here any way that we could drop
most of the changes to ChannelInputStream and focus on one or two specific
cases? I&
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("U
On 10/08/2021 07:58, Luke Hutchison wrote:
On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison
wrote:
Could a getURLClassPath() method please be added to BuiltInClassLoader?
For security reasons, the getURLClassPath() method should return a copy of
ucp, not the reference to ucp, to prevent the c
On Sat, 7 Aug 2021 06:45:21 GMT, Markus KARG
wrote:
> I think I fixed all requested changes. Anymore comments on this PR?
I hope to get to this soon.
-
PR: https://git.openjdk.java.net/jdk/pull/4263
On Fri, 6 Aug 2021 13:32:00 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList
> java/nio/channels/FileChannel/Transfer2GPlus.java on linux-aarch64
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5032
On Thu, 5 Aug 2021 14:06:17 GMT, Thomas Stuefe wrote:
>> On Unix systems, the JDK has always relied on the Runtime.exec
>> implementation to close the file descriptors. On Windows the inheritance has
>> to be disabled in the parent. So if the gtest launcher is forking directly
>> then we may h
On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial fix which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8271208?
>
> Ran `make docs-image` locally and generated the new javadocs and the change
> looks fine.
Marked as review
On Wed, 4 Aug 2021 17:04:38 GMT, Thomas Stuefe wrote:
>> src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41:
>>
>>> 39: */
>>> 40: jint osSupport::openReadOnly(const char *path) {
>>> 41: return ::open(path, O_CLOEXEC);
>>
>> This is okay but I think it would be useful to know
On Wed, 4 Aug 2021 12:22:24 GMT, Thomas Stuefe wrote:
> We should not leak the handle to the jimage file (lib/modules) to childs.
>
> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
> well.
>
> Note that this only poses a problem when a child process is spawned off
On 03/08/2021 15:36, Volker Simonis wrote:
Hi,
I have a quick question on JDK-8198997 [1] (a follow-up of JDK-8194154
[2]) which introduced normalization for the cached "user.dir" property
in order to avoid "inefficient, repeated normalization".
However, from what I can see, WinNTFileSystem.get
On Sat, 31 Jul 2021 15:58:07 GMT, Markus KARG
wrote:
>>> Is this loop correct for the case that the channel gets truncated? In that
>>> case transferTo will return 0 as no bytes will be transferred and I'm
>>> concerned this code will go into an infinite loop.
>>
>> Good catch, indeed missed
On Fri, 30 Jul 2021 17:22:59 GMT, Lance Andersen wrote:
>> Hi,
>>
>> As discussed in the
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html
>> thread, this is the revised patch to address the use of '.' and '..' within
>> Zip FS
>>
>> Zip FS needs to use "." and "
On Thu, 29 Jul 2021 19:57:30 GMT, Markus KARG
wrote:
>> Good point.
>
> :-)
Is this loop correct for the case that the channel gets truncated? In that case
transferTo will return 0 as no bytes will be transferred and I'm concerned this
code will go into an infinite loop.
Also can you can che
On Fri, 30 Jul 2021 01:43:56 GMT, Jaikiran Pai wrote:
>> Lance Andersen has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains six additional
>> commit
On Mon, 26 Jul 2021 21:07:59 GMT, Lance Andersen wrote:
> I have not gone through the latest update in detail but there are some
> changes that are needed. Before moving forward with the CSR, I would like to
> give time for additional feedback on naming and design.
This proposal will need a fe
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev
wrote:
> Dear colleagues,
>
> Please review the patch that replaces the lambdas with anonymous classes
> which solves the startup time regression as shown below.
>
> I attached the Bytestacks flamegraphs for both original (regression) and
>
On Mon, 26 Jul 2021 10:16:47 GMT, Lance Andersen wrote:
>> Hi,
>>
>> As discussed in the
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html
>> thread, this is the revised patch to address the use of '.' and '..' within
>> Zip FS
>>
>> Zip FS needs to use "." and "
On Sun, 25 Jul 2021 21:56:10 GMT, Lance Andersen wrote:
> Hi,
>
> As discussed in the
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html
> thread, this is the revised patch to address the use of '.' and '..' within
> Zip FS
>
> Zip FS needs to use "." and ".." as l
On Sun, 25 Jul 2021 12:06:49 GMT, Sergey Chernyshev
wrote:
> I don't understand your analysis, you are testing the startup time with -Xint
> which disable JITs, but there is no mention of -Xint in the bug report.
> It's obvious to me that there is a regression with -Xint given that the
> lambd
On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed. In
>> post-BiasedLocking times, this is gets worse, as every access is
>> synchronized.
>> I ch
On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. On
>> MacOS, before the fix, running with `-Xss15
On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov
wrote:
> I propose to remove 'null' assignment of field CompactByteArray.values in
> `expand` method. In the next statement this field is overridden with another
> value - `tempArray`.
> This code was there from initial load of OpenJDK sources.
On Fri, 23 Jul 2021 11:57:34 GMT, Jaikiran Pai wrote:
> The updated version of this PR now fixes this part to open it just once. I
> had reviewed this `transferTo` multiple times before, but clearly I
> overlooked this part of the implementation.
>
> Thank you for these inputs. The updated PR
On Fri, 23 Jul 2021 08:47:46 GMT, Jaikiran Pai wrote:
> This part I didn't understand. Did you mean to refer some other JBS issue?
> Because from what I see in https://bugs.openjdk.java.net/browse/JDK-8251329
> there's no patch attached to it (unless of course it's restricted to specific
> JBS
On Thu, 22 Jul 2021 16:01:30 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8190753?
>>
>> The commit here checks for the size of the zip entry before trying to create
>> a `ByteArrayOutputStream
On Fri, 2 Jul 2021 11:08:43 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commit
On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk wrote:
> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app'
> dir to env variable in jpackage app launcher.
Is there a test planned for this change or is it covered by an existing test?
Just asking as this has been com
On Wed, 21 Jul 2021 17:34:15 GMT, Naoto Sato wrote:
>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of
>> the changes is `Charset.defaultCharset()` returning `UTF-8` and
>> `file.encoding` system property being added in the spec, but another notable
>> modification i
On 03/07/2021 17:19, Jaikiran Pai wrote:
:
There are still some decisions to be made:
1. Should we introduce this new property or should we enhance the existing
"useTempFile" property to allow a size to be passed?
It's an implementation tuning knob and highly unlikely to be in the
environmen
On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman wrote:
>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin"
>> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath()
>> looks for "/bin/" first in "/t
On 02/07/2021 18:16, Lance Andersen wrote:
:
That being said, if we want to follow Alan’s suggestion and throw an Exception,
I am OK with that as well.
Either way, we currently cannot access the file via Zip FS due to the call to
ZipPath::getResolvedPath() for all access and the path is only
On 02/07/2021 13:08, Jaikiran Pai wrote:
Thank you for noticing this issue in my change and bringing this up. I
have a question around this use case. Please consider a small
variation to your example as below:
try (var os = Files.newOutputStream(ZIPFILE);
ZipOutputStream zos = n
On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote:
>> Add a cache to record which sources have called `System::setSecurityManager`
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision
On Thu, 1 Jul 2021 13:25:32 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8251329?
>>
>> As noted in that issue, if a zip filesystem created on top of a jar
>> containing a "./" entry is "walked" using the `Files.walk
On Sun, 27 Jun 2021 13:13:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8251329?
>
> As noted in that issue, if a zip filesystem created on top of a jar
> containing a "./" entry is "walked" using the `Files.walkFile
On 30/06/2021 17:15, Jaikiran Pai wrote:
I understand that Alan's suggestion holds good and we should have some
logic in place which switches to using a temp file once we notice that
the sizes we are dealing with can exceed some threshold, but I guess
that is something we need to do separatel
On 30/06/2021 08:19, Bernd Eckenfels wrote:
Hello, sorry for being unpopular, but I just hate it to waste
developer resources,
I realy think this deprecation message should be re-considered, it
broke a lot of things, the amount of work to implement a caching
solution feels like a waste of tim
On Tue, 29 Jun 2021 21:18:35 GMT, Weijun Wang wrote:
>> Using a synchronized WeakHashMap with the class as the key would not prevent
>> class unloading.
>> Using a non-weak set or map to strings would keep the strings around for the
>> life of the runtime.
>
> I hope this is uncommon but if tha
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK
On Mon, 28 Jun 2021 03:41:20 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8190753?
>
> The commit here checks for the size of the zip entry before trying to create
> a `ByteArrayOutputStream` for
On Wed, 3 Feb 2021 01:29:02 GMT, Bo Zhang
wrote:
>> Previously, `ImageBufferCache` contains a ThreadLocal field which holds
>> strong reference to `ImageBufferCache$BufferReference.class`. When loaded
>> from `jrt-fs.jar`, this will keep `JrtFileSystemProvider$JrtFsLoader`
>> in memory forever a
On Fri, 25 Jun 2021 18:46:30 GMT, Mandy Chung wrote:
>> `Lookup::accessClass` should determine the accessibility of the element
>> type. An array class is accessible if and only if its element type is
>> accessible.
>>
>> This also fixes a spec bug to document `@throws NullPointerException` i
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote:
>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>>
>> Sometimes I introduce new methods. Please feel free to suggest method names
>> you like to use.
>
> Weijun Wang has updated the pull request incrementally with o
On Fri, 25 Jun 2021 20:50:47 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 163:
>>
>>> 161: * @apiNote
>>> 162: * Unlike the {@link InputStream#read(byte[],int,int) equivalent
>>> method}
>>> 163: * of {@code InputStream}, this
On Fri, 25 Jun 2021 17:24:58 GMT, Mandy Chung wrote:
> `java.lang.reflect.Proxy::newProxyInstance` and
> `java.lang.invoke.MethodHandleProxies::asInterfaceInstance` do not specify
> how to deal with sealed interfaces. These APIs should reject sealed
> interface with `IllegalArgumentException
On 25/06/2021 14:51, David Lloyd wrote:
Is this better than the current solution of `nativeOrder() ==
BIG_ENDIAN` other than reducing a few keystrokes?
I wouldn't expect many developers would need to be concerned with the
platform endianness, it's more likely going to be something advanced,
may
On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter wrote:
>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
>> `read(byte[],int,int)` to return zero per the `InputStream` specification
>> when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated
On Mon, 21 Jun 2021 13:26:14 GMT, Alan Bateman wrote:
>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
>> against JDK17.
>>
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock
>> object associated with t
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov
wrote:
> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
> against JDK17.
>
> This fixes the deadlock in ClassLoader between the two lock objects - a lock
> object associated with the class being loaded, and the
> Clas
On 18/06/2021 18:30, Brian Burkhalter wrote:
On Jun 18, 2021, at 6:36 AM, Alan Bateman <mailto:al...@openjdk.java.net>> wrote:
Adding an override of transferTo may require new tests. @bplb Do you
if we have good tests for all the scenarios where input stream
re
On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk wrote:
> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin"
> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath()
> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so"
> string
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK
On Sat, 5 Jun 2021 15:11:55 GMT, Markus KARG
wrote:
> @AlanBateman I'm done with the changes you requested and kindly like to ask
> where to go from here.
Moving ChannelOutputStream to sun.nio.ch looks right. The implementation of
transferTo will need a few rounds of cleanup, it's a look very
On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote:
> There are a lot more tests than just tier1. :) I don't expect many, if any,
> tests to be looking for a specific IOOBE message, and I can't see an easy way
> to find such tests without running them. If core-libs folk are okay with this
>
On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote:
> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
> by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
> the whole JDK codebase.
I looked through the changes in java.base and only spotted o
On 14/06/2021 08:35, Peter Firmstone wrote:
I wouldn't want to see SecurityManager and Policy be neutralized, it's
better to remove it and fail early so people update their software,
there's a risk they may update without realizing it's no longer fully
functional. Get rid of the baggage so
cc'ing security-dev as that is the mailing list to use for this JEP.
This JEP is the first of several in a multi-release/multi-year effort.
It's way too early to give any guess as to when the APIs will be
removed. As the JEP says, future releases may degrade the SM APIs so
that System.getSM re
On Wed, 9 Jun 2021 13:37:02 GMT, Jorn Vernee wrote:
>> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line
>> 241:
>>
>>> 239: \ --validate Validate a jar. This process will
>>> validate that the API\n\
>>> 240: \ exported by a
On Tue, 8 Jun 2021 18:32:36 GMT, Jorn Vernee wrote:
>> This patch adds a `--validate` option to the jar tool which can be used to
>> validate a jar file that might be malformed. For instance, if a jar is a
>> multi-release jar, it is malformed if different versions expose different
>> APIs.
>>
On Tue, 8 Jun 2021 14:29:38 GMT, Athijegannathan Sundararajan
wrote:
>> jlink should clean up output directory on any failure. should not leave
>> partially filled output.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with
> one additional commit since the last re
On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote:
>>> I thought about that but not sure of performance impact. Is the worst
>>> problem that more than one warnings will be printed for a single caller?
>>> It's not really harmless.
>>>
>>> As for the frame, if the warning message only contain
On Wed, 19 May 2021 15:36:57 GMT, Jorn Vernee wrote:
>> This patch adds a `--validate` option to the jar tool which can be used to
>> validate a jar file that might be malformed. For instance, if a jar is a
>> multi-release jar, it is malformed if different versions expose different
>> APIs.
>
On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote:
> I thought about that but not sure of performance impact. Is the worst problem
> that more than one warnings will be printed for a single caller? It's not
> really harmless.
>
> As for the frame, if the warning message only contain the calle
On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan
wrote:
> jlink should clean up output directory on any failure. should not leave
> partially filled output.
I think we need to rename the JBS issue as this is not specific to the -vm
option. Instead, this is about cleanup when jlin
On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote:
> You might want to make your "WARNING" consistent with the VM's "Warning" so
> that OutputAnalyzer's logic to ignore warnings will automatically ignore
> these too.
The uppercase "WARNING" is intentional here, it was the same with illegal
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
Changes requested by alanb (Reviewer).
src/java.base/share/classes/java/lang/System.java line 331:
> 329:
> 330:
On Mon, 7 Jun 2021 00:22:41 GMT, Joe Darcy wrote:
>> Make explicit illegal argument cases of Class.arrayType.
>>
>> Please also review the corresponding CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8268300
>
> Joe Darcy has updated the pull request incrementally with one additional
> commi
On Wed, 2 Jun 2021 16:13:48 GMT, Jonathan Gibbons wrote:
> Please review the change to update to using jtreg 6.
>
> The primary change is to the jib-profiles.js file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion`
On Wed, 2 Jun 2021 15:00:56 GMT, Roger Riggs wrote:
>> Methods are added to java.lang.Process to read and write characters and
>> lines from and to a spawned Process.
>> The Charset used to encode and decode characters to bytes can be specified
>> or use the
>> operating system native encoding
On Wed, 2 Jun 2021 00:39:25 GMT, Stuart Marks wrote:
> I'm fixing this along with a couple intertwined issues.
>
> 1. Add Map.Entry::copyOf as an idempotent copy operation.
>
> 2. Clarify that AbstractMap.SimpleImmutableEntry is itself unmodifiable (not
> really immutable) but that subclasses
501 - 600 of 5664 matches
Mail list logo
