On 06/09/2017 05:17, Weijun Wang wrote:
Hi All
Please review the change, which spans to root, jdk and langtools repos.
http://cr.openjdk.java.net/~weijun/8148371/
I've searched for the "policytool" word in the whole jdk10/jdk10 forests,
removed all files having the word inside the path n
One of the long standing issues with the security manager support is
that the overhead when there is no security manager is non-zero. Two
specific examples are (i) the overhead of defineClass (assuming the
defining loader is a SecureClassLoader) as it involves a callback to get
the permission
On 20/11/2017 20:15, Bernd Eckenfels wrote:
:
One thing which might be a problem: when doPrivileged does no longer
execute the Code in a seperate stack this has implications to the
runtime. The stacks will get deeper (and might even overflow (more
often)). So maybe this „no seperate stack“ fu
On 21/11/2017 00:48, David Lloyd wrote:
One thing that springs to mind. Some allowance would have to be made
for domain combiners and JAAS Subject propagation: this mechanism also
uses access control contexts, to its own great detriment.
Are you thinking about usages where there is no security m
On 22/11/2017 13:23, Sean Mullan wrote:
Please review a new JEP Draft titled "Open-Source the Root
Certificates". The JDK source code currently contains an empty cacerts
keystore, which prevents security components such as TLS from working
out-of-the-box on OpenJDK builds.
The goal of this JE
On 22/11/2017 14:37, Sean Mullan wrote:
Please review this change to remove the pre-JDK 1.2 SecurityManager
methods that have been deprecated since JDK 1.2 and marked for removal
in JDK 9. These methods are fragile, error-prone and have been
obsolete since the SecurityManager was revamped in JD
On 22/11/2017 15:49, Sean Mullan wrote:
Hmm. Where do you see it being called inside doPrivileged?
StackWalker.getInstance does a permission check when you want class refs.
:
Sure, the test already had everything I need so it was easier to
leverage it rather than just duplicating. I had
On 23/11/2017 19:21, Jason Tedor wrote:
> Long term then it would be interesting to explore degrading and
eventually dropping the security manager but that is beyond the scope
of what I would like to discuss here.
That is a bold topic to immediately declare out of scope. I am looking
for some
On 01/12/2017 17:16, Volker Simonis wrote:
Hi Rajan,
great to see this finally happen!
I have just a quick question related to the tests. As far as I can
see, the tests will only succeed if the OpenJDK will be build with the
new open sourced, Oracle root certificates. But what if somebody is
On 01/12/2017 18:05, Volker Simonis wrote:
:
Yes, but as far as I know @key tags are implemented by querying VM
properties. In this case however there's no VM property which
indicates how the VM has been configured.
jtreg -k allows keyword expressions to be specified. It's one way of
selecting
On 11/12/2017 01:12, Weijun Wang wrote:
I modified a class inside the jdk.crypto.cryptoki module, compiled it with "javac -d
/tmp", and then ran a small program with
java --patch-module jdk.crypto.cryptoki=/tmp -Djava.security.manager MyProg
and it fails with
TEST RESULT: Failed. Execution
On 11/12/2017 07:50, Weijun Wang wrote:
I was just trying to run a jtreg test on a new Windows VirtualBox VM. A small
code change is needed but I don't want to do a full build (it also does not
have enough memory). I just copied an existing image, and the modified class
was compiled on the hos
On 18/12/2017 16:28, Fridrich Strba wrote:
Hello, good people,
After removing some deprecated SecurityManager methods in jdk10, I am
trying to build libbluray, but there is this snippet that obviously is
broken with jdk10:
classDepth has been deprecated since 1.2 (1998) so it's surprising to
se
On 12/01/2018 04:51, Amy Lu wrote:
Please review this minor test-tag-only change to move bugid from @test
to @bug
bug: https://bugs.openjdk.java.net/browse/JDK-8194959
webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/
Looks good.
On 23/03/2018 13:56, Magnus Ihse Bursie wrote:
With modern compilers, we can use compiler directives (such as
_attribute__((visibility("default"))), or __declspec(dllexport)) to
control symbol visibility, directly in the source code. This has
historically not been present on all compilers, so w
On 23/03/2018 15:15, Magnus Ihse Bursie wrote:
:
Very much so, yes. I've found a lot of dubious exports, everything from global
variables (yuck!) to functions that does not seem to be used anymore, to lots
of strange exports.
The changes looks good to me and I think we should follow this up wit
Moving this to security-dev.
From the stack trace, it looks like you are using JDK 8 or older. There
are several changes in JDK 9 and newer in the PolicyFile code to how it
loads its resources that may help with the issues you are seeing.
-Alan
On 27/03/2018 13:56, Peter Firmstone wrote:
No
On 27/03/2018 16:15, Sean Mullan wrote:
Please remove this change to remove several SecurityManager methods
that have been marked for removal since Java SE 9:
checkTopLevelWindow, checkSystemClipboardAccess,
checkAwtEventQueueAccess, and checkMemberAccess. These methods no
longer have any bene
On 30/04/2018 13:25, Claes Redestad wrote:
Hi,
moving a couple of local permission constants to
sun.security.util.SecurityConstants ensures we delay and avoid loading
permission classes very early during bootstrap. Delaying load is
profitable since it's happening early enough (before
System.
On 29/06/2018 09:22, Sibabrata Sahoo wrote:
May I get the approval from serviceability-...@openjdk.java.net.
This a test only change to update the keystores and the list of
ciphers/protocols that the test uses. There's nothing serviceability
specific here so having a Reviewer from the security
Forwarding to security-dev.
On 10/07/2018 17:47, Norman Maurer wrote:
Hi all,
I just tried to run netty[1] testsuite with the latest jdk11 EA
release (21) and saw some class-cast-exception with our custom
SSLEngine implementation
Caused by: java.lang.ClassCastException: class
io.netty.han
On 12/07/2018 05:47, Xuelei Fan wrote:
Hi,
Please review the update:
http://cr.openjdk.java.net/~xuelei/8207029/webrev.00/
It's an interesting user case of the TrustManagerFactory and
KeyManagerFactory. The KeyManager or TrustManager implementation may
be not implemented in the same prov
On 20/07/2018 12:38, Chris Hegarty wrote:
JDK-8204233 added a new security property, `jdk.net.includeInExceptions`,
to include additional, potentially security sensitive, information in
exception detail messages in the networking area. The property accepts a
comma separated list of values that sp
On 06/08/2018 20:11, joe darcy wrote:
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to
suppress future planned serial lint checks (JDK-8202056).
Mo
On 06/08/2018 20:23, Sean Mullan wrote:
After further evaluation of the new jdk.includeInExceptions security
property originally introduced in JDK-8204233 [1] and further
generalized in JDK-8207846 [2], I felt that a stronger warning should
be added to the description of the property alerting t
On 07/08/2018 16:00, Baesken, Matthias wrote:
Ping 😊 , any reviews / comments ?
Did we get to a conclusion on whether to have central infrastructure to
read/parse the security property? As I recall, this one was originally
proposed before the generalization of the networking solution. Th
On 13/08/2018 20:11, Sean Mullan wrote:
:
Also, this change puts more of a dependency on sun.security.action
which I think we want to avoid, as it would be nice to eventually stop
exporting sun.security.action so as to minimize the exports from
java.base to the java.security.jgss module. You
On 24/08/2018 15:52, Baesken, Matthias wrote:
Hello, I created another webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.5/
- use now jarPath instead of jarpath in the java security file
- moved the parsing of the property to a more general location (separate
class jdk/intern
On 27/08/2018 16:09, Weijun Wang wrote:
Since we've removed all krb5-based ciphersuites from JSSE, this qualified
export is useless anymore.
Please review the patch below:
diff --git a/src/java.base/share/classes/module-info.java
b/src/java.base/share/classes/module-info.java
--- a/src/java.b
On 27/08/2018 12:25, Weijun Wang wrote:
Would it be possible (in the future) for 2 modules to use the same name for a
private package? If yes, we can dup the sun.security.action classes into
java.security.jgss without having to modify all calls.
Not if both modules are mapped to the same class
On 28/08/2018 15:17, Xuelei Fan wrote:
Hi,
Please review this release note:
https://bugs.openjdk.java.net/browse/JDK-8210070
Per the "supported_groups" extension specification, the
supported_groups extension should not present in the ServerHello
handshake message. JDK 11 cannot work wit
On 31/08/2018 15:07, Xuelei Fan wrote:
As we don't fix it in JDK 11, it is intended to have a known issue
note for JDK 11.
Yes, a RN-KnownIssue make sense, I'm just trying to understand there is
a note showing up under "Build 9". It may be that whatever generates
this preview page is using t
On 10/09/2018 21:37, Jonathan Gibbons wrote:
Please review a patch to have the Source Launcher be able to work when
a security manager is enabled.
It's not clear to me that this is an interesting use-case but in any
case I think you've got two scenarios to test. One is setting
java.security.man
On 11/09/2018 19:42, Jonathan Gibbons wrote:
:
As regards the interaction between Source Launcher and the use of a
security manager, I see 3 possibilities:
1. Specifically support it, as provided in this webrev
2. No code change, but update JEP 330 to specify the behavior
3. Explicitly reject
On 14/09/2018 00:19, Bernd Eckenfels wrote:
:
I am curious, did you verify that the compiler will actually optimize
the getSecurityManager null check in case allow=never?
Yes, and the reason the allowSecurityManager field is an int rather than
a boolean is so that it get sets to a value othe
On 13/09/2018 21:02, Sean Mullan wrote:
:
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053
This is inline with the discussion we had on this mailing list last year
a
On 14/09/2018 03:40, Weijun Wang wrote:
The test runs very slow on Linux and turns out reading from the embedded HTTP
server is the bottleneck. Here is the fix:
diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
--- a/test/jd
On 14/09/2018 13:46, David Lloyd wrote:
:
There are essentially two main parts to this change:
1. Deprecation of System.s[etS]ecurityManager()
We (JBoss) use this method to configure some things at run time (like
customizing the Policy) before installing our security manager, so
this would be
On 14/09/2018 14:28, David Lloyd wrote:
:
I can say that this explanation would be more palatable by far if the
security manager as a whole could be deprecated all at once. I for
one would certainly be happy to remove support for it in the software
that I maintain (it's a considerable amount of
On 15/09/2018 22:00, Philip Race wrote:
It was exported in the past .. and it was publicly documented ..
http://www.oracle.com/technetwork/articles/javase/appletwarning-135102.html
.. so I think Sergey was correct in his "JDK" scope.
Implementation would be for something entirely internal.
I
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 increm
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
> unexpe
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 8
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
> existing
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 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 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 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 thoug
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 b
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, 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 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 re
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
unt
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 be.
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 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 -Djava
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 im
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 c
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 changes
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 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 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
> ac
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 jdk.se
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:
>
> open/
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 there
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 fin
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 reas
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 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, 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: printSt
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 i
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 c
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 c
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 cod
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 exceptio
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 e
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 exce
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 exce
On Thu, 29 Oct 2020 14:13:40 GMT, Maurizio Cimadamore
wrote:
>>> @mcimadamore, if you pull from current master, you would get the Linux
>>> x86_32 tier1 run "for free".
>>
>> Just did that - I also removed TestMismatch from the problem list in the
>> latest iteration, and fixed the alignment
On Mon, 2 Nov 2020 11:26:51 GMT, Maurizio Cimadamore
wrote:
>> I looked through the changes in this update.
>>
>> The shared memory segment support looks sound and the mechanism to close a
>> shared memory segment is clever (albeit a bit surprising at first that it
>> does global handshake to
On Wed, 4 Nov 2020 07:45:09 GMT, Alan Bateman wrote:
>>> The javadoc for copyFrom isn't changed in this update but I notice it
>>> specifies IndexOutOfBoundException when the source segment is larger than
>>> the receiver, have other exceptions been ex
On Thu, 5 Nov 2020 17:14:16 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * fi
On Mon, 9 Nov 2020 16:07:13 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * fi
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1299
On Fri, 4 Dec 2020 10:29:48 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 Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote:
> And I can certainly move jdwp.spec to java.base instead.
If jdwp.spec has to move to the src tree then src/java.se is probably the most
suitable home because Java SE specifies JDWP as an optional interface. So
nothing to do with jav
On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie wrote:
>> @mlchung If you don't have any strong preference, I implore you to accept
>> this change. I **vastly** prefer to move the data out of `make`!
>>
>> This is not just about Skara tooling. When working with make files, autoconf
>> and
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$M
On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie wrote:
>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`,
>> `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good
>> overall.
>
> I think this is almost ready to be pushed, but I'd like to have some
On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov
wrote:
> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
jrtfs is compiled twice, the second is to --release 8 so it can be packaged
into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to
be
On Fri, 18 Dec 2020 20:11:26 GMT, Stuart Marks wrote:
> I have to say that introducing a ThreadLocal here seems like a step in the
> wrong direction. With a ThreadLocal, if I read this correctly, a
> MessageDigest will be cached with each thread that ever calls this API, and
> it won't be garb
On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov
wrote:
>> I already suggested this, but anyway please always extract the changes to
>> the java.desktop module to the separate PR.
>
> I've extracted changes in java.desktop into separate PR #1856
> Reverted this changes from current PR.
Probab
On Wed, 23 Dec 2020 02:13:38 GMT, Valerie Peng wrote:
> Could someone please help review this trivial change - just replace
> JNI_COMMIT with 0 for all ReleasePrimitiveArrayCritical calls.
>
> Thanks,
> Valerie
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.jav
On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote:
>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one
On Tue, 5 Jan 2021 21:02:21 GMT, Joe Darcy wrote:
> Back in JDK 16, two unintended default constructors were identified and
> deprecated for removal. The time has come to remove them.
>
> Please also review the corresponding CSRs:
>
> JDK-8258521 Remove terminally deprecated constructor in GSS
On Mon, 11 Jan 2021 09:20:07 GMT, Magnus Ihse Bursie wrote:
>> Marked as reviewed by prr (Reviewer).
>
> This PR is not stale; it's just still waiting for input from @AlanBateman.
@magicus Can the CharacterDataXXX.template files move to
src/java.base/share/classes/java/lang?
-
PR:
On 18/01/2021 21:29, Bernd wrote:
Hello,
bad news everyone. The second Windows Filesystem related security bug
reported by Jonas Lykkegaard which allows crashing Windows with a
unpriveledged read access also affects JVM and it is not filtered by
Path.of. Which means bot new File(bad).exists
On Fri, 15 Jan 2021 14:58:14 GMT, Alan Bateman wrote:
>> This PR is not stale; it's just still waiting for input from @AlanBateman.
>
> @magicus Can the CharacterDataXXX.template files move to
> src/java.base/share/classes/java/lang?
> @AlanBateman When I moved the cha
On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov
wrote:
>> 8080272 Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8080272: Refactor I/O stream copying
701 - 800 of 906 matches
Mail list logo
