Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

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  for JDK 9 is
available on java.net, summary of  changes are listed here
.
Early Access b136  (#5506) for JDK 9
with Project Jigsaw is available on java.net, summary of changes are
listed here
.


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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Mark Thomas]

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  for JDK 9 is
> available on java.net, summary of  changes are listed here
> .
> Early Access b136  (#5506) for JDK 9
> with Project Jigsaw is available on java.net, summary of changes are
> listed here
> .
>
>
> 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

>>
> 

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

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  for JDK 9 is
available on java.net, summary of  changes are listed here
.
Early Access b136  (#5506) for JDK 9
with Project Jigsaw is available on java.net, summary of changes are
listed here
. 



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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

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  for JDK 9 is
available on java.net, summary of  changes are listed here
.
Early Access b136  (#5506) for JDK 9
with Project Jigsaw is available on java.net, summary of  changes are
listed here
.

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Mark Thomas]

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  for JDK 9 is
>> available on java.net, summary of  changes are listed here
>> .
>> Early Access b136  (#5506) for JDK 9
>> with Project Jigsaw is available on java.net, summary of  changes are
>> listed here
>> .
>>
>> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

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  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.
Early Access b136  (#5506) for JDK 9 
with Project Jigsaw is available on java.net, summary of  changes are 
listed here 
.


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

Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net

[Rory O'Donnell]

Hi Mark,

Early Access b136  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.
Early Access b136  (#5506) for JDK 9 with 
Project Jigsaw is available on java.net, summary of  changes are listed 
here 
.


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