date:20200807

Re: Publishing EOL dates on whichversion?

2020-08-07 Thread Igal Sapir

Chris,

On Thu, Aug 6, 2020 at 8:29 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm wondering if we shouldn't add EOL dates to the "which version" page.
>
> The table on that page is very busy, but I think it would help to know:
>
> 1. When a currently-supported version will be EOL'd (e.g. 7.0.x)
> 2. When a superseded version has been EOL'd (e.g. 6.0.x)
>

+1.  Very useful and important information IMO.


> We might be able to shrink the table horizontally a little by
> shrinkking / abbreviating some of the column headers. For example
> replace "Authentication (JASPIC) Spec" with "JASPIC". Maybe drop
> "Spec" from all headers. Maybe shorten "Latest Released Version" to
> "Latest" and "Supported Java Versions" to "Java". We could use a
> stylesheet to add those longer headers for printing, and we could use
> "title"s to expand the headers if you float a mouse/tap a finger on
> the headings to get more information. We could also put a key below
> the table.
>
> WDYT?
>

There are many opportunities for improving the layout, and I'd be happy to
get back on that.  It is a bit challenging for me to work with SVN though
as I'm much more familiar with Git and I don't have much time ATM to work
on improving my SVN skills (which would probably become obsolete soon
anyway).

It'd be great if we could move the website to Git.  Many apache projects
use the `-site` or `-website` suffix, so it can be something like
`tomcat-site`.

Best,

Igal



>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sIa8ACgkQHPApP6U8
> pFhjkA/8DLMqIHgF130aGL2YXWuG5OKl/WHh1NFUHhcWHg1zu4zosaMeqExcxFdM
> 20kE44WjbcD0kvAEeAvR6ejOLm1S7lfXzCs41ZnJI6v4wyhEfp+n9gfYESF3kZqU
> 5v4IhD0XBspp60iom2BVggF61qu2ZIE9BCD+zv5ikELni4+psg1T7WkTomtIj8Id
> W0A+QGMnsYyAGZpqxPRM3agn/T2A+pbsQKFTfqX8KEot+m00PrEy5HRjeYCRpm4Y
> OtlHrPLhrOutS7M3K8b191BPf7I55pGEfsq7rSHnpD0H+KM4ur9v6tHtWNutwVTY
> 3Y2Fs357Cckr+jU0YpBEDn/2jmHioiShMYNmchalkvbXCiCESzgzhr5oazU7tp9j
> et7zFy3XlJ1e0fJ3vq/LQnu6HqCwPRPaF27h8hyVrLSzatrPb9Cb2/AGr3SaHonK
> 9YmpziI1MR4i358y3cxeVIaTMal6MDAjRn8fIfQxxm3k5PZiHb+aMNd4Mion11xH
> SqVAep9FyV9V0AbikoazTzUApPBosiD0onioq3o6ApSVfdaa+shh2jmI2JFzRGkf
> Unpb3xGRye3EZZVjwXCDw0QJ2UVx65gM7k5W0xvUr0IOmSjJVLBpi1Z1Zv7ijNN0
> nj8x3UUTNrABK8PniUIZ+xafoRFlPv4RDGcf6laCdks5R5y31+8=
> =8Ax9
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[GitHub] [tomcat] MilovdZee commented on pull request #336: Fix SSHA documentation and cleanup the code

2020-08-07 Thread GitBox



MilovdZee commented on pull request #336:
URL: https://github.com/apache/tomcat/pull/336#issuecomment-670671787


   Strange. Travis starts to fail... And at unrelated locations...



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JDK 15 is now in the Initial Release Candidate Phase

2020-08-07 Thread Rory O'Donnell


Many Thanks Martin!

Rgds,Rory

On 07/08/2020 14:13, Martin Grigorov wrote:

Hi Rory,

The Apache Tomcat build and tests are fine with JDK 15+35-1559 and JDK 
16-ea+9-365 both on x86_64 and aarch64 architectures!


Regards,
Martin

On Fri, Aug 7, 2020 at 12:01 PM Rory O'Donnell 
mailto:rory.odonn...@oracle.com>> wrote:



Hi Mark,

*Per the JDK 15 schedule  , we are now in the Initial Release
Candidate Phase
*


***Please advise if you have any open high priority issues.***

  * Schedule for JDK 15
  o *2020/08/06 Initial Release Candidate*
  o 2020/08/20 Final Release Candidate
  o 2020/09/15 General Availability

**

  * The overall feature set is frozen.
  o Per the JDK Release Process [1] we now turn our focus to
P1 bugs.
  * Features included in JDK 15:
  o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)

  o JEP 360: Sealed Classes (Preview)

  o JEP 371: Hidden Classes 
  o JEP 372: Remove the Nashorn JavaScript Engine

  o JEP 373: Reimplement the Legacy DatagramSocket API

  o JEP 374: Disable and Deprecate Biased Locking

  o JEP 375: Pattern Matching for instanceof (Second Preview)

  o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector

  o JEP 378: Text Blocks 
  o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector

  o JEP 381: Remove the Solaris and SPARC Ports

  o JEP 383: Foreign-Memory Access API (Second Incubator)

  o JEP 384: Records (Second Preview)

  o JEP 385: Deprecate RMI Activation for Removal


*JDK 15 **Early Access build 35 *is now available at
http://jdk.java.net/15

  * Release notes
  o http://jdk.java.net/15/release-notes
  * Recent fixes that might be of interest
  o Build 34
  + JDK-8246094: [macos] Sound Recording and playback is
not working

*JDK 16 Early Access build 9 ***is now available at
http://jdk.java.net/16

  * JEP Candidate
  o JEP 388: Windows/AArch64 Port

  * JEPs targeted to JDK 16, so far:
  o JEP 369: Migrate to GitHub 
  o JEP 357: Migrate from Mercurial to Git

  o JEP 347: Enable C++14 Language Features


**

  * Recent fixes that might be of interest
 o

Build 9

  + JDK-8243320: Add SSL root certificates to Oracle Root
CA program
  + JDK-8243321: Add Entrust root CA - G4 to Oracle Root
CA program
  o Build 8
  + JDK-8246094: [macos] Sound Recording and playback is
not working
  + JDK-8248655: Support supplementary characters in
String case insensitive operations
  o Build 7
  + JDK-8246032: Implementation of JEP 347: Enable C++14
Language Features


*__*
Rgds,Rory

 [1] http://openjdk.java.net/jeps/3

-- 
Rgds, Rory O'Donnell

Quality Engineering Manager
Oracle EMEA, Dublin, Ireland


--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

[GitHub] [tomcat] MilovdZee commented on a change in pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



MilovdZee commented on a change in pull request #336:
URL: https://github.com/apache/tomcat/pull/336#discussion_r467140671



##
File path: java/org/apache/catalina/realm/MessageDigestCredentialHandler.java
##
@@ -32,16 +32,13 @@
 /**
  * This credential handler supports the following forms of stored passwords:
  * 
- * encodedCredential - a hex encoded digest of the password digested
- * using the configured digest
- * {MD5}encodedCredential - a Base64 encoded MD5 digest of the
- * password
- * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the
- * password
- * {SSHA}encodedCredential - 20 character salt followed by the 
salted
- * SHA1 digest Base64 encoded
- * salt$iterationCount$encodedCredential - a hex encoded salt,
- * iteration code and a hex encoded credential, each separated by $
+ * encodedCredential - a hex encoded digest of the password 
digested using the configured digest
+ * {MD5}encodedCredential - a Base64 encoded MD5 digest of the 
password
+ * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the 
password
+ * {SSHA}encodedCredential - 20 character SHA1 digest Base64 
encoded followed by salt
+ * {SSHA2}encodedCredential - 20 character salt followed by the 
salted digest Base64 encoded

Review comment:
   > What does `{SSHAv2}` add that the existing `salt$iteration$hash` 
doesn't already provide?
   
   I would have preferred to do the SSHA implementation differently but that 
would break backward compatibility. So I choose SSHAv2... 
   
   I agree that I'm now using the `salt$iteration$hash` way and indeed SSHAv2 
does not add functionality. Adding SSHAv2 introduces yet another option and 
needs support...
   
   Maybe better to refactor the existing code to be more readable?
   
   But why allow the algorithm to be set when the SSHA only works when it is 
set to SHA-1? I did not know that SSHA was something of a standard and I now 
see that the implementation is indeed correct. Only the javadoc is incorrect.
   
   I'll just do a refactor of the implementation and fix the javadoc then. And 
I won't add the SSHAv2 option.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] MilovdZee commented on a change in pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



MilovdZee commented on a change in pull request #336:
URL: https://github.com/apache/tomcat/pull/336#discussion_r467133771



##
File path: java/org/apache/catalina/realm/MessageDigestCredentialHandler.java
##
@@ -32,16 +32,13 @@
 /**
  * This credential handler supports the following forms of stored passwords:
  * 
- * encodedCredential - a hex encoded digest of the password digested
- * using the configured digest
- * {MD5}encodedCredential - a Base64 encoded MD5 digest of the
- * password
- * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the
- * password
- * {SSHA}encodedCredential - 20 character salt followed by the 
salted
- * SHA1 digest Base64 encoded
- * salt$iterationCount$encodedCredential - a hex encoded salt,
- * iteration code and a hex encoded credential, each separated by $
+ * encodedCredential - a hex encoded digest of the password 
digested using the configured digest
+ * {MD5}encodedCredential - a Base64 encoded MD5 digest of the 
password
+ * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the 
password
+ * {SSHA}encodedCredential - 20 character SHA1 digest Base64 
encoded followed by salt
+ * {SSHA2}encodedCredential - 20 character salt followed by the 
salted digest Base64 encoded

Review comment:
   Fixed. I started by using SSHA2 but that suggested that it used SHA-2 
what is not the case. It could use SHA-2 but it could just as well use SHA-512.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] MilovdZee commented on pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



MilovdZee commented on pull request #336:
URL: https://github.com/apache/tomcat/pull/336#issuecomment-670590235


   True. With SHA-1 it works. But the documentation does not enforce SHA-1. 
Even the code suggests that longer digests should be possible. But because of 
the implementation only algorithms with 20 bytes work. The salt could be 
variable in length though.
   
   final int saltPos = 20;
   byte[] serverDigestBytes = new byte[saltPos];
   
   This forces the digest to be 20 bytes but that is only true for SHA-1. And 
it looks strange to use the saltPos to define the digest length.
   
   final int saltLength = serverDigestPlusSaltBytes.length - saltPos;
   
   This also indicates that the digest is of fixed length and that the salt is 
of variable length. I'm not a crypto guru but I would assume the length of the 
salt to be algorithm independent and the digest to be variable in length. 
Depending on the algorithm.
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] ChristopherSchultz commented on a change in pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



ChristopherSchultz commented on a change in pull request #336:
URL: https://github.com/apache/tomcat/pull/336#discussion_r467125860



##
File path: java/org/apache/catalina/realm/MessageDigestCredentialHandler.java
##
@@ -32,16 +32,13 @@
 /**
  * This credential handler supports the following forms of stored passwords:
  * 
- * encodedCredential - a hex encoded digest of the password digested
- * using the configured digest
- * {MD5}encodedCredential - a Base64 encoded MD5 digest of the
- * password
- * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the
- * password
- * {SSHA}encodedCredential - 20 character salt followed by the 
salted
- * SHA1 digest Base64 encoded
- * salt$iterationCount$encodedCredential - a hex encoded salt,
- * iteration code and a hex encoded credential, each separated by $
+ * encodedCredential - a hex encoded digest of the password 
digested using the configured digest
+ * {MD5}encodedCredential - a Base64 encoded MD5 digest of the 
password
+ * {SHA}encodedCredential - a Base64 encoded SHA1 digest of the 
password
+ * {SSHA}encodedCredential - 20 character SHA1 digest Base64 
encoded followed by salt
+ * {SSHA2}encodedCredential - 20 character salt followed by the 
salted digest Base64 encoded

Review comment:
   Javadoc says `SSHA2` but code uses `{SSHAv2}`.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] ChristopherSchultz edited a comment on pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



ChristopherSchultz edited a comment on pull request #336:
URL: https://github.com/apache/tomcat/pull/336#issuecomment-670585072


   While the documentation may have been misleading, the implementation was 
correct: the stored credential is a literal `{SSHA}` + 
`base64(concat(sha1(concat(password, salt)), salt)`. I'm not sure this "fixes" 
anything; maybe it just adds another implementation.
   
   The salt length is not fixed at 20 characters. Tomcat doesn't generate new 
stored-credentials, so the salt for a `{SSHA}`-encoded credential is whatever 
is left over after the 20 bytes of the SHA1 hash has been removed from the 
front of the credential. (This is why the salt is somewhat confusingly placed 
at the end of the stored-credential.)
   
   Your new implementation creates `{SSHAv2}` (or `{SSHA2}`?), which AFAIK 
doesn't implement any widespread standard at all. `{SHA}` and `{SSHA}` are 
fairly widespread.
   
   What does `{SSHAv2}` add that the existing `salt$iteration$hash` doesn't 
already provide?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] ChristopherSchultz edited a comment on pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



ChristopherSchultz edited a comment on pull request #336:
URL: https://github.com/apache/tomcat/pull/336#issuecomment-670585072


   While the documentation may have been misleading, the implementation was 
correct: the stored credential is a literal `{SSHA}` + 
`base64(concat(sha1(concat(password, salt)), salt)`. I'm not sure this "fixes" 
anything; maybe it just adds another implementation.
   
   The salt length is not fixed at 20 characters. Tomcat doesn't generate new 
stored-credentials, so the salt for a `{SSHA}`-encoded credential is whatever 
is left over after the 20 bytes of the SHA1 hash has been removed from the 
front of the credential. (This is why the salt is somewhat confusingly placed 
at the end of the stored-credential.)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] ChristopherSchultz commented on pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



ChristopherSchultz commented on pull request #336:
URL: https://github.com/apache/tomcat/pull/336#issuecomment-670585072


   While the documentation may have been misleading, the implementation was 
correct: the stored credential is a literal `{SSHA}` + 
`base64(concat(sha1(concat(password, salt)), salt)`. I'm not sure this "fixes" 
anything; maybe it just adds another implementation.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] MilovdZee opened a new pull request #336: fix SSHA by implementing SSHAv2

2020-08-07 Thread GitBox



MilovdZee opened a new pull request #336:
URL: https://github.com/apache/tomcat/pull/336


   For SSHA the order of salt and digest was reverse to the documentation. It 
actually was "{SSHA}".
   
   I added SSHAv2 to also allow for SHA-256 and other algorithms. I introduced 
{SSHAv2} for this. SSHA keeps on working like it did so the change it backward 
compatible.
   
   The same holds for tomcat-10 but let us first fix the 9.x.x branch. If 
accepted I'll also create a 10.x.x PR.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: JDK 15 is now in the Initial Release Candidate Phase

2020-08-07 Thread Martin Grigorov

Hi Rory,

The Apache Tomcat build and tests are fine with JDK 15+35-1559 and JDK
16-ea+9-365 both on x86_64 and aarch64 architectures!

Regards,
Martin

On Fri, Aug 7, 2020 at 12:01 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
>
> *Per the JDK 15 schedule  , we are now in the Initial Release Candidate
> Phase *
>
>
> *Please advise if you have any open high priority issues.*
>
>- Schedule for JDK 15
>   - *2020/08/06 Initial Release Candidate*
>   - 2020/08/20 Final Release Candidate
>   - 2020/09/15 General Availability
>
>
>- The overall feature set is frozen.
>   - Per the JDK Release Process [1] we now turn our focus to P1 bugs.
>- Features included in JDK 15:
>   - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>   
>   - JEP 360: Sealed Classes (Preview)
>   
>   - JEP 371: Hidden Classes 
>   - JEP 372: Remove the Nashorn JavaScript Engine
>   
>   - JEP 373: Reimplement the Legacy DatagramSocket API
>   
>   - JEP 374: Disable and Deprecate Biased Locking
>   
>   - JEP 375: Pattern Matching for instanceof (Second Preview)
>   
>   - JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>   
>   - JEP 378: Text Blocks 
>   - JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
>   
>   - JEP 381: Remove the Solaris and SPARC Ports
>   
>   - JEP 383: Foreign-Memory Access API (Second Incubator)
>   
>   - JEP 384: Records (Second Preview)
>   
>   - JEP 385: Deprecate RMI Activation for Removal
>   
>
> *JDK 15 **Early Access build 35 *is now available at
> http://jdk.java.net/15
>
>- Release notes
>- http://jdk.java.net/15/release-notes
>- Recent fixes that might be of interest
>   - Build 34
>   - JDK-8246094: [macos] Sound Recording and playback is not working
>
> *JDK 16 Early Access build 9 *is now available at http://jdk.java.net/16
>
>- JEP Candidate
>   - JEP 388: Windows/AArch64 Port 
>- JEPs targeted to JDK 16, so far:
>   - JEP 369: Migrate to GitHub 
>   - JEP 357: Migrate from Mercurial to Git
>   
>   - JEP 347: Enable C++14 Language Features
>   
>
>
>- Recent fixes that might be of interest
>   -
>
>   Build 9
>   - JDK-8243320: Add SSL root certificates to Oracle Root CA program
>  - JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program
>   - Build 8
>   - JDK-8246094: [macos] Sound Recording and playback is not working
>  - JDK-8248655: Support supplementary characters in String case
>  insensitive operations
>   - Build 7
>  - JDK-8246032: Implementation of JEP 347: Enable C++14 Language
>  Features
>
>
> Rgds,Rory
>
> [1] http://openjdk.java.net/jeps/3
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

[GitHub] [tomcat] MilovdZee commented on pull request #335: Message digest credential handler fix

2020-08-07 Thread GitBox



MilovdZee commented on pull request #335:
URL: https://github.com/apache/tomcat/pull/335#issuecomment-670498590


   oops. wrong master



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] MilovdZee closed pull request #335: Message digest credential handler fix

2020-08-07 Thread GitBox



MilovdZee closed pull request #335:
URL: https://github.com/apache/tomcat/pull/335


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[GitHub] [tomcat] MilovdZee opened a new pull request #335: Message digest credential handler fix

2020-08-07 Thread GitBox



MilovdZee opened a new pull request #335:
URL: https://github.com/apache/tomcat/pull/335


   For SSHA the order of salt and digest was reverse to the documentation. It 
was "{SSHA}".
   
   I added SSHA2 to also allow for SHA-256 and other algorithms. I introduced 
{SSHA2} for this. It could be confusing because it also support SHA-512 and 
others.
   
   The same holds for tomcat-10 but let us first fix the 9.x.x branch. If 
accepted I'll also create a 10.x.x PR.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

JDK 15 is now in the Initial Release Candidate Phase

2020-08-07 Thread Rory O'Donnell



Hi Mark,

*Per the JDK 15 schedule  , we are now in the Initial Release Candidate 
Phase

*


***Please advise if you have any open high priority issues.***

 * Schedule for JDK 15
 o *2020/08/06 Initial Release Candidate*
 o 2020/08/20 Final Release Candidate
 o 2020/09/15 General Availability

**

 * The overall feature set is frozen.
 o Per the JDK Release Process [1] we now turn our focus to P1 bugs.
 * Features included in JDK 15:
 o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
   
 o JEP 360: Sealed Classes (Preview) 
 o JEP 371: Hidden Classes 
 o JEP 372: Remove the Nashorn JavaScript Engine
   
 o JEP 373: Reimplement the Legacy DatagramSocket API
   
 o JEP 374: Disable and Deprecate Biased Locking
   
 o JEP 375: Pattern Matching for instanceof (Second Preview)
   
 o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
   
 o JEP 378: Text Blocks 
 o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
   
 o JEP 381: Remove the Solaris and SPARC Ports
   
 o JEP 383: Foreign-Memory Access API (Second Incubator)
   
 o JEP 384: Records (Second Preview)
   
 o JEP 385: Deprecate RMI Activation for Removal
   

*JDK 15 **Early Access build 35 *is now available at http://jdk.java.net/15

 * Release notes
 o http://jdk.java.net/15/release-notes
 * Recent fixes that might be of interest
 o Build 34
 + JDK-8246094: [macos] Sound Recording and playback is not working

*JDK 16 Early Access build 9 ***is now available at http://jdk.java.net/16

 * JEP Candidate
 o JEP 388: Windows/AArch64 Port 
 * JEPs targeted to JDK 16, so far:
 o JEP 369: Migrate to GitHub 
 o JEP 357: Migrate from Mercurial to Git
   
 o JEP 347: Enable C++14 Language Features
   

**

 * Recent fixes that might be of interest
 o

   Build 9

 + JDK-8243320: Add SSL root certificates to Oracle Root CA program
 + JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program
 o Build 8
 + JDK-8246094: [macos] Sound Recording and playback is not working
 + JDK-8248655: Support supplementary characters in String case
   insensitive operations
 o Build 7
 + JDK-8246032: Implementation of JEP 347: Enable C++14
   Language Features


*__*
Rgds,Rory

 [1] http://openjdk.java.net/jeps/3

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

Re: Publishing EOL dates on whichversion?

[GitHub] [tomcat] MilovdZee commented on pull request #336: Fix SSHA documentation and cleanup the code

Re: JDK 15 is now in the Initial Release Candidate Phase

[GitHub] [tomcat] MilovdZee commented on a change in pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] MilovdZee commented on a change in pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] MilovdZee commented on pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] ChristopherSchultz commented on a change in pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] ChristopherSchultz edited a comment on pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] ChristopherSchultz edited a comment on pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] ChristopherSchultz commented on pull request #336: fix SSHA by implementing SSHAv2

[GitHub] [tomcat] MilovdZee opened a new pull request #336: fix SSHA by implementing SSHAv2

Re: JDK 15 is now in the Initial Release Candidate Phase

[GitHub] [tomcat] MilovdZee commented on pull request #335: Message digest credential handler fix

[GitHub] [tomcat] MilovdZee closed pull request #335: Message digest credential handler fix

[GitHub] [tomcat] MilovdZee opened a new pull request #335: Message digest credential handler fix

JDK 15 is now in the Initial Release Candidate Phase

16 matches

Site Navigation

Mail list logo

Footer information