Your are correct, the engine (and the parser) do use its own JexlFeatures
copies (expressionFeatures/scriptFeatures members) that are never modified
after creation. An equivalent rule applies for JexlOptions btw, copied for
isolation for each evaluation. Those classes, by themselves, even if t
On Fri, 20 Oct 2023 at 17:35, Alex Herbert wrote:
>
> Navigating to the Java CI workflow you can generate a badge using the
> ... menu in the top right next to the search filter. This creates a
> badge with a different URL to that currently in use:
>
> Current:
> [![GitHub Actions
> Status](https:
I opened a PR after changing the expected failure probability to 1e-5.
I had an old version of the GH build file when I estimated it used 4
runs. The latest CI runs 4 JDKs on 3 platforms plus CodeQL and
coverage. So this is 14 runs. We should see failures with a
probability of:
(1 - (1 - 1e-5)**1
On Fri, 20 Oct 2023 at 19:09, Henri Biestro wrote:
>
>
> JexlPermissions concrete classes are but since this is an interface, anyone
> could create a non-thread safe instance and use it. The same way a
> JexlFeatures could be corrupted by being constructed with a non-thread safe
> namespace pre
Hi Alex,
I'd prefer if you could give a shot at adjusting this test when you can take
the time.
TY,
Gary
On 2023/10/20 18:17:35 Alex Herbert wrote:
> On Fri, 20 Oct 2023 at 18:55, Alex Herbert wrote:
> >
> > The chi-square critical value (13.82) is correct:
> >
> > >>> from scipy.stats import
On Fri, 20 Oct 2023 at 18:55, Alex Herbert wrote:
>
> The chi-square critical value (13.82) is correct:
>
> >>> from scipy.stats import chi2
> >>> chi2(2).isf(0.001)
> 13.815510557964274
>
> The test seems to fail with the expected frequency when run locally. I
> annotated with:
>
> @RepeatedTest(
JexlPermissions concrete classes are but since this is an interface, anyone
could create a non-thread safe instance and use it. The same way a JexlFeatures
could be corrupted by being constructed with a non-thread safe namespace
predicate (making side-effects etc).
And for JexlFeatures, using
The chi-square critical value (13.82) is correct:
>>> from scipy.stats import chi2
>>> chi2(2).isf(0.001)
13.815510557964274
The test seems to fail with the expected frequency when run locally. I
annotated with:
@RepeatedTest(value = 10)
I observe 93 failures (just under 1 in 1000). So it i
It's possible the chi square test is miscalculated. Perhaps some stats
expert can check that. It's also possible the chi square test isn't
the right one to use here. Again, consult a stats expert.
It's also very possible that the randomness is not nearly as random as
it's supposed to be. That's in
Despite the failure comment:
RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- will
fail about 1 in 1000 times ==> expected: but was:
This test fails a LOT more than once every 1000 times, based on how many GitHub
builds I need to restart every week.
What can be done t
Navigating to the Java CI workflow you can generate a badge using the
... menu in the top right next to the search filter. This creates a
badge with a different URL to that currently in use:
Current:
[![GitHub Actions
Status](https://github.com/apache/commons-build-plugin/workflows/Java%20CI/badge
In general, I assume nothing is thread-safe unless documented as such.
Gary
On Fri, Oct 20, 2023, 12:27 PM sebb wrote:
> Are instances of the classes JexlFeatures and JexlPermissions intended
> to be thread-safe?
>
> I have seen mention that they can be shared between threads.
>
> However Jexl
Are instances of the classes JexlFeatures and JexlPermissions intended
to be thread-safe?
I have seen mention that they can be shared between threads.
However JexlFeatures is does not appear to be thread-safe (has mutable
fields which are not safely published). Not looked at JexlPermissions
in de
The build-plugin readme shows a failing Java CI build:
https://github.com/apache/commons-build-plugin
However the build has been working for ages:
https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml
Any idea how this can be fixed?
Not much point having the badge if it is
It seems that on top of our double trouble with [text], we have run into
another conversion issue with Java 21, this time in [BeanUtils].
I'd like help figuring this one out:
Error:
org.apache.commons.beanutils2.sql.converters.SqlTimeConverterTestCase.testLocale
-- Time elapsed: 0.009 s <<< F
Thank you Alex!
The PR is now merged.
Gary
On Fri, Oct 20, 2023, 4:09 AM Alex Herbert wrote:
> I've implemented a fix for this in PR 467 [1]. Builds now pass on JDK 21.
>
> This does not change the DoubleFormat class. It adds javadoc to state
> that the formatting is dependent on Double.toStri
Greetings!
JDK 21 has been released (General Availability) on September 19th as planned.
You can find "The Arrival of Java 21" announcement here [1], and some
additional Java 21 materials in the "Topics of Interest" section below. On
behalf of the entire Java team, let me send our thanks to all
I've implemented a fix for this in PR 467 [1]. Builds now pass on JDK 21.
This does not change the DoubleFormat class. It adds javadoc to state
that the formatting is dependent on Double.toString.
The tests have been updated to use a different range for the random
doubles so the tests across form
18 matches
Mail list logo