OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Rory O'Donnell 


Hi Mark,

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


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 

 * Schedule (proposed)
 o 2021/06/10         Rampdown Phase One
 o 2021/07/15         Rampdown Phase Two
 o 2021/08/05         Initial Release Candidate
 o 2021/08/19         Final Release Candidate
 o 2021/09/14         General Availability

 * Features:*Heads-up on an important Candidate JEP
   *
 o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
   *
 o successor to JEP 396: Strongly Encapsulate JDK Internals by
   Default 
 o strongly encapsulate all internal elements of the JDK by default
 o exception for Critical Internal APIs such as /sun.misc.Unsafe/

 * JEPs targeted to JDK 17, so far:
 o JEP 356: Enhanced Pseudo-Random Number Generators
   
 o JEP 382: New macOS Rendering Pipeline
   
 o JEP 391: macOS/AArch64 Port 
 o JEP 398: Deprecate the Applet API for Removal
   

 * Release Notes are available at http://jdk.java.net/17/release-notes
   
 * Changes in recent builds that maybe of interest:
 o Build 16
 + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
   device throws FileSystemException: "nul: Incorrect function"
   (win)
 # Reported by Apache Ant
 o Build 15
 + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
   prevents dnf install/updates
 o Build 14
 + JDK-8262277: URLClassLoader.getResource throws undocumented
   IllegalArgumentException
 + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
   conversion with a sign character

*Project Loom Early-Access Build: **Build 17-loom+5-191* 
*(2021/3/19)*


 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   .
 * These builds are produced for the purpose of gathering feedback. Use
   for any other purpose is at your own risk.
 * Please send feedback via e-mail to loom-...@openjdk.java.net
   . To send e-mail to this address
   you must first subscribe to the mailing list
   .

*Quality Report for March 2021 was published here [1]*.

 * Thanks to everyone who contributed by creating features or
   enhancements, logging  bugs, or downloading and testing the
   early-access builds.

*Worth reading - **The Arrival of Java 16! 
*


 * JDK 16 Migration guide -
   https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
 * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
   respond to this *tweet
   *.
 * Oracle Developer Live event - Individual sessions:
1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
   https://youtu.be/1acKCBbd6f4 
2. *Java Language Futures: Spring 2021* (Gavin Bierman):
   https://youtu.be/K9SVV0XNIP8 
3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
   Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
   
4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
   *https://youtu.be/1hyWJTjxeGM **
5. *How Records Can Improve Serialization* (Julia Boes, Chris
   Hegarty): https://youtu.be/44D8M6ZxuLU
   
6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
   Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
   
7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
   https://youtu.be/bHcKTYy_Nec 
8. *Project Skara: Migrating OpenJDK to Git and GitHub* (Erik
   Duveblad, Robin Westberg): https://youtu.be/-pBgplk7fVk
   
9. *Monitoring and Troubleshooting Tools in the JDK* (Poonam
   Parhar): https://youtu.be/mcfubUmbZhQ 
   10. *Fast and Efficient Microservices for Java with GraalVM* (Alina
   Yurenko): https://youtu.be/_eRD6qJqtNw
   
   11. *Accelerating Productivity with Micronaut and Java Records*
   (Graeme Rocher): https://youtu.be/RoNeoX

Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Rémy Maucherat 
On Fri, Apr 2, 2021 at 10:09 AM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *OpenJDK 17 Early Access build 16 is now available at
> **http://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>
>   * Schedule (proposed)
>   o 2021/06/10 Rampdown Phase One
>   o 2021/07/15 Rampdown Phase Two
>   o 2021/08/05 Initial Release Candidate
>   o 2021/08/19 Final Release Candidate
>   o 2021/09/14 General Availability
>
>   * Features:*Heads-up on an important Candidate JEP
> *
>   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
> *
>   o successor to JEP 396: Strongly Encapsulate JDK Internals by
> Default 
>   o strongly encapsulate all internal elements of the JDK by default
>   o exception for Critical Internal APIs such as /sun.misc.Unsafe/
>

Our use of Unsafe does indeed seem to still work, and the testsuite and
OpenSSL TLS support is still functional.
It would be good to get a better method to deallocate a direct ByteBuffer,
eventually ...

Rémy


>
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o Build 16
>   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
> device throws FileSystemException: "nul: Incorrect function"
> (win)
>   # Reported by Apache Ant
>   o Build 15
>   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
> prevents dnf install/updates
>   o Build 14
>   + JDK-8262277: URLClassLoader.getResource throws undocumented
> IllegalArgumentException
>   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
> conversion with a sign character
>
> *Project Loom Early-Access Build: **Build 17-loom+5-191*
> *(2021/3/19)*
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> .
>   * These builds are produced for the purpose of gathering feedback. Use
> for any other purpose is at your own risk.
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> *Quality Report for March 2021 was published here [1]*.
>
>   * Thanks to everyone who contributed by creating features or
> enhancements, logging  bugs, or downloading and testing the
> early-access builds.
>
> *Worth reading - **The Arrival of Java 16!
> *
>
>   * JDK 16 Migration guide -
> https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
>   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
> respond to this *tweet
> *.
>   * Oracle Developer Live event - Individual sessions:
>  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
> https://youtu.be/1acKCBbd6f4 
>  2. *Java Language Futures: Spring 2021* (Gavin Bierman):
> https://youtu.be/K9SVV0XNIP8 
>  3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
> Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
> 
>  4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
> *https://youtu.be/1hyWJTjxeGM **
>  5. *How Records Can Improve Serialization* (Julia Boes, Chris
> Hegarty): https://youtu.be/44D8M6ZxuLU
> 
>  6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
> Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
> 
>  7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
> https://youtu.be/bHcKTYy_Nec 
>  8. *Project Skara: Migrating OpenJDK to Git and Gi

Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Martin Grigorov 
Hi Rory,

Apache Tomcat 10.x build and tests pass successfully with JDK 17-ea+16-1315
on Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Apr 2, 2021 at 11:02 AM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *OpenJDK 17 Early Access build 16 is now available at
> **http://jdk.java.net/17* 
>
>   * These early-access , open-source builds are provided under the
>   o GNU General Public License, version 2, with the Classpath
> Exception 
>
>   * Schedule (proposed)
>   o 2021/06/10 Rampdown Phase One
>   o 2021/07/15 Rampdown Phase Two
>   o 2021/08/05 Initial Release Candidate
>   o 2021/08/19 Final Release Candidate
>   o 2021/09/14 General Availability
>
>   * Features:*Heads-up on an important Candidate JEP
> *
>   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
> *
>   o successor to JEP 396: Strongly Encapsulate JDK Internals by
> Default 
>   o strongly encapsulate all internal elements of the JDK by default
>   o exception for Critical Internal APIs such as /sun.misc.Unsafe/
>
>   * JEPs targeted to JDK 17, so far:
>   o JEP 356: Enhanced Pseudo-Random Number Generators
> 
>   o JEP 382: New macOS Rendering Pipeline
> 
>   o JEP 391: macOS/AArch64 Port 
>   o JEP 398: Deprecate the Applet API for Removal
> 
>
>   * Release Notes are available at http://jdk.java.net/17/release-notes
> 
>   * Changes in recent builds that maybe of interest:
>   o Build 16
>   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
> device throws FileSystemException: "nul: Incorrect function"
> (win)
>   # Reported by Apache Ant
>   o Build 15
>   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
> prevents dnf install/updates
>   o Build 14
>   + JDK-8262277: URLClassLoader.getResource throws undocumented
> IllegalArgumentException
>   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
> conversion with a sign character
>
> *Project Loom Early-Access Build: **Build 17-loom+5-191*
> *(2021/3/19)*
>
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> .
>   * These builds are produced for the purpose of gathering feedback. Use
> for any other purpose is at your own risk.
>   * Please send feedback via e-mail to loom-...@openjdk.java.net
> . To send e-mail to this address
> you must first subscribe to the mailing list
> .
>
> *Quality Report for March 2021 was published here [1]*.
>
>   * Thanks to everyone who contributed by creating features or
> enhancements, logging  bugs, or downloading and testing the
> early-access builds.
>
> *Worth reading - **The Arrival of Java 16!
> *
>
>   * JDK 16 Migration guide -
> https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
>   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
> respond to this *tweet
> *.
>   * Oracle Developer Live event - Individual sessions:
>  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
> https://youtu.be/1acKCBbd6f4 
>  2. *Java Language Futures: Spring 2021* (Gavin Bierman):
> https://youtu.be/K9SVV0XNIP8 
>  3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
> Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
> 
>  4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:
> *https://youtu.be/1hyWJTjxeGM **
>  5. *How Records Can Improve Serialization* (Julia Boes, Chris
> Hegarty): https://youtu.be/44D8M6ZxuLU
> 
>  6. *Vector API: SIMD Programming in Java* (Paul Sandoz, Sandhya
> Viswanathan[Intel]): https://youtu.be/VYo3p4R66N8
> 
>  7. *Your Guide to OpenJDK Development* (Jesper Wilhelmsson):
> https://youtu.be/bHcKTYy_Nec 
>  8. *Project Skara: Migrating OpenJDK to Git and GitHub* (Erik
> Duveblad, Robin Westberg): https://youtu.be/-pBgplk7fVk
>

Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Martin Grigorov 
On Fri, Apr 2, 2021 at 12:19 PM Rémy Maucherat  wrote:

> On Fri, Apr 2, 2021 at 10:09 AM Rory O'Donnell 
> wrote:
>
> >
> > Hi Mark,
> >
> > *OpenJDK 17 Early Access build 16 is now available at
> > **http://jdk.java.net/17* 
> >
> >   * These early-access , open-source builds are provided under the
> >   o GNU General Public License, version 2, with the Classpath
> > Exception 
> >
> >   * Schedule (proposed)
> >   o 2021/06/10 Rampdown Phase One
> >   o 2021/07/15 Rampdown Phase Two
> >   o 2021/08/05 Initial Release Candidate
> >   o 2021/08/19 Final Release Candidate
> >   o 2021/09/14 General Availability
> >
> >   * Features:*Heads-up on an important Candidate JEP
> > *
> >   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
> > *
> >   o successor to JEP 396: Strongly Encapsulate JDK Internals by
> > Default 
> >   o strongly encapsulate all internal elements of the JDK by default
> >   o exception for Critical Internal APIs such as /sun.misc.Unsafe/
> >
>
> Our use of Unsafe does indeed seem to still work, and the testsuite and
> OpenSSL TLS support is still functional.
> It would be good to get a better method to deallocate a direct ByteBuffer,
> eventually ...
>

This has been mentioned recently at
https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005269.html

"Finally, a related point: The sun.misc package has been exported and

available for reflection since JDK 9. It was neither removed nor
strongly encapsulated in JDK 9. It was available in JDK 9, and continues

to be available in JDK 17."


> Rémy
>
>
> >
> >   * JEPs targeted to JDK 17, so far:
> >   o JEP 356: Enhanced Pseudo-Random Number Generators
> > 
> >   o JEP 382: New macOS Rendering Pipeline
> > 
> >   o JEP 391: macOS/AArch64 Port 
> >   o JEP 398: Deprecate the Applet API for Removal
> > 
> >
> >   * Release Notes are available at http://jdk.java.net/17/release-notes
> > 
> >   * Changes in recent builds that maybe of interest:
> >   o Build 16
> >   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
> > device throws FileSystemException: "nul: Incorrect function"
> > (win)
> >   # Reported by Apache Ant
> >   o Build 15
> >   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
> > prevents dnf install/updates
> >   o Build 14
> >   + JDK-8262277: URLClassLoader.getResource throws undocumented
> > IllegalArgumentException
> >   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
> > conversion with a sign character
> >
> > *Project Loom Early-Access Build: **Build 17-loom+5-191*
> > *(2021/3/19)*
> >
> >   * These early-access builds are provided under the GNU General Public
> > License, version 2, with the Classpath Exception
> > .
> >   * These builds are produced for the purpose of gathering feedback. Use
> > for any other purpose is at your own risk.
> >   * Please send feedback via e-mail to loom-...@openjdk.java.net
> > . To send e-mail to this address
> > you must first subscribe to the mailing list
> > .
> >
> > *Quality Report for March 2021 was published here [1]*.
> >
> >   * Thanks to everyone who contributed by creating features or
> > enhancements, logging  bugs, or downloading and testing the
> > early-access builds.
> >
> > *Worth reading - **The Arrival of Java 16!
> > *
> >
> >   * JDK 16 Migration guide -
> >
> https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
> >   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
> > respond to this *tweet
> > *.
> >   * Oracle Developer Live event - Individual sessions:
> >  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
> > https://youtu.be/1acKCBbd6f4 
> >  2. *Java Language Futures: Spring 2021* (Gavin Bierman):
> > https://youtu.be/K9SVV0XNIP8 
> >  3. *Ask the Java Architects* (Mark Reinhold, Brian Goetz, Mikael
> > Vidstedt, Ron Pressler): https://youtu.be/CVE4bWvuD3o
> > 
> >  4. *Learn Java 16 with IntelliJ IDEA *(Trisha Gee[JetBrains])*:

Re: [VOTE] Release Apache Tomcat Native 1.2.28

2021-04-02 Thread Martin Grigorov 
On Thu, Apr 1, 2021 at 4:56 PM Mark Thomas  wrote:

> Version 1.2.28 includes the following changes compared to 1.2.27
>
> - Correct regression in previous fix for BZ 65181
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.28 release is
>   [ X ] Stable, go ahead and release
>   [ ] Broken because of ...
>
>
Tested build on Linux x86_64 and aarch64, and runtime usage on aarch64 with
HTTP2 - "INFO: The ["https-openssl-apr-8080"] connector has been configured
to support negotiation to [h2] via ALPN"

Regards,
Martin

Thanks,
>
> Mark
>
>
> [1]
>
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.28
> [2]
>
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=5566385ab63361d8d707613508d803964a15a1f8
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [External] : Re: OpenJDK 17 Early Access build 16 is now available

2021-04-02 Thread Rory O'Donnell 

Many thanks Martin!

On 02/04/2021 12:02, Martin Grigorov wrote:

Hi Rory,

Apache Tomcat 10.x build and tests pass successfully with JDK 17-ea+16-1315
on Linux x86_64 and aarch64!

Regards,
Martin

On Fri, Apr 2, 2021 at 11:02 AM Rory O'Donnell 
wrote:


Hi Mark,

*OpenJDK 17 Early Access build 16 is now available at
**https://urldefense.com/v3/__http://jdk.java.net/17*__;Kg!!GqivPVa7Brio!JtIYu-pMxzTz33powYipMa1qHMPIBh7bRmZhkuvoq594AH2gyIJu_tCblqw0Dqf9JC4$
  


   * These early-access , open-source builds are provided under the
   o GNU General Public License, version 2, with the Classpath
 Exception 

   * Schedule (proposed)
   o 2021/06/10 Rampdown Phase One
   o 2021/07/15 Rampdown Phase Two
   o 2021/08/05 Initial Release Candidate
   o 2021/08/19 Final Release Candidate
   o 2021/09/14 General Availability

   * Features:*Heads-up on an important Candidate JEP
 *
   o *Candidate - JEP 403: **Strongly Encapsulate JDK Internals
 *
   o successor to JEP 396: Strongly Encapsulate JDK Internals by
 Default 
   o strongly encapsulate all internal elements of the JDK by default
   o exception for Critical Internal APIs such as /sun.misc.Unsafe/

   * JEPs targeted to JDK 17, so far:
   o JEP 356: Enhanced Pseudo-Random Number Generators
 
   o JEP 382: New macOS Rendering Pipeline
 
   o JEP 391: macOS/AArch64 Port 
   o JEP 398: Deprecate the Applet API for Removal
 

   * Release Notes are available at 
https://urldefense.com/v3/__http://jdk.java.net/17/release-notes__;!!GqivPVa7Brio!JtIYu-pMxzTz33powYipMa1qHMPIBh7bRmZhkuvoq594AH2gyIJu_tCblqw07TG4Gwg$
 

   * Changes in recent builds that maybe of interest:
   o Build 16
   + JDK-8263898: (fs) Files.newOutputStream on the "NUL" special
 device throws FileSystemException: "nul: Incorrect function"
 (win)
   # Reported by Apache Ant
   o Build 15
   + JDK-8263575: Conflict between JDK rpms and OL8 Modularity
 prevents dnf install/updates
   o Build 14
   + JDK-8262277: URLClassLoader.getResource throws undocumented
 IllegalArgumentException
   + JDK-8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character

*Project Loom Early-Access Build: **Build 17-loom+5-191*
*(2021/3/19)*

   * These early-access builds are provided under the GNU General Public
 License, version 2, with the Classpath Exception
 .
   * These builds are produced for the purpose of gathering feedback. Use
 for any other purpose is at your own risk.
   * Please send feedback via e-mail to loom-...@openjdk.java.net
 . To send e-mail to this address
 you must first subscribe to the mailing list
 .

*Quality Report for March 2021 was published here [1]*.

   * Thanks to everyone who contributed by creating features or
 enhancements, logging  bugs, or downloading and testing the
 early-access builds.

*Worth reading - **The Arrival of Java 16!
*

   * JDK 16 Migration guide -
 https://docs.oracle.com/en/java/javase/16/migrate/getting-started.html
   * #AllTestsGreenOnJDK16 - If your tests are green on JDK 16 please
 respond to this *tweet
 
*.
   * Oracle Developer Live event - Individual sessions:
  1. *Java 16: Consistency and Innovation* (Aurelio Garcia-Ribeyro):
 
https://urldefense.com/v3/__https://youtu.be/1acKCBbd6f4__;!!GqivPVa7Brio!JtIYu-pMxzTz33powYipMa1qHMPIBh7bRmZhkuvoq594AH2gyIJu_tCblqw0ldSnaRk$
  

  2. *Java Language Futures: Sp

Re: TCK Signature for EL API

2021-04-02 Thread Raymond Augé 
I just wanted to make a note that removing the annotation will also mean
that the module-info.java will need to be manually managed since bnd also
generated that based on the annotations.

Just FYI,
- Ray

On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO 
wrote:

> That's awesome news.
>
> I'm glad it's something that can be achieved without too much effort.
> I understand and buy the pragmatic approach.
>
> But at the same time, if we can do a step forward and get even closer to
> being certified, that'd be great.
>
> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :
>
> > I've been playing with this a bit more and it appears we can simply
> > hard-code the "Require-Capability" header in el-api.jar.bnd
> >
> > Having taken the time to look at the actual values generated for these
> > API JARs, this does look like something that would be simple to maintain
> > manually - especially for the API JARs where adding a new use of
> > ServiceLoader is likely to happen fairly rarely.
> >
> > We should be able to remove the Bnd annotation in
> > - 10.0.x for 10.0.6 onwards
> > - 9.0.x for 9.0.46 onwards
> >
> > We'll certainly do this for the API JARs. I think we'll leave it in
> > place for the implementation JARs
> >
> > I have a few things on my TODO list at the moment but I don't see why I
> > shouldn't be able to get this done for the May set of releases.
> >
> > Mark
> >
> >
> > On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> > > Hi,
> > >
> > > AFAIK TomEE will try to be certified and will try to not fork as much
> as
> > > possible Tomcat code so can be neat to solve it in particular when
> > > relatively easy:
> > >
> > > 1. compile tomcat classes with bnd as of today
> > > 2. run bnd to get the manifest.mf (
> > > 3. post process tomcat classes to remove bnd from the .class
> > > 4. jar it
> > >
> > > should solve the process and does not look crazy compared to what
> tomcat
> > > already does, no?
> > >
> > > Alternative is indeed to drop bnd since the manifest is quite easy to
> > write
> > > manually or with an ant task to filter the version for tomcat case, at
> > > least for spec jars (it is harder for the impl but here bnd is fine).
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le jeu. 1 avr. 2021 à 09:19, Mark Thomas  a écrit :
> > >
> > >> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > >>> Hello,
> > >>>
> > >>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> > >>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> > >>> the EL API? Will it be removed in the next release?
> > >>
> > >> Currently, there are no plans to change the Tomcat code.
> > >>
> > >> We do run the TCKs but take a pragmatic view of any failures. For
> > >> example, the Servlet TCK test that tests setting a context path in
> > >> web.xml always fails because Tomcat always overrides any such setting.
> > >> The Servlet spec allows this setting to be overridden but the TCK test
> > >> doesn't consider the possibility that a container will always do this.
> > >> Therefore we simply treat this as an expected failure. Full details
> for
> > >> all the TCKs we run can be found on the Wiki:
> > >>
> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> > >>
> > >> The EL signature test failure is another example of a failure that we
> > >> consider can be safely ignored.
> > >>
> > >> Tomcat does not, and has not for many, many years, formally certified
> > >> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > >> request at any point in that time to complete formal certification.
> > >> Therefore, I expect that Tomcat will continue following its current
> > >> pragmatic approach to the TCKs.
> > >>
> > >> Mark
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> > >>
> > >>
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>
> --
> Jean-Louis
>


-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow

Re: [VOTE] Release Apache Tomcat Native 1.2.28

2021-04-02 Thread Felix Schumacher 


Am 01.04.21 um 15:56 schrieb Mark Thomas:
> Version 1.2.28 includes the following changes compared to 1.2.27
>
> - Correct regression in previous fix for BZ 65181
>
> The proposed release artefacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 1.2.28 release is
>  [x] Stable, go ahead and release
>  [ ] Broken because of ...

Tests pass on Tomcat 8.5.65, 9.0.45 and 10.0.5 under Linux

Felix

>
> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.2.28
>
> [2]
> https://gitbox.apache.org/repos/asf?p=tomcat-native.git;a=commit;h=5566385ab63361d8d707613508d803964a15a1f8
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

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

Re: [VOTE] Release Apache Tomcat 10.0.5

2021-04-02 Thread Felix Schumacher 


Am 30.03.21 um 10:46 schrieb Mark Thomas:
> The proposed Apache Tomcat 10.0.5 release is now available for
> voting.
>
> Apache Tomcat 10.x implements Jakarta EE 9 and, as such, the primary
> package for all the specification APIs has changed from javax.* to
> jakarta.*
>
> Applications that run on Tomcat 9 will not run on Tomcat 10 without
> changes. Java EE applications designed for Tomcat 9 and earlier may be
> placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will
> automatically convert them to Jakarta EE and copy them to the webapps
> directory
>
> The notable changes compared to 10.0.4 are:
>
> - Fix a regression in 10.0.4 that meant that an error during an
>   asynchronous read broke all future asynchronous reads associated with
>   the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>   the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>   binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat10/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.0.5/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1304
> The tag is:
> https://github.com/apache/tomcat/tree/10.0.5
> 328d87e3d1ef41c46b5173114e30d37394bd68b9
>
> The proposed 10.0.5 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 10.0.5 (stable)

The order of "stable" and "broken" is different to the one in tc natives
voting mail, which confused me. Is this intentional?

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

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

Re: [VOTE] Release Apache Tomcat 8.5.65

2021-04-02 Thread Felix Schumacher 


Am 30.03.21 um 15:13 schrieb Mark Thomas:
> The proposed Apache Tomcat 8.5.65 release is now available for voting.
>
> The notable changes compared to the 8.5.64 release are:
>
> - Fix a regression in 8.5.64 that meant that an error during an
>   asynchronous read broke all future asynchronous reads associated with
>   the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>   the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>   binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.65/
>
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1306/
>
> The tag is:
> https://github.com/apache/tomcat/tree/8.5.65
> 752c1b9221f7d51a9f0f13d5ce83540589e228e4
>
> The proposed 8.5.65 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 8.5.65

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

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

Re: [VOTE] Release Apache Tomcat 9.0.45

2021-04-02 Thread Felix Schumacher 


Am 30.03.21 um 12:52 schrieb Mark Thomas:
> The proposed Apache Tomcat 9.0.45 release is now available for voting.
>
> The notable changes compared to the 9.0.44 release are:
>
> - Fix a regression in 9.0.44 that meant that an error during an
>   asynchronous read broke all future asynchronous reads associated with
>   the same request instance.
>
> - Prevent concurrent calls to ServletInputStream.isReady() corrupting
>   the input buffer.
>
> - Update the packaged version of Tomcat Native to 1.2.27 to pick up
>   binaries built with OpenSSL 1.1.1k
>
> Along with lots of other bug fixes and improvements.
>
> For full details, see the changelog:
> https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.45/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1305/
> The tag is:
> https://github.com/apache/tomcat/tree/9.0.45
> 4dcf07fd1b53d3934d408060c6ef1ea13894c16f
>
> The proposed 9.0.45 release is:
> [ ] Broken - do not release
> [x] Stable - go ahead and release as 9.0.45

Felix


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

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

Re: TCK Signature for EL API

2021-04-02 Thread Mark Thomas 

On 02/04/2021 13:58, Raymond Augé wrote:

I just wanted to make a note that removing the annotation will also mean
that the module-info.java will need to be manually managed since bnd also
generated that based on the annotations.


That might be more problematic. Sigh. I'll look into that next week.

Mark




Just FYI,
- Ray

On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO 
wrote:


That's awesome news.

I'm glad it's something that can be achieved without too much effort.
I understand and buy the pragmatic approach.

But at the same time, if we can do a step forward and get even closer to
being certified, that'd be great.

Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :


I've been playing with this a bit more and it appears we can simply
hard-code the "Require-Capability" header in el-api.jar.bnd

Having taken the time to look at the actual values generated for these
API JARs, this does look like something that would be simple to maintain
manually - especially for the API JARs where adding a new use of
ServiceLoader is likely to happen fairly rarely.

We should be able to remove the Bnd annotation in
- 10.0.x for 10.0.6 onwards
- 9.0.x for 9.0.46 onwards

We'll certainly do this for the API JARs. I think we'll leave it in
place for the implementation JARs

I have a few things on my TODO list at the moment but I don't see why I
shouldn't be able to get this done for the May set of releases.

Mark


On 01/04/2021 08:24, Romain Manni-Bucau wrote:

Hi,

AFAIK TomEE will try to be certified and will try to not fork as much

as

possible Tomcat code so can be neat to solve it in particular when
relatively easy:

1. compile tomcat classes with bnd as of today
2. run bnd to get the manifest.mf (
3. post process tomcat classes to remove bnd from the .class
4. jar it

should solve the process and does not look crazy compared to what

tomcat

already does, no?

Alternative is indeed to drop bnd since the manifest is quite easy to

write

manually or with an ant task to filter the version for tomcat case, at
least for spec jars (it is harder for the impl but here bnd is fine).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <

https://github.com/rmannibucau> |

LinkedIn  | Book
<



https://www.packtpub.com/application-development/java-ee-8-high-performance




Le jeu. 1 avr. 2021 à 09:19, Mark Thomas  a écrit :


On 31/03/2021 20:14, Volodymyr Siedlecki wrote:

Hello,

It appears the TCK Signature tests will not be relaxed (see 1 & 2),
and I'm wondering how Tomcat will proceed with the bnd annotation in
the EL API? Will it be removed in the next release?


Currently, there are no plans to change the Tomcat code.

We do run the TCKs but take a pragmatic view of any failures. For
example, the Servlet TCK test that tests setting a context path in
web.xml always fails because Tomcat always overrides any such setting.
The Servlet spec allows this setting to be overridden but the TCK test
doesn't consider the possibility that a container will always do this.
Therefore we simply treat this as an expected failure. Full details

for

all the TCKs we run can be found on the Wiki:

https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs

The EL signature test failure is another example of a failure that we
consider can be safely ignored.

Tomcat does not, and has not for many, many years, formally certified
against the Jakarta EE / Java EE TCKs. I am not aware of any user
request at any point in that time to complete formal certification.
Therefore, I expect that Tomcat will continue following its current
pragmatic approach to the TCKs.

Mark

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







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




--
Jean-Louis







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

Re: TCK Signature for EL API

2021-04-02 Thread Romain Manni-Bucau 
Isn't it stable enough to use bcel or asm to write it?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 2 avr. 2021 à 16:41, Mark Thomas  a écrit :

> On 02/04/2021 13:58, Raymond Augé wrote:
> > I just wanted to make a note that removing the annotation will also mean
> > that the module-info.java will need to be manually managed since bnd also
> > generated that based on the annotations.
>
> That might be more problematic. Sigh. I'll look into that next week.
>
> Mark
>
>
> >
> > Just FYI,
> > - Ray
> >
> > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO 
> > wrote:
> >
> >> That's awesome news.
> >>
> >> I'm glad it's something that can be achieved without too much effort.
> >> I understand and buy the pragmatic approach.
> >>
> >> But at the same time, if we can do a step forward and get even closer to
> >> being certified, that'd be great.
> >>
> >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas  a écrit :
> >>
> >>> I've been playing with this a bit more and it appears we can simply
> >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> >>>
> >>> Having taken the time to look at the actual values generated for these
> >>> API JARs, this does look like something that would be simple to
> maintain
> >>> manually - especially for the API JARs where adding a new use of
> >>> ServiceLoader is likely to happen fairly rarely.
> >>>
> >>> We should be able to remove the Bnd annotation in
> >>> - 10.0.x for 10.0.6 onwards
> >>> - 9.0.x for 9.0.46 onwards
> >>>
> >>> We'll certainly do this for the API JARs. I think we'll leave it in
> >>> place for the implementation JARs
> >>>
> >>> I have a few things on my TODO list at the moment but I don't see why I
> >>> shouldn't be able to get this done for the May set of releases.
> >>>
> >>> Mark
> >>>
> >>>
> >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
>  Hi,
> 
>  AFAIK TomEE will try to be certified and will try to not fork as much
> >> as
>  possible Tomcat code so can be neat to solve it in particular when
>  relatively easy:
> 
>  1. compile tomcat classes with bnd as of today
>  2. run bnd to get the manifest.mf (
>  3. post process tomcat classes to remove bnd from the .class
>  4. jar it
> 
>  should solve the process and does not look crazy compared to what
> >> tomcat
>  already does, no?
> 
>  Alternative is indeed to drop bnd since the manifest is quite easy to
> >>> write
>  manually or with an ant task to filter the version for tomcat case, at
>  least for spec jars (it is harder for the impl but here bnd is fine).
> 
>  Romain Manni-Bucau
>  @rmannibucau  |  Blog
>   | Old Blog
>   | Github <
> >>> https://github.com/rmannibucau> |
>  LinkedIn  | Book
>  <
> >>>
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> 
> 
> 
>  Le jeu. 1 avr. 2021 à 09:19, Mark Thomas  a écrit :
> 
> > On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> >> Hello,
> >>
> >> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> >> and I'm wondering how Tomcat will proceed with the bnd annotation in
> >> the EL API? Will it be removed in the next release?
> >
> > Currently, there are no plans to change the Tomcat code.
> >
> > We do run the TCKs but take a pragmatic view of any failures. For
> > example, the Servlet TCK test that tests setting a context path in
> > web.xml always fails because Tomcat always overrides any such
> setting.
> > The Servlet spec allows this setting to be overridden but the TCK
> test
> > doesn't consider the possibility that a container will always do
> this.
> > Therefore we simply treat this as an expected failure. Full details
> >> for
> > all the TCKs we run can be found on the Wiki:
> >
> > https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> >
> > The EL signature test failure is another example of a failure that we
> > consider can be safely ignored.
> >
> > Tomcat does not, and has not for many, many years, formally certified
> > against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > request at any point in that time to complete formal certification.
> > Therefore, I expect that Tomcat will continue following its current
> > pragmatic approach to the TCKs.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: d