Re: [VFS][VFS-700] Some tests fail on Java 11 and above

2019-04-19 Thread Gary Gregory 
Can anyone lend a hand ?

Gary

On Fri, Apr 12, 2019 at 7:43 AM Gary Gregory  wrote:

> Help needed ;-)
>
> Gary
>

Re: [vfs] Spaces in folders cause Jenkins build to fail

2019-04-19 Thread Woonsan Ko 
On Fri, Apr 19, 2019 at 6:13 PM Gary Gregory  wrote:
>
> Hi,
>
> WRT
> https://builds.apache.org/job/Apache%20Commons%20VFS/org.apache.commons$commons-vfs2/9/testReport/junit/org.apache.commons.vfs2.test/UriTests/testAbsoluteURI/
>
> I just replaced the old svn-based build with a git-based build.
>
> I called the project "Apache Commons VFS" in the UI and Jenkins put the
> project in a folder of the same name.
>
> Notice the failure in the report above which contains:
>
> org.apache.commons.vfs2.FileSystemException: Badly formed URI
> "file:///home/jenkins/jenkins-slave/workspace/Apache Commons
> VFS/commons-vfs2/target/test-classes/test-data/read-tests".
> at 
> org.apache.commons.vfs2.provider.url.UrlFileProvider.findFile(UrlFileProvider.java:73)
> at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:716)
> at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:653)
> at 
> org.apache.commons.vfs2.test.UriTests.testAbsoluteURI(UriTests.java:43)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:198)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.lang.IllegalArgumentException: Illegal character in
> path at index 51: file:///home/jenkins/jenkins-slave/workspace/Apache
> Commons VFS/commons-vfs2/target/test-classes/test-data/read-tests
> at java.net.URI.create(URI.java:852)
> at 
> org.apache.commons.vfs2.provider.url.UrlFileProvider.findFile(UrlFileProvider.java:59)
> ... 26 more
> Caused by: java.net.URISyntaxException: Illegal character in path at
> index 51: file:///home/jenkins/jenkins-slave/workspace/Apache Commons
> VFS/commons-vfs2/target/test-classes/test-data/read-tests
> at java.net.URI$Parser.fail(URI.java:2848)
> at java.net.URI$Parser.checkChars(URI.java:3021)
> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
> at java.net.URI$Parser.parse(URI.java:3053)
> at java.net.URI.(URI.java:588)
> at java.net.URI.create(URI.java:850)
> ... 27 more
>
> I wonder if this is something we need to fix in VFS? I just don't want
> us to hack the test to make it work if there is a real underlying
> issue.

I now notice the difference between `new URL("file://.../Apache
Commons VFS/...")` and `URI.create("file://.../Apache Commons
VFS/...")`.
The former doesn't throw an exception at all whereas the latter does.
And, the latter replaced the former with commit
b913ebd36a136efc99195fef9f8a857b55d02545 for VFS-360 in my
contribution.
Good news is the URIs or URLs are just local variables. [1] So,
perhaps shall we change it back to use URLs again?

Regards,

Woonsan

[1] org.apache.commons.vfs2.provider.url.UrlFileProvider.findFile(FileObject,
String, FileSystemOptions)

>
> Thoughts,
>
> Gary

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

Re: [rng] Split and Jump functions

2019-04-19 Thread Alex Herbert 


> On 19 Apr 2019, at 15:30, Gilles Sadowski  wrote:
> 
> Le jeu. 18 avr. 2019 à 21:53, Alex Herbert  > a écrit :
>> 
>> 
>> 
>>> On 18 Apr 2019, at 14:12, Gilles Sadowski  wrote:
>>> 
>>> Hello Alex.
>>> 
>> [...]
 
 OK so this results in:
 
 /**
 * Some summary.
 */
 public interface JumpableUniformRandomProvider extends
 UniformRandomProvider {
/**
 * Creates a copy of the UniformRandomProvider and advances the
 state of the copy.
 * The state of the current instance is not altered. The state of
 the copy will be
 * advanced an equivalent of {@code n} sequential calls to a method
 that updates the
 * state of the provider.
 *
 * @return the copy with an advanced state
 */
JumpableUniformRandomProvider jump();
 }
 
>>> 
>>> +1
>>> [Clean and lean: and no side-effects to explain...]
>>> 
 
 This can be documented in an implementation as:
 
 public class MyJumpingRNG implements JumpableUniformRandomProvider {
/**
 * {@inheritDoc}
 *
 * The jump size {@code n} is the equivalent of {@code 2^64}
 calls to
 * {@link UniformRandomProvider#nextLong() nextLong()}.
 */
@Override
public JumpableUniformRandomProvider jump() {
// TODO Auto-generated method stub
return null;
}
 }
>>> 
>>> +1
>>> 
 
 Do we add a second interface for LongJumpableUniformRandomProvider?
>>> 
>>> Sure, if the functionality is provided by some of the algorithms implemented
>>> in [RNG].
>>> But let's have the two functionalities in separate commits.
>>> 
 
>> So the options are (in all cases returning the copy):
>> 
>> 1. createAndJumpCopy
>> 2. copyAndJumpParent
>> 3. jumpParentAndCopy
>> 4. jump and copy separately
>> 
>> 1. Your preferred option. A copy of the state is made. The state is 
>> advanced in the copy and returned. But when called repeatedly it will 
>> get the same generator and code must be organised appropriately.
> We could provide a convenience method in  "RandomSource":
> 
> public UniformRandomProvider[] jump(int n,
> JumpableUniformRandomProvider parent) {
>final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
>UniformRandomProvider tmp = parent;
>for (int i = 0; i < n; i++) {
>rngs[i] = restrict(tmp);
>tmp = tmp.jump();
>}
>return rngs;
> }
 
 +1. Remove the need for the user to repeat boiler plate code.
 
 Same sort of idea of longJump() too.
>>> 
>>> +1
>>> 
>> It is not actually possible to jump forward a single instance. Only 
>> children are advanced.
> A feature: There is only one way to alter the state of an instance
> (i.e. a call to "next()").
 OK.
>>> 
>>> Great. :-)
>>> 
>>> Gilles
>> 
>> This sounds like a resolution. I will put the ideas into a Jira ticket for 
>> Jumpable.
> 
> Thanks.
> 
>> 
>> I am a bit busy at the moment with other mini-projects (updates to 
>> nextInt(int) being the main one, Poisson samplers (again) being another 
>> leading to a family of log normal based distributions that may be supported 
>> using cumulative probability look-up tables) but will hope to get this done 
>> soon. The actual implementation should be quite easy.
>> 
>> Here’s one for you to think about on the subject of Jumpable. What about 
>> support for the generators that can be advanced by a user specified 
>> increment? For example the SplitMix algorithm is based on a sequence and so 
>> can be advanced from 1 to 2^64-1 steps. It does seem strange to support this 
>> (if we add jumpable to SplitMix) using only one specific jump distance. A 
>> Skippable can do this:
>> 
>> SkippableURP {
>>public SkippableURP skip(long steps);
>> 
>>// or
>> 
>>public SkippableURP skipPower2(long power);
>> }
>> 
>> Too much?
> 
> You read my mind. ;-)
> What would be the uses of "short" jumps (i.e. having small
> non-overlapping sequences

I could not think of one. Just wanted to raise the suggestion. It would not be 
supported for many generators anyway (currently only SplitMix, maybe more in 
the future).

> from many instances, rather than a longer one from a single instance)?
> IIUC, the hard-coded jump sizes in existing implementations seem a compromise,
> based on the number of potentially concurrent threads, or independent
> simulations.
> Increasing that number does not seem necessary for the mid-term.
> 
> Regards,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
>

[vfs] Spaces in folders cause Jenkins build to fail

2019-04-19 Thread Gary Gregory 
Hi,

WRT
https://builds.apache.org/job/Apache%20Commons%20VFS/org.apache.commons$commons-vfs2/9/testReport/junit/org.apache.commons.vfs2.test/UriTests/testAbsoluteURI/

I just replaced the old svn-based build with a git-based build.

I called the project "Apache Commons VFS" in the UI and Jenkins put the
project in a folder of the same name.

Notice the failure in the report above which contains:

org.apache.commons.vfs2.FileSystemException: Badly formed URI
"file:///home/jenkins/jenkins-slave/workspace/Apache Commons
VFS/commons-vfs2/target/test-classes/test-data/read-tests".
at 
org.apache.commons.vfs2.provider.url.UrlFileProvider.findFile(UrlFileProvider.java:73)
at 
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:716)
at 
org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:653)
at 
org.apache.commons.vfs2.test.UriTests.testAbsoluteURI(UriTests.java:43)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:198)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at 
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at 
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.lang.IllegalArgumentException: Illegal character in
path at index 51: file:///home/jenkins/jenkins-slave/workspace/Apache
Commons VFS/commons-vfs2/target/test-classes/test-data/read-tests
at java.net.URI.create(URI.java:852)
at 
org.apache.commons.vfs2.provider.url.UrlFileProvider.findFile(UrlFileProvider.java:59)
... 26 more
Caused by: java.net.URISyntaxException: Illegal character in path at
index 51: file:///home/jenkins/jenkins-slave/workspace/Apache Commons
VFS/commons-vfs2/target/test-classes/test-data/read-tests
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3053)
at java.net.URI.(URI.java:588)
at java.net.URI.create(URI.java:850)
... 27 more

I wonder if this is something we need to fix in VFS? I just don't want
us to hack the test to make it work if there is a real underlying
issue.

Thoughts,

Gary

Re: [VFS] Exceptions in new file filter code

2019-04-19 Thread Otto Fowler 
+1 then, from looking at the code, I don’t see why RuntimeException would
be required there.


On April 19, 2019 at 12:38:02, Gary Gregory (garydgreg...@gmail.com) wrote:

On Fri, Apr 19, 2019 at 11:38 AM Otto Fowler 
wrote:

> Where these written to be used as lambdas?
>

They were not. These were written a long time ago as part of Apache Commons
IO and recently ported to VFS.

Gary


>
>
> On April 19, 2019 at 10:07:28, Gary Gregory (garydgreg...@gmail.com)
> wrote:
>
> Hi All:
>
> In our new file filters ported from Commons IO, we have code like:
>
> } catch (final FileSystemException ex) {
> throw new RuntimeException(ex);
> }
>
> I propose instead that we have the accept() methods throw
> FileSystemException directly.
>
> Gary
>

Re: [commons-parent] branch master updated: japicmp-maven-plugin should not break builds on source incompatible changes by default.

2019-04-19 Thread Gary Gregory 
On Fri, Apr 19, 2019 at 1:19 PM Gilles Sadowski 
wrote:

> Hi.
>
> Le ven. 19 avr. 2019 à 19:09,  a écrit :
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ggregory pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-parent.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new ad831d8  japicmp-maven-plugin should not break builds on source
> incompatible changes by default.
> > ad831d8 is described below
> >
> > commit ad831d8c8eabed2dece24bf3c56015a9f817edd9
> > Author: Gary Gregory 
> > AuthorDate: Fri Apr 19 13:09:42 2019 -0400
> >
> > japicmp-maven-plugin should not break builds on source incompatible
> > changes by default.
>
> Doesn't seem to match the huge change!
>

Hi Gilles,

Must be some tab .vs. space or CR vs. CRLF nonsense :-(

Gary

>
> Gilles
>
> > ---
> >  pom.xml | 3648
> ---
> >  src/changes/changes.xml |1 +
> >  2 files changed, 1826 insertions(+), 1823 deletions(-)
> >
> > [... Too many lines ...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-parent] branch master updated: japicmp-maven-plugin should not break builds on source incompatible changes by default.

2019-04-19 Thread Gilles Sadowski 
Hi.

Le ven. 19 avr. 2019 à 19:09,  a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-parent.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new ad831d8  japicmp-maven-plugin should not break builds on source 
> incompatible changes by default.
> ad831d8 is described below
>
> commit ad831d8c8eabed2dece24bf3c56015a9f817edd9
> Author: Gary Gregory 
> AuthorDate: Fri Apr 19 13:09:42 2019 -0400
>
> japicmp-maven-plugin should not break builds on source incompatible
> changes by default.

Doesn't seem to match the huge change!

Gilles

> ---
>  pom.xml | 3648 
> ---
>  src/changes/changes.xml |1 +
>  2 files changed, 1826 insertions(+), 1823 deletions(-)
>
> [... Too many lines ...]

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

Re: [VFS] Exceptions in new file filter code

2019-04-19 Thread Gary Gregory 
On Fri, Apr 19, 2019 at 11:38 AM Otto Fowler 
wrote:

> Where these written to be used as lambdas?
>

They were not. These were written a long time ago as part of Apache Commons
IO and recently ported to VFS.

Gary


>
>
> On April 19, 2019 at 10:07:28, Gary Gregory (garydgreg...@gmail.com)
> wrote:
>
> Hi All:
>
> In our new file filters ported from Commons IO, we have code like:
>
> } catch (final FileSystemException ex) {
> throw new RuntimeException(ex);
> }
>
> I propose instead that we have the accept() methods throw
> FileSystemException directly.
>
> Gary
>

Re: [VFS] Exceptions in new file filter code

2019-04-19 Thread Otto Fowler 
Where these written to be used as lambdas?


On April 19, 2019 at 10:07:28, Gary Gregory (garydgreg...@gmail.com) wrote:

Hi All:

In our new file filters ported from Commons IO, we have code like:

} catch (final FileSystemException ex) {
throw new RuntimeException(ex);
}

I propose instead that we have the accept() methods throw
FileSystemException directly.

Gary

Re: [rng] Split and Jump functions

2019-04-19 Thread Gilles Sadowski 
Le jeu. 18 avr. 2019 à 21:53, Alex Herbert  a écrit :
>
>
>
> > On 18 Apr 2019, at 14:12, Gilles Sadowski  wrote:
> >
> > Hello Alex.
> >
>  [...]
> >>
> >> OK so this results in:
> >>
> >> /**
> >>  * Some summary.
> >>  */
> >> public interface JumpableUniformRandomProvider extends
> >> UniformRandomProvider {
> >> /**
> >>  * Creates a copy of the UniformRandomProvider and advances the
> >> state of the copy.
> >>  * The state of the current instance is not altered. The state of
> >> the copy will be
> >>  * advanced an equivalent of {@code n} sequential calls to a method
> >> that updates the
> >>  * state of the provider.
> >>  *
> >>  * @return the copy with an advanced state
> >>  */
> >> JumpableUniformRandomProvider jump();
> >> }
> >>
> >
> > +1
> > [Clean and lean: and no side-effects to explain...]
> >
> >>
> >> This can be documented in an implementation as:
> >>
> >> public class MyJumpingRNG implements JumpableUniformRandomProvider {
> >> /**
> >>  * {@inheritDoc}
> >>  *
> >>  * The jump size {@code n} is the equivalent of {@code 2^64}
> >> calls to
> >>  * {@link UniformRandomProvider#nextLong() nextLong()}.
> >>  */
> >> @Override
> >> public JumpableUniformRandomProvider jump() {
> >> // TODO Auto-generated method stub
> >> return null;
> >> }
> >> }
> >
> > +1
> >
> >>
> >> Do we add a second interface for LongJumpableUniformRandomProvider?
> >
> > Sure, if the functionality is provided by some of the algorithms implemented
> > in [RNG].
> > But let's have the two functionalities in separate commits.
> >
> >>
>  So the options are (in all cases returning the copy):
> 
>  1. createAndJumpCopy
>  2. copyAndJumpParent
>  3. jumpParentAndCopy
>  4. jump and copy separately
> 
>  1. Your preferred option. A copy of the state is made. The state is 
>  advanced in the copy and returned. But when called repeatedly it will 
>  get the same generator and code must be organised appropriately.
> >>> We could provide a convenience method in  "RandomSource":
> >>>
> >>> public UniformRandomProvider[] jump(int n,
> >>> JumpableUniformRandomProvider parent) {
> >>> final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
> >>> UniformRandomProvider tmp = parent;
> >>> for (int i = 0; i < n; i++) {
> >>> rngs[i] = restrict(tmp);
> >>> tmp = tmp.jump();
> >>> }
> >>> return rngs;
> >>> }
> >>
> >> +1. Remove the need for the user to repeat boiler plate code.
> >>
> >> Same sort of idea of longJump() too.
> >
> > +1
> >
>  It is not actually possible to jump forward a single instance. Only 
>  children are advanced.
> >>> A feature: There is only one way to alter the state of an instance
> >>> (i.e. a call to "next()").
> >> OK.
> >
> > Great. :-)
> >
> > Gilles
>
> This sounds like a resolution. I will put the ideas into a Jira ticket for 
> Jumpable.

Thanks.

>
> I am a bit busy at the moment with other mini-projects (updates to 
> nextInt(int) being the main one, Poisson samplers (again) being another 
> leading to a family of log normal based distributions that may be supported 
> using cumulative probability look-up tables) but will hope to get this done 
> soon. The actual implementation should be quite easy.
>
> Here’s one for you to think about on the subject of Jumpable. What about 
> support for the generators that can be advanced by a user specified 
> increment? For example the SplitMix algorithm is based on a sequence and so 
> can be advanced from 1 to 2^64-1 steps. It does seem strange to support this 
> (if we add jumpable to SplitMix) using only one specific jump distance. A 
> Skippable can do this:
>
> SkippableURP {
> public SkippableURP skip(long steps);
>
> // or
>
> public SkippableURP skipPower2(long power);
> }
>
> Too much?

You read my mind. ;-)
What would be the uses of "short" jumps (i.e. having small
non-overlapping sequences
from many instances, rather than a longer one from a single instance)?
IIUC, the hard-coded jump sizes in existing implementations seem a compromise,
based on the number of potentially concurrent threads, or independent
simulations.
Increasing that number does not seem necessary for the mid-term.

Regards,
Gilles

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

Re: status and release of commons-scxml-2.0?

2019-04-19 Thread Jacob Beard 
Hi Ate,

Thanks for your reply. I think I could help with these issues, and close the 
gap for full compliance of the js language model.  

I was wondering, did you have a timeline in mind for the 2.0 release? I should 
start to free up in June/July.

Let me know what you think. Thank you,

Jake

> On Apr 18, 2019, at 3:46 PM, Ate Douma  wrote:
> 
> 
> 
>> On 18/04/2019 18.00, Jacob Beard wrote:
>> Hi Ate,
>>> On Apr 18, 2019, at 11:23 AM, Ate Douma  wrote:
>>> 
>>> Only for the javascript language (using Java 8 Nashorn, now deprecated
>>> since Java 11...) there are still 3/188 W3C IRP tests failing.
>>> And those 3 test failures are really, really difficult to fix, because
>>> of limitations/quirks in the Nashorn engine itself.
>> Could you please provide more information on this? Which tests are failing, 
>> and what are the limitations and quirks of Nashorn that cause this?
> 
> Sure.
> 
> Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
> that the Nashorn engine by default doesn't fail on referencing a missing
> property. Which is tested by W3C IRP test 307.
> 
> Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
> which make use of XML DOM APIs in a condition, like:
> 
>  cond="var1.getElementsByTagName('book')[0].getAttribute('title') == 'title1'"
> 
> However Nashorn doesn't provide default/native XML DOM support, and
> adding that would be (at least from my perspective) quite an effort, if
> even properly doable.
> That doesn't feel like worth the effort, with little added value/ROI.
> 
> [1] https://issues.apache.org/jira/browse/SCXML-273
> 
>> Thank you,
>> Jake
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
> 


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

[VFS] Exceptions in new file filter code

2019-04-19 Thread Gary Gregory 
Hi All:

In our new file filters ported from Commons IO, we have code like:

} catch (final FileSystemException ex) {
throw new RuntimeException(ex);
}

I propose instead that we have the accept() methods throw
FileSystemException directly.

Gary

JDK 13 - Early Access build 17 is available

2019-04-19 Thread Rory O'Donnell 


*Hi Benedikt, *

*OpenJDK builds *- JDK 13 - Early Access build 17 is available at 
http://jdk.java.net/13/


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

 * Release notes [1]

*Significant changes since the last availability email*

 * build 16 - Update the default enabled cipher suites preference
   (JDK-8163326 )
 * build 16 - Add new keytool -showinfo -tls command for displaying TLS
   configuration information (JDK-8219861
   )
 * build 15  -*New Japanese Era Name **(JDK-8205432
   )*
 * build 15  - Accessing REIWA era in java.time.chrono.JapaneseEra
   (JDK-8174268 )
 * build 15  - Duplicated RSA services are no longer supported by
   SunJSSE provider (JDK-8220016
   )
 * build 15  - Use server cipher suites preference by default
   (JDK-8168261 )
 * build 15  - The Swing Motif Look and Feel is deprecated and
   unsupported on macOS (JDK-8177960
   )
 * build 15  - Remove support for javadoc "frames" mode (JDK-8215599
   )

Bug fix reported by Open Source Projects  :

 * build 15  - Unable to read certain PKCS12 keystores from
   SequenceInputStream (JDK-8157404)
   

*April 2019 CPU Released*

 * As part of the Apr 2019 Critical Patch Update we released OpenJDK
   12.0.1  under the GNU General Public License, version 2, with the
   Classpath Exception . [2]
 * One change previously announced in the Java Cryptographic Roadmap [3]

*Request for feedback *-  switch expressions in JDK 12  , feedback via 
amber-dev list [4]


Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] http://jdk.java.net/12
[3] https://java.com/en/jre-jdk-cryptoroadmap.html
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-April/002770.html

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