On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
On Tue, 14 Jun 2022 11:36:36 GMT, Matthias Baesken wrote:
>> When trying to construct an LdapURL object with a bad input string (in this
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we
>> run into the
On Fri, 10 Jun 2022 13:41:48 GMT, Matthias Baesken wrote:
> Hi Alan , sure we could use something like the already existing hostInfo of
> property jdk.includeInException private static final boolean
> enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo");
> and make the
On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken wrote:
> When trying to construct an LdapURL object with a bad input string (in this
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run
> into the
On Fri, 13 May 2022 04:41:03 GMT, ExE Boss wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated copyrights
>> Fixed cast style to add a space after cast, (where consistent with file
>> style)
>> Improved
On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a
On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs wrote:
>> PR#8599 8244681: proposes to add compiler warnings for possible lossy
>> conversions
>> From the CSR:
>>
>> "If the type of the right-hand operand of a compound assignment is not
>> assignment compatible with the type of the variable, a
On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote:
> I did wonder why it has security-libs as the sub-category and if the intent
> was not what we see here.
I suspect the JBS issue was initially created to to look at the usages of
getProperty in the security code but it has been extended. The
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote:
> JDK-6725221 Standardize obtaining boolean properties with defaults
src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
> 775: if (!printStackPropertiesSet && VM.initLevel() >= 1) {
> 776:
On Thu, 28 Apr 2022 16:58:40 GMT, Joe Darcy wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> out
On Thu, 28 Apr 2022 01:34:19 GMT, Joe Darcy wrote:
>> To enable more complete doclint checking (courtesy @jonathan-gibbons),
>> please review this PR to add type-level @param tags where they are missing.
>>
>> To the maintainers of java.util.concurrent, those changes could be separated
>> out
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run arbitrary code may be problematic (for the
same
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already provide. Nothing is being subtracted, and thus I
On 25/04/2022 15:45, Flavia Rainone wrote:
Hi everyone,
I work with the XNIO ( https://github.com/xnio/xnio/ ) project, led by
David Lloyd in CC.
I'm not sure if this is the best way to get in touch, but I could not
find out how to create an account for OpenJDK Jira to add a comment
On Mon, 25 Apr 2022 17:40:13 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8285504
>
> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
> a single code review, so it was decided to split into smaller chunks. This is
> one such chunk:
>
>
On Thu, 21 Apr 2022 14:11:08 GMT, Alan Bateman wrote:
>> I ran `codespell` on modules owned by the security team (`java.security.jgss
>> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
>> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth
On Thu, 21 Apr 2022 13:51:27 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by the security team (`java.security.jgss
> java.security.sasl java.smartcardio java.xml.crypto jdk.crypto.cryptoki
> jdk.crypto.ec jdk.crypto.mscapi jdk.security.auth jdk.security.jgss`), and
>
On Mon, 18 Apr 2022 15:13:14 GMT, Anthony Scarpino
wrote:
> x86-64 only uses this intrinsic, aarch64 does not support this intrinsic and
> uses the java code.
It looks like aarch64 has an implementation of
generate_galoisCounterMode_AESCrypt, isn't that the code that implGCMCrypt0
runs?
On Mon, 18 Apr 2022 05:06:26 GMT, Smita Kamath wrote:
> When input length provided to the intrinsic is 8192, only 7680 bytes are
> processed as the intrinsic operates on multiples of 768 bytes.
> In implGCMCrypt(ByteBuffer src, ByteBuffer dst) method,
> dst.put(bout, 0, PARALLEL_LEN) statement
On 17/04/2022 17:24, liach wrote:
Convert dynamic proxies to hidden classes. Modifies the serialization of proxies
(requires change in "Java Object Serialization Specification"). Makes the
proxies hidden in stack traces. Removes duplicate logic in proxy building.
The main compatibility
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on the `src/java.base` directory, and accepted those
> changes where it indeed discovered real typos.
>
> (Due to false positives this can unfortunately not be run automatically)
>
> The majority of fixes are in
On Fri, 8 Apr 2022 22:55:07 GMT, Bradford Wetmore wrote:
> @AlanBateman, @dfuch, @bchristi-git, any great ideas here?
As you have found, if an open Socket is unreferenced then a cleaner can close
the underlying socket (and release the file descriptor). The Cleaner is setup
by the SocketImpl
On 27/03/2022 14:45, Rick Hillegas wrote:
From the silence, I assume that there isn't any advice I can give
Derby users. At this time the Security Manager is the only mechanism
for protecting an application against these threats. Users should
ignore the deprecation diagnostics and set
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On 16/03/2022 08:44, Magnus Ihse Bursie wrote:
:
If you have such strong opinions on the data files shared between
java.base and jdk.charsets/jdk.localedata, I propose we leave them in
make/data for the time being, clean up the associated mess, and then
work out where they actually should
Magnus,
This proposal does not address the previous concerns. As before, you are
proposing to put the data files used to generate the classes for
jdk.localedata and jdk.charsets into src/java.base and I don't think we
should do that. I really think this PR needs to be withdraw n or closed
On Mon, 7 Mar 2022 17:55:45 GMT, Joe Darcy wrote:
>> Please review this small API enhancement to add the usual constructors
>> taking a cause to SocketException and then update uses of initiCause on
>> creating SocketException to instead pass the cause via the constructor.
>>
>> Please also
On Fri, 4 Mar 2022 21:17:01 GMT, Joe Darcy wrote:
> Please review this small API enhancement to add the usual constructors taking
> a cause to SocketException and then update uses of initiCause on creating
> SocketException to instead pass the cause via the constructor.
>
> Please also review
On Tue, 22 Feb 2022 22:05:32 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
On Fri, 18 Feb 2022 19:22:27 GMT, Lance Andersen wrote:
> Ok, thank you for the feedback. I just pushed a change with additional
> comments on the jar creation which hopefully will address your input above.
It's a bit better but I think it needs a clear step-by-step instructions in a
comment
On Fri, 18 Feb 2022 17:15:17 GMT, Lance Andersen wrote:
> If you feel there is still something lacking for documentation, I can
> certainly make another pass clarify/add it, but I tried to cover the steps
> (but I also understand what might be obvious to me might not be as obvious as
> I
On Fri, 18 Feb 2022 16:25:30 GMT, Lance Andersen wrote:
> > The updates changes to ZipFile/JarFile look okay. I don't have time to
> > study the test too closely right now but it will need to include
> > instructions on how to re-create the signed JAR that is stored in the byte
> > array.
>
On Thu, 17 Feb 2022 19:00:47 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
On Thu, 10 Feb 2022 21:35:56 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the attached patch to address
>>
>> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
>> parameter
>> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
On Tue, 8 Feb 2022 18:11:38 GMT, Lance Andersen wrote:
> I personally think it is best to continue throw the NPE as that provides
> symmetry with ZipFile::getInputStream, aligns with the current javadoc where
> a null parameter will throw an NPE unless specified elsewhere, there are
>
On Tue, 8 Feb 2022 15:27:46 GMT, Sean Mullan wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reduce Exception checking to JarFile::verifiableEntry
>
> src/java.base/share/classes/java/util/jar/JarFile.java line
On Fri, 4 Feb 2022 12:42:39 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review the attached patch to address
>
> - That JarFile::getInputStream did not check for a null ZipEntry passed as a
> parameter
> - Have Zip/JarFile::getInputStream throw a ZipException in the event that an
>
On Tue, 1 Feb 2022 22:33:46 GMT, Joe Darcy wrote:
>> The references to JOSS, the Java Object Serialization Specification, are not
>> done consistently in the API javadoc. This should be improved.
>>
>> I'll update copyright years before pushing.
>
> Joe Darcy has updated the pull request
On Wed, 5 Jan 2022 17:22:54 GMT, Daniel D. Daugherty wrote:
> A couple of trivial ProblemListings:
>
> JDK-8279529 ProblemList
> java/nio/channels/DatagramChannel/ManySourcesAndTargets.java on macosx-aarch64
> JDK-8279532 ProblemList
>
On Tue, 4 Jan 2022 06:59:58 GMT, Aleksey Shipilev wrote:
>> SonarCloud reports:
>> A "Map" cannot contain a "String" in a "ServiceKey"
>> type.
>>
>>
>> // clean up old alias if present
>> Service prevAliasService = legacyMap.get(aliasAlg);
>>
>>
>> Should be `aliasKey`, like
On Thu, 23 Dec 2021 13:33:26 GMT, Aleksey Shipilev wrote:
> SonarCloud reports:
> A "Map" cannot contain a "String" in a "ServiceKey"
> type.
>
>
> // clean up old alias if present
> Service prevAliasService = legacyMap.get(aliasAlg);
>
>
> Should be `aliasKey`, like other
On Wed, 22 Dec 2021 01:18:58 GMT, Stuart Marks wrote:
>> Enable the security manager in rmiregistry's launcher arguments.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change java.security.manager to "allow"; filter
On Fri, 17 Dec 2021 20:01:27 GMT, Stuart Marks wrote:
> Enable the security manager in rmiregistry's launcher arguments.
As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry
-J-Djava.security.manager=allow` are equivalent because rmiregistry sets the
default SM. Some
On Wed, 6 Oct 2021 20:37:29 GMT, Andrey Turbanov wrote:
>> 8274809: Update java.base classes to use try-with-resources
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8274809: Update java.base classes to use
On Mon, 6 Dec 2021 22:22:14 GMT, Weijun Wang wrote:
> Add null check. I must have thought the NPE will be thrown anyway but the
> `catch Exception` block swallows it.
>
> I added a noreg-trivial label. If you think differently can add one.
Is there a test for this? (I see noreg-trivial is
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API
On Tue, 2 Nov 2021 19:35:29 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] -
On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote:
> In comments, I think the 'synchronized static 'reads better, the conventional
> order is for the code.
I think Roger is right and maybe the change to the javadoc could be dropped
from this patch.
-
PR:
On 28/10/2021 20:14, Rick Hillegas wrote:
As a canary in the mineshaft, I built and tested Apache Derby with the
recent build 18-ea+20-1248 of Open JDK 18. I tripped across the
following issue when running Derby's regression tests. The problem is
explained in more detail at
On Tue, 26 Oct 2021 12:52:58 GMT, Aleksei Efimov wrote:
>> 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
On Fri, 22 Oct 2021 14:27:41 GMT, Aleksei Efimov wrote:
>> 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
On Wed, 20 Oct 2021 18:25:24 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change InetAddressResolver method names
>
> src/java.b
On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote:
>> 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
On Wed, 20 Oct 2021 11:52:38 GMT, Aleksei Efimov wrote:
>> 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
On Sun, 17 Oct 2021 15:55:59 GMT, Aleksei Efimov wrote:
> * `InetAddressResolverProvider.Configuration` interface API might evolve,
> e.g. there might be a need to pass additional configuration items.
> * local hostname is a dynamic information, therefore it cannot be passed as
> string
On Wed, 15 Sep 2021 01:45:49 GMT, wxiang
wrote:
> Yes, I will take care of it. Need I create a new PR?
Up to you, it's okay to continue with this one if you want, we would just need
to change the description here and in JBS.
-
PR: https://git.openjdk.java.net/jdk/pull/5383
On Wed, 8 Sep 2021 06:30:34 GMT, wxiang
wrote:
>> wxiang has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Some minor changes
>>
>> Include:
>> 1. remove public for INDEX_NAME in JarFile
>> 2. recover the definition for
On Wed, 8 Sep 2021 06:30:34 GMT, wxiang
wrote:
> Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473
Thanks. I've updated the CSR to make it clearer what this change is about.
There is still some TDB for the JAR file spec.
-
PR:
On Tue, 7 Sep 2021 03:34:27 GMT, wxiang
wrote:
> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the
> JAR index support in URLClassPath,
> and don’t need to do anything to the jar tool in the short term,
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin and webstart are no longer supported and
>
On 23/08/2021 07:46, Jaikiran Pai wrote:
:
So if any of the upcoming Java 18 EA builds introduce the "disallow"
by default, then if Ant has to test against those EA builds (not just
for SecurityManager but any other changes), then Ant project will have
to start setting the
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 Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be done more efficiently(up to x20
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 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, 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:
>
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 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:
>
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas
how Java threads should behave. I know the main problem is not "SecurityManager is too complex
/ too slow / wrongly used /..." -- the main problem of
On 31/07/2021 04:04, Peter Firmstone wrote:
Allan has advised when finalizers are removed, it will be practical to
use Agents to instrument public API to implement an authorization
layer, this is try, so can it be coordinated with JEP 411 et al?
Our exchange was about instrumenting
On 23/07/2021 23:33, Peter Firmstone wrote:
I think it's worth noting that there isn't a way to securely run code
with malicious intent now, so I'm surprised that at this late stage
you were still providing support for sand boxing (whack a mole).
It's just for us many assumptions have been
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
On 23/07/2021 11:48, Peter Firmstone wrote:
Perhaps the solution is to replace the entire class, instead of
instrumenting one method?
Compile a patched copy of the JVM, with modified class files, then
replace the existing classes in the JVM with the modified classes?
Kinda like
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
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
On 30/06/2021 05:51, Jaikiran Pai wrote:
In the case we are dealing with, the class is always
"org.apache.tools.ant.types.Permissions". It will always be loaded by
one single classloader (so classloaded just once). However, multiple
different instances of this class will get created during
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
On 29/06/2021 08:04, Jaikiran Pai wrote:
Thank you Alan. I see that
https://bugs.openjdk.java.net/browse/JDK-8269543 has been created for
this. I'll keep a watch on that one.
Yes, that was the original intention but had to dropped because it
wasn't thread safe.
BTW: I'm puzzled as to
On 28/06/2021 18:16, Jaikiran Pai wrote:
On a slightly related note, I was wondering why we decided to go with
what appears to be a bit more aggressive approach to these warning
messages as compared to what was done with the illegal reflective
access warnings? I would have thought that the
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
On 23/06/2021 04:02, Peter Firmstone wrote:
Note: I'm not sure how to replace an inherited AccessControlContext
(with a new implementation based on StackWalker functionality) at
thread creation time, as it must be created when threads are created,
possibly by using ThreadFactory everywhere,
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
On 18/06/2021 03:51, Jaikiran Pai wrote:
:
Given all that, do you think that we should be printing the jar file paths in
this WARNING message by default? I read the linked CSR, but I didn't see why
the location of the jar or the name of the jar would be useful in this warning
message. As long
On Thu, 17 Jun 2021 14:55:02 GMT, Weijun Wang wrote:
>> More loudly and precise warning messages when a security manager is either
>> enabled at startup or installed at runtime.
>>
>> This is new PR for the `openjdk/jdk17` repo copied from
>> https://github.com/openjdk/jdk/pull/4400. A new
On 17/06/2021 00:30, Rick Hillegas wrote:
Thanks for that advice, Alan. I have rototilled
@SuppressWarnings("removal") annotations across the Derby codebase and
thrown more memory at javadoc so that it won't crash on JDK 11. When I
run Derby's test suites, I see a blizzard of the following
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
On 15/06/2021 15:10, Rick Hillegas wrote:
:
When I tried to build Derby with the Rampdown Phase One build of open
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation
of Security Manager classes and methods, undoubtedly the consequence
of JEP 411
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
On 10/06/2021 07:40, Peter Firmstone wrote:
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
JFR events can't be used to intercept/veto operations, assuming that is
what you are asking. However, it might be that JFR events
On 10/06/2021 03:49, Peter Firmstone wrote:
Hi Sean,
Sorry I've confused you.
What I should have said is a ProtectionDomain with a null CodeSource.
What I mean to ask is, where ProtectionDomain is created with a null
CodeSource, in Class::getProtectionDomain() can we have CodeSource's
that
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
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
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 04/06/2021 05:22, Peter Firmstone wrote:
Could someone please advise the recommended way now to preserve the
Subject in Executors to establish a TLS connection?
I think the primitive you are looking for is scope local variables. It's
still in the exploration phase but there is a draft
On 03/06/2021 01:04, Chapman Flack wrote:
On 06/02/21 19:41, Peter Firmstone wrote:
We need the power of AccessController's stack walk, StackWalker doesn't work
with compiled code, only bytecode.
Is this correct? I have not tried it, but the apidocs had led me to
understand it did not
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
1 - 100 of 766 matches
Mail list logo
