Hello Christoph,

The actual release notes I initially looked up are the April  Release notes 
from Azul (17.34) for 17.0.3. I already opened a case there. However I then 
also checked the Oracle Release Notes (I thought they would contain the same 
17.0.3 changes).

The incompatibility in VFS was actually a shortcoming in VFS: if you want to 
determine who can handle a file type it would check the mime type or the 
extension. But it was coded in a way that if it has a mime type but no handler 
for that type it won’t check for the file extension. This way it could no 
longer browser URLs ending in .jar or uncompres .go files (or generally all 
files where there was previously only a file extension handler registered).

I would asume this negative consequences is hard to predict, especially since 
VFS could in this case prevemt it. However for an application it is unfortunate 
that this breaks (especially when hoping to ship a quarterly security update 
quickly). Bit generally it’s a noteworthy new feature.

Thanks for the reminder of the Shipilev release notes, I did actually not check 
them after looking at two vendors (and not finding a Release announcement mail 
like there was one for 17.0.2. Can I asume those are no longer sent after X.0.2 
is published? I guess my comment to „not including it in the release notes“ was 
not valid for the OpenJDK Updates project and I will take it up with Azul to 
check the source they are using.

If you want to look deeper into this:

The VFS logic might be a bit hard to follow, it basically works on URLs and it 
has a filesystem layering mode which checks on mime type and/or extension: 
https://issues.apache.org/jira/browse/VFS-770
This is the actual fix commit for it: 
https://github.com/apache/commons-vfs/commit/f3b7a06f28aab2db829806e0e857c05b71a14305
It is retrieving the contentType for a URL here 
https://github.com/apache/commons-vfs/blob/64da24778ea075ffc5de8588a29a0f50c6c8d94e/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/FileContentInfoFilenameFactory.java#L41

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: Langer, Christoph <christoph.lan...@sap.com>
Gesendet: Tuesday, April 26, 2022 5:18:38 PM
An: Bernd Eckenfels <e...@zusammenkunft.net>; jdk-updates-...@openjdk.java.net 
<jdk-updates-...@openjdk.java.net>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Betreff: RE: Regression after April Java 17 Update (mime types)

Hi Bernd,

I just noticed your report regarding the regression after JDK-8273655. I'm 
directing this communication to jdk-updates-dev now as it seems more 
appropriate.

I assume with release notes you're referring to the Oracle 17.0.3 release 
notes? This change, if you look closely at the backports, was only brought to 
OpenJDK 17.0.3 and it will hit the OpenJDK 11u update 11.0.16 in July. So, it 
would not be reflected in Oracle release notes. The best you can get for 
OpenJDK 17.0.3 release notes is [0], to my knowledge.

Do you have some more information regarding the incompatibility? What I'm 
understanding is that this backport unveils a problem with Apache VFS? Do you 
have a bug link for that one? If it's just uncovering a bug in another 3rd 
party software, I assume it doesn't merit a backout, though.

Best regards
Christoph

[0] https://builds.shipilev.net/backports-monitor/release-notes-17.0.3.html


> -----Original Message-----
> From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> On Behalf Of Bernd
> Eckenfels
> Sent: Montag, 25. April 2022 19:39
> To: core-libs-dev <core-libs-dev@openjdk.java.net>
> Subject: Regression after April Java 17 Update (mime types)
>
> Hello,
>
> We just tried to push out the Java 17 April Update but it failed with some
> incompatible behavior. We found out it is caused due to a new mime-type (and
> a bug in Apache VFS) that JAR files could no longer be opened in an overlay
> (technically a JAR URL suddenly had a mime-type and therefore VFS no longer
> looked at the file extension).
>
> Just wanted to give a heads up in case anybody else has that problem. The
> change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release
> notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the
> OpenJDK announcement?
>
> This specific case is a changed behavior (even when it has rather unexpected
> negative consequences), it would be therefore good to be called out
> specifically.
>
> Gruss
> Bernd
>
>
> --
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbernd.eck
> enfels.net%2F&amp;data=05%7C01%7Cchristoph.langer%40sap.com%7C9ca8f
> 2471e24471c3d8308da26e286b1%7C42f7676cf455423c82f6dc2d99791af7%7
> C0%7C0%7C637865052069446373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=J3kfVCvkDUH9UxiRqkoS9g9o85nB46ksbpUF5HihRP8
> %3D&amp;reserved=0

Reply via email to