You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rory O'Donnell <ro...@oracle.com> on 2016/09/20 10:15:37 UTC
Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Hi Mark,
Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9 with
Project Jigsaw is available on java.net, summary of changes are listed
here
<http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
There have been a number of fixes to bugs reported by Open Source
projects since the last availability email :
* 8165723 - b136 - core-libs JarFile::isMultiRelease() method returns
false when it should return true
* 8165116 - b136 - xml redirect function is not allowed even with
enableExtensionFunctions
NOTE:- Build 135 included a fix for JDK-8161016 which *has introduced a
behavioral change to HttpURLConnection, more info:*
The behavior of HttpURLConnection when using a ProxySelector has been
modified with this JDK release. Currently, HttpURLConnection.connect()
call would fallback to a DIRECT connection attempt if the configured
proxy/proxies failed to make a connection. This release introduces a
change whereby no DIRECT connection will be attempted in such a
scenario. Instead, the HttpURLConnection.connect() method will fail and
throw an IOException which occurred from the last proxy tested. This
behavior now matches with the HTTP connections made by popular web
browsers. But this change will bring compatibility issues for the
applications expecting a DIRECT connection when a proxy server is down
or when wrong proxies are provided.
*
JDK 9 Outreach Survey*
In order to encourage and receive additional feedback from developers
testing their applications with JDK 9,
the OpenJDK Quality Outreach effort has put together a very brief survey
about your experiences with JDK 9 so far.
It is available at***https://www.surveymonkey.de/r/JDK9EA*
We would love to hear feedback from you!
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks Mark,
I updated the bug with your comments.
Rgds,Rory
On 01/12/2016 14:12, Mark Thomas wrote:
> On 30/11/2016 09:49, Rory O'Donnell wrote:
>> Hi Mark,
>>
>> The bug has been updated with the following suggestion, any comment ?
> Hi Rory,
>
> That would certainly be a good step in the right direction. It would
> enable the problem to be fixed for "jar:" without negatively impacting
> all the other protocols.
>
> What would make it perfect would be also changing the default for the
> "jar:" protocol to "do not cache" rather than "cache".
>
> Kind regards,
>
> Mark
>
>
>> Rgds,Rory
>>
>> "We could possibly add an API to explicitly set the default
>> independently per protocol. So, it would then be possible to disable it
>> for jar: URLs, but not other URL types. This would be a new API
>> obviously, and therefore only available from the release in which it is
>> introduced. "
>>
>>
>>
>> On 05/10/2016 09:17, Rory O'Donnell wrote:
>>> Thanks Mark, I'll update the bug.
>>>
>>> Rgds,Rory
>>>
>>>
>>> On 05/10/2016 09:15, Mark Thomas wrote:
>>>> On 04/10/2016 18:12, Rory O'Donnell wrote:
>>>>> Hi Mark,
>>>>>
>>>>> There was an update to JDK-8163449 below:
>>>>>
>>>>> Caching is enabled by default, but it can be disabled statically (if
>>>>> strangely through a non-static api). The fact that files can't be
>>>>> deleted on windows is a consequence of this caching, and also that
>>>>> files
>>>>> are opened by the Java runtime on windows in a mode that prevents
>>>>> deletion. So, really, this isn't a bug and the question is can the
>>>>> submitter just disable caching?
>>>>>
>>>>> Let me know if that works for you ?
>>>> It doesn't.
>>>>
>>>> The caching causes file locking on all operating systems. It is more
>>>> obvious on Windows since the OS won't let you delete the file. On Linux
>>>> while you can delete the file but the space won't be freed until the
>>>> lock is released.
>>>>
>>>> I'm aware of the ability to disable the caching and this is what Tomcat
>>>> does to work-around this issue.
>>>>
>>>> The bug was raised because the current default triggers file descriptor
>>>> leaks and lock files for JarURLConnection and that seems like a poor
>>>> choice for a default.
>>>>
>>>> Equally, I'd rather not have to to disable all caching just to avoid a
>>>> problem with one URLConnection sub-class.
>>>>
>>>> My hope was that rather than a single default caching option for all
>>>> URLConnections, the default could be configured per protocol and that
>>>> the default for the jar protocol would be changed to false.
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>>> Rgds,Rory
>>>>>
>>>>> On 20/09/2016 11:15, Rory O'Donnell wrote:
>>>>>> Hi Mark,
>>>>>>
>>>>>> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
>>>>>> available on java.net, summary of changes are listed here
>>>>>> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
>>>>>> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
>>>>>> with Project Jigsaw is available on java.net, summary of changes are
>>>>>> listed here
>>>>>> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>>>>>>
>>>>>>
>>>>>> There have been a number of fixes to bugs reported by Open Source
>>>>>> projects since the last availability email :
>>>>>>
>>>>>> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
>>>>>> returns false when it should return true
>>>>>> * 8165116 - b136 - xml redirect function is not allowed even with
>>>>>> enableExtensionFunctions
>>>>>>
>>>>>> NOTE:- Build 135 included a fix for JDK-8161016 which *has
>>>>>> introduced a behavioral change to HttpURLConnection, more info:*
>>>>>>
>>>>>> The behavior of HttpURLConnection when using a ProxySelector has been
>>>>>> modified with this JDK release. Currently, HttpURLConnection.connect()
>>>>>> call would fallback to a DIRECT connection attempt if the configured
>>>>>> proxy/proxies failed to make a connection. This release introduces a
>>>>>> change whereby no DIRECT connection will be attempted in such a
>>>>>> scenario. Instead, the HttpURLConnection.connect() method will fail
>>>>>> and throw an IOException which occurred from the last proxy tested.
>>>>>> This behavior now matches with the HTTP connections made by popular
>>>>>> web browsers. But this change will bring compatibility issues for the
>>>>>> applications expecting a DIRECT connection when a proxy server is down
>>>>>> or when wrong proxies are provided.
>>>>>> *
>>>>>>
>>>>>> JDK 9 Outreach Survey*
>>>>>>
>>>>>> In order to encourage and receive additional feedback from developers
>>>>>> testing their applications with JDK 9,
>>>>>> the OpenJDK Quality Outreach effort has put together a very brief
>>>>>> survey about your experiences with JDK 9 so far.
>>>>>>
>>>>>> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>>>>>>
>>>>>> We would love to hear feedback from you!
>>>>>>
>>>>>>
>>>>>> Rgds,Rory
>>>>>> --
>>>>>> Rgds,Rory O'Donnell
>>>>>> Quality Engineering Manager
>>>>>> Oracle EMEA , Dublin, Ireland
>>>>> --
>>>>> Rgds,Rory O'Donnell
>>>>> Quality Engineering Manager
>>>>> Oracle EMEA , Dublin, Ireland
>>>>>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Mark Thomas <ma...@apache.org>.
On 30/11/2016 09:49, Rory O'Donnell wrote:
> Hi Mark,
>
> The bug has been updated with the following suggestion, any comment ?
Hi Rory,
That would certainly be a good step in the right direction. It would
enable the problem to be fixed for "jar:" without negatively impacting
all the other protocols.
What would make it perfect would be also changing the default for the
"jar:" protocol to "do not cache" rather than "cache".
Kind regards,
Mark
>
> Rgds,Rory
>
> "We could possibly add an API to explicitly set the default
> independently per protocol. So, it would then be possible to disable it
> for jar: URLs, but not other URL types. This would be a new API
> obviously, and therefore only available from the release in which it is
> introduced. "
>
>
>
> On 05/10/2016 09:17, Rory O'Donnell wrote:
>> Thanks Mark, I'll update the bug.
>>
>> Rgds,Rory
>>
>>
>> On 05/10/2016 09:15, Mark Thomas wrote:
>>> On 04/10/2016 18:12, Rory O'Donnell wrote:
>>>> Hi Mark,
>>>>
>>>> There was an update to JDK-8163449 below:
>>>>
>>>> Caching is enabled by default, but it can be disabled statically (if
>>>> strangely through a non-static api). The fact that files can't be
>>>> deleted on windows is a consequence of this caching, and also that
>>>> files
>>>> are opened by the Java runtime on windows in a mode that prevents
>>>> deletion. So, really, this isn't a bug and the question is can the
>>>> submitter just disable caching?
>>>>
>>>> Let me know if that works for you ?
>>> It doesn't.
>>>
>>> The caching causes file locking on all operating systems. It is more
>>> obvious on Windows since the OS won't let you delete the file. On Linux
>>> while you can delete the file but the space won't be freed until the
>>> lock is released.
>>>
>>> I'm aware of the ability to disable the caching and this is what Tomcat
>>> does to work-around this issue.
>>>
>>> The bug was raised because the current default triggers file descriptor
>>> leaks and lock files for JarURLConnection and that seems like a poor
>>> choice for a default.
>>>
>>> Equally, I'd rather not have to to disable all caching just to avoid a
>>> problem with one URLConnection sub-class.
>>>
>>> My hope was that rather than a single default caching option for all
>>> URLConnections, the default could be configured per protocol and that
>>> the default for the jar protocol would be changed to false.
>>>
>>> Mark
>>>
>>>
>>>
>>>> Rgds,Rory
>>>>
>>>> On 20/09/2016 11:15, Rory O'Donnell wrote:
>>>>> Hi Mark,
>>>>>
>>>>> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
>>>>> available on java.net, summary of changes are listed here
>>>>> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
>>>>> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
>>>>> with Project Jigsaw is available on java.net, summary of changes are
>>>>> listed here
>>>>> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>>>>>
>>>>>
>>>>> There have been a number of fixes to bugs reported by Open Source
>>>>> projects since the last availability email :
>>>>>
>>>>> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
>>>>> returns false when it should return true
>>>>> * 8165116 - b136 - xml redirect function is not allowed even with
>>>>> enableExtensionFunctions
>>>>>
>>>>> NOTE:- Build 135 included a fix for JDK-8161016 which *has
>>>>> introduced a behavioral change to HttpURLConnection, more info:*
>>>>>
>>>>> The behavior of HttpURLConnection when using a ProxySelector has been
>>>>> modified with this JDK release. Currently, HttpURLConnection.connect()
>>>>> call would fallback to a DIRECT connection attempt if the configured
>>>>> proxy/proxies failed to make a connection. This release introduces a
>>>>> change whereby no DIRECT connection will be attempted in such a
>>>>> scenario. Instead, the HttpURLConnection.connect() method will fail
>>>>> and throw an IOException which occurred from the last proxy tested.
>>>>> This behavior now matches with the HTTP connections made by popular
>>>>> web browsers. But this change will bring compatibility issues for the
>>>>> applications expecting a DIRECT connection when a proxy server is down
>>>>> or when wrong proxies are provided.
>>>>> *
>>>>>
>>>>> JDK 9 Outreach Survey*
>>>>>
>>>>> In order to encourage and receive additional feedback from developers
>>>>> testing their applications with JDK 9,
>>>>> the OpenJDK Quality Outreach effort has put together a very brief
>>>>> survey about your experiences with JDK 9 so far.
>>>>>
>>>>> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>>>>>
>>>>> We would love to hear feedback from you!
>>>>>
>>>>>
>>>>> Rgds,Rory
>>>>> --
>>>>> Rgds,Rory O'Donnell
>>>>> Quality Engineering Manager
>>>>> Oracle EMEA , Dublin, Ireland
>>>> --
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland
>>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Rory O'Donnell <ro...@oracle.com>.
Hi Mark,
The bug has been updated with the following suggestion, any comment ?
Rgds,Rory
"We could possibly add an API to explicitly set the default
independently per protocol. So, it would then be possible to disable it
for jar: URLs, but not other URL types. This would be a new API
obviously, and therefore only available from the release in which it is
introduced. "
On 05/10/2016 09:17, Rory O'Donnell wrote:
> Thanks Mark, I'll update the bug.
>
> Rgds,Rory
>
>
> On 05/10/2016 09:15, Mark Thomas wrote:
>> On 04/10/2016 18:12, Rory O'Donnell wrote:
>>> Hi Mark,
>>>
>>> There was an update to JDK-8163449 below:
>>>
>>> Caching is enabled by default, but it can be disabled statically (if
>>> strangely through a non-static api). The fact that files can't be
>>> deleted on windows is a consequence of this caching, and also that
>>> files
>>> are opened by the Java runtime on windows in a mode that prevents
>>> deletion. So, really, this isn't a bug and the question is can the
>>> submitter just disable caching?
>>>
>>> Let me know if that works for you ?
>> It doesn't.
>>
>> The caching causes file locking on all operating systems. It is more
>> obvious on Windows since the OS won't let you delete the file. On Linux
>> while you can delete the file but the space won't be freed until the
>> lock is released.
>>
>> I'm aware of the ability to disable the caching and this is what Tomcat
>> does to work-around this issue.
>>
>> The bug was raised because the current default triggers file descriptor
>> leaks and lock files for JarURLConnection and that seems like a poor
>> choice for a default.
>>
>> Equally, I'd rather not have to to disable all caching just to avoid a
>> problem with one URLConnection sub-class.
>>
>> My hope was that rather than a single default caching option for all
>> URLConnections, the default could be configured per protocol and that
>> the default for the jar protocol would be changed to false.
>>
>> Mark
>>
>>
>>
>>> Rgds,Rory
>>>
>>> On 20/09/2016 11:15, Rory O'Donnell wrote:
>>>> Hi Mark,
>>>>
>>>> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
>>>> available on java.net, summary of changes are listed here
>>>> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
>>>> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
>>>> with Project Jigsaw is available on java.net, summary of changes are
>>>> listed here
>>>> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>>>>
>>>>
>>>> There have been a number of fixes to bugs reported by Open Source
>>>> projects since the last availability email :
>>>>
>>>> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
>>>> returns false when it should return true
>>>> * 8165116 - b136 - xml redirect function is not allowed even with
>>>> enableExtensionFunctions
>>>>
>>>> NOTE:- Build 135 included a fix for JDK-8161016 which *has
>>>> introduced a behavioral change to HttpURLConnection, more info:*
>>>>
>>>> The behavior of HttpURLConnection when using a ProxySelector has been
>>>> modified with this JDK release. Currently, HttpURLConnection.connect()
>>>> call would fallback to a DIRECT connection attempt if the configured
>>>> proxy/proxies failed to make a connection. This release introduces a
>>>> change whereby no DIRECT connection will be attempted in such a
>>>> scenario. Instead, the HttpURLConnection.connect() method will fail
>>>> and throw an IOException which occurred from the last proxy tested.
>>>> This behavior now matches with the HTTP connections made by popular
>>>> web browsers. But this change will bring compatibility issues for the
>>>> applications expecting a DIRECT connection when a proxy server is down
>>>> or when wrong proxies are provided.
>>>> *
>>>>
>>>> JDK 9 Outreach Survey*
>>>>
>>>> In order to encourage and receive additional feedback from developers
>>>> testing their applications with JDK 9,
>>>> the OpenJDK Quality Outreach effort has put together a very brief
>>>> survey about your experiences with JDK 9 so far.
>>>>
>>>> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>>>>
>>>> We would love to hear feedback from you!
>>>>
>>>>
>>>> Rgds,Rory
>>>> --
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Rory O'Donnell <ro...@oracle.com>.
Thanks Mark, I'll update the bug.
Rgds,Rory
On 05/10/2016 09:15, Mark Thomas wrote:
> On 04/10/2016 18:12, Rory O'Donnell wrote:
>> Hi Mark,
>>
>> There was an update to JDK-8163449 below:
>>
>> Caching is enabled by default, but it can be disabled statically (if
>> strangely through a non-static api). The fact that files can't be
>> deleted on windows is a consequence of this caching, and also that files
>> are opened by the Java runtime on windows in a mode that prevents
>> deletion. So, really, this isn't a bug and the question is can the
>> submitter just disable caching?
>>
>> Let me know if that works for you ?
> It doesn't.
>
> The caching causes file locking on all operating systems. It is more
> obvious on Windows since the OS won't let you delete the file. On Linux
> while you can delete the file but the space won't be freed until the
> lock is released.
>
> I'm aware of the ability to disable the caching and this is what Tomcat
> does to work-around this issue.
>
> The bug was raised because the current default triggers file descriptor
> leaks and lock files for JarURLConnection and that seems like a poor
> choice for a default.
>
> Equally, I'd rather not have to to disable all caching just to avoid a
> problem with one URLConnection sub-class.
>
> My hope was that rather than a single default caching option for all
> URLConnections, the default could be configured per protocol and that
> the default for the jar protocol would be changed to false.
>
> Mark
>
>
>
>> Rgds,Rory
>>
>> On 20/09/2016 11:15, Rory O'Donnell wrote:
>>> Hi Mark,
>>>
>>> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
>>> available on java.net, summary of changes are listed here
>>> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
>>> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
>>> with Project Jigsaw is available on java.net, summary of changes are
>>> listed here
>>> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>>>
>>> There have been a number of fixes to bugs reported by Open Source
>>> projects since the last availability email :
>>>
>>> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
>>> returns false when it should return true
>>> * 8165116 - b136 - xml redirect function is not allowed even with
>>> enableExtensionFunctions
>>>
>>> NOTE:- Build 135 included a fix for JDK-8161016 which *has
>>> introduced a behavioral change to HttpURLConnection, more info:*
>>>
>>> The behavior of HttpURLConnection when using a ProxySelector has been
>>> modified with this JDK release. Currently, HttpURLConnection.connect()
>>> call would fallback to a DIRECT connection attempt if the configured
>>> proxy/proxies failed to make a connection. This release introduces a
>>> change whereby no DIRECT connection will be attempted in such a
>>> scenario. Instead, the HttpURLConnection.connect() method will fail
>>> and throw an IOException which occurred from the last proxy tested.
>>> This behavior now matches with the HTTP connections made by popular
>>> web browsers. But this change will bring compatibility issues for the
>>> applications expecting a DIRECT connection when a proxy server is down
>>> or when wrong proxies are provided.
>>> *
>>>
>>> JDK 9 Outreach Survey*
>>>
>>> In order to encourage and receive additional feedback from developers
>>> testing their applications with JDK 9,
>>> the OpenJDK Quality Outreach effort has put together a very brief
>>> survey about your experiences with JDK 9 so far.
>>>
>>> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>>>
>>> We would love to hear feedback from you!
>>>
>>>
>>> Rgds,Rory
>>> --
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>>
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Mark Thomas <ma...@apache.org>.
On 04/10/2016 18:12, Rory O'Donnell wrote:
> Hi Mark,
>
> There was an update to JDK-8163449 below:
>
> Caching is enabled by default, but it can be disabled statically (if
> strangely through a non-static api). The fact that files can't be
> deleted on windows is a consequence of this caching, and also that files
> are opened by the Java runtime on windows in a mode that prevents
> deletion. So, really, this isn't a bug and the question is can the
> submitter just disable caching?
>
> Let me know if that works for you ?
It doesn't.
The caching causes file locking on all operating systems. It is more
obvious on Windows since the OS won't let you delete the file. On Linux
while you can delete the file but the space won't be freed until the
lock is released.
I'm aware of the ability to disable the caching and this is what Tomcat
does to work-around this issue.
The bug was raised because the current default triggers file descriptor
leaks and lock files for JarURLConnection and that seems like a poor
choice for a default.
Equally, I'd rather not have to to disable all caching just to avoid a
problem with one URLConnection sub-class.
My hope was that rather than a single default caching option for all
URLConnections, the default could be configured per protocol and that
the default for the jar protocol would be changed to false.
Mark
>
> Rgds,Rory
>
> On 20/09/2016 11:15, Rory O'Donnell wrote:
>>
>> Hi Mark,
>>
>> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
>> available on java.net, summary of changes are listed here
>> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
>> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
>> with Project Jigsaw is available on java.net, summary of changes are
>> listed here
>> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>>
>> There have been a number of fixes to bugs reported by Open Source
>> projects since the last availability email :
>>
>> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
>> returns false when it should return true
>> * 8165116 - b136 - xml redirect function is not allowed even with
>> enableExtensionFunctions
>>
>> NOTE:- Build 135 included a fix for JDK-8161016 which *has
>> introduced a behavioral change to HttpURLConnection, more info:*
>>
>> The behavior of HttpURLConnection when using a ProxySelector has been
>> modified with this JDK release. Currently, HttpURLConnection.connect()
>> call would fallback to a DIRECT connection attempt if the configured
>> proxy/proxies failed to make a connection. This release introduces a
>> change whereby no DIRECT connection will be attempted in such a
>> scenario. Instead, the HttpURLConnection.connect() method will fail
>> and throw an IOException which occurred from the last proxy tested.
>> This behavior now matches with the HTTP connections made by popular
>> web browsers. But this change will bring compatibility issues for the
>> applications expecting a DIRECT connection when a proxy server is down
>> or when wrong proxies are provided.
>> *
>>
>> JDK 9 Outreach Survey*
>>
>> In order to encourage and receive additional feedback from developers
>> testing their applications with JDK 9,
>> the OpenJDK Quality Outreach effort has put together a very brief
>> survey about your experiences with JDK 9 so far.
>>
>> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>>
>> We would love to hear feedback from you!
>>
>>
>> Rgds,Rory
>> --
>> Rgds,Rory O'Donnell
>> Quality Engineering Manager
>> Oracle EMEA , Dublin, Ireland
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are
available on java.net
Posted by Rory O'Donnell <ro...@oracle.com>.
Hi Mark,
There was an update to JDK-8163449 below:
Caching is enabled by default, but it can be disabled statically (if
strangely through a non-static api). The fact that files can't be
deleted on windows is a consequence of this caching, and also that files
are opened by the Java runtime on windows in a mode that prevents
deletion. So, really, this isn't a bug and the question is can the
submitter just disable caching?
Let me know if that works for you ?
Rgds,Rory
On 20/09/2016 11:15, Rory O'Donnell wrote:
>
> Hi Mark,
>
> Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
> available on java.net, summary of changes are listed here
> <http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
> Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9
> with Project Jigsaw is available on java.net, summary of changes are
> listed here
> <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
>
> There have been a number of fixes to bugs reported by Open Source
> projects since the last availability email :
>
> * 8165723 - b136 - core-libs JarFile::isMultiRelease() method
> returns false when it should return true
> * 8165116 - b136 - xml redirect function is not allowed even with
> enableExtensionFunctions
>
> NOTE:- Build 135 included a fix for JDK-8161016 which *has introduced
> a behavioral change to HttpURLConnection, more info:*
>
> The behavior of HttpURLConnection when using a ProxySelector has been
> modified with this JDK release. Currently, HttpURLConnection.connect()
> call would fallback to a DIRECT connection attempt if the configured
> proxy/proxies failed to make a connection. This release introduces a
> change whereby no DIRECT connection will be attempted in such a
> scenario. Instead, the HttpURLConnection.connect() method will fail
> and throw an IOException which occurred from the last proxy tested.
> This behavior now matches with the HTTP connections made by popular
> web browsers. But this change will bring compatibility issues for the
> applications expecting a DIRECT connection when a proxy server is down
> or when wrong proxies are provided.
> *
>
> JDK 9 Outreach Survey*
>
> In order to encourage and receive additional feedback from developers
> testing their applications with JDK 9,
> the OpenJDK Quality Outreach effort has put together a very brief
> survey about your experiences with JDK 9 so far.
>
> It is available at***https://www.surveymonkey.de/r/JDK9EA*
>
> We would love to hear feedback from you!
>
>
> Rgds,Rory
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland