Build failed in Jenkins: commons-jcs #169

[Apache Jenkins Server]

See 

Changes:

[tv] Rework build and packaging

[tv] Add target to svn:ignore

[tv] Rework build and packaging

--
[...truncated 933 lines...]
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/Implements.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/Immutable.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/TestOnly.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/ThreadSafety.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/TODO.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/ThreadSafetyType.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/JavaBean.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/NonNullable.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/UnsupportedOperation.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/CopyRightApache.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/annotation/CopyRightType.java
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/ref
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/ref/KeyedSoftReference.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/ref/IKey.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/ref/KeyedRefCollector.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/lang/ref/KeyedWeakReference.java
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/config
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/config/YajCacheConfig.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/config/PerCacheConfig.java
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CacheChangeEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CacheClearEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CachePutEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CachePutBeanCopyEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/ICacheChangeHandler.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CacheRemoveEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CachePutBeanCloneEvent.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CacheChangeSupport.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/ICacheChangeListener.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/beans/CachePutCopyEvent.java
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/SafeCacheWrapper.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/CacheEntry.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/CacheType.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/ICacheSafe.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/ICache.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/core/CacheManager.java
A 
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/soft
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/soft/SoftRefCache.java
AU
commons-jcs-sandbox/yajcache/src/main/java/org/apache/commons/jcs/yajcache/soft/SoftRefFileCache.java
AUcommons-jcs-sandbox/yajcache/pom.xml
AUcommons-jcs-sandbox/yajcache/README.txt
AUcommons-jcs-sandbox/pom.xml
AURELEASE-NOTES.txt
A   

Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")

[sebb]

On 27 September 2016 at 12:22, Gilles  wrote:
> Hi.
>
> On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
>>
>> Le 27/09/2016 à 01:14, Gilles a écrit :
>>
> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),


 This should go in the ArrayUtils class of commons-lang, with a
 java.util.Random parameter.
>>>
>>>
>>> I don't get that.
>>> The idea is to parameterize the utilities with a "UniformRandomProvider"
>>> instance.
>>
>>
>> My suggestion is to add two methods to ArrayUtils in commons-lang for
>> each primitive type and Object (and maybe a couple more if we want to
>> shuffle only a subset of the array):
>>
>>ArraysUtils.shuffle(Object[] array)
>>ArraysUtils.shuffle(Object[] array, java.util.Random rnd)
>
>
> I (strongly) suggest
>
>   ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider rnd)

Huh?

That would require LANG to depend on RNG.
I am against that.

>>
>> And if we want to shuffle with a random generator from commons-rng, we
>> simply convert the UniformRandomProvider into a java.util.Random using
>> the adapter:
>>
>>RandomProvider rng = RandomSource.create(...);
>>ArraysUtils.shuffle(array, new JDKRandomAdapter(rng));
>>
>> or
>>
>>RandomProvider rng = RandomSource.create(...);
>>ArraysUtils.shuffle(array, rng.asRandom());
>
>
> Similarly, we'd rather overload "shuffle" as follows
>
>   ArraysUtils.shuffle(Object[] array, java.util.Random rnd) {
> shuffle(array, RandomUtils.asUniformRandomProvider(rnd));
>   }
>
> where "RandomUtils" is currently in CM (package "o.a.c.math4.random").
>
> It is not a matter of taste (cf. caveat in "o.a.c.math4.random.RngAdpator").
> The factory method "asUniformRandomProvider" creates an instance that
> redirects all the interface methods to their counterpart in "Random" (when
> they exist): sequence of any type is the same, whether the Random instance
> is wrapped or not.  "RngAdapter" however creates a "Random" instance where
> only 32-bits integers sequences are preserved.
>
> Moreover, the default RNG should be a good one, i.e. not "java.util.Random".
>
> But overall it would be much better to put all this in a new component
> and deprecate all of CL's "Random"-parameterized methods.
> It was noted (not only by me) that CL grew too big (and out of its original
> scope).  "RandomUtils" is relatively small (in Lang 3.4): now is a good
> opportunity to deprecate these few methods and those intended for 3.5
> and redirect users to a dedicated component.

+1

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

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

Early Access builds of JDK 8u122 b01 & JDK 9 EA b138 are available.

[Rory O'Donnell]

Hi Benedikt,

Early Access b01  for JDK 8u122 is 
available on java.net.


Early Access b138  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b138  (#5561) 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  :


 * 8038348 - b137 - Instance field load is replaced by wrong data Phi
 * 8041480 - b137 - ArrayIndexOutOfBoundsException when JTable contains
   certain string
 * 8145542 - b137 - The case failed automatically and thrown
   java.lang.ArrayIndexOutOfBoundsException exception.
 * 8151725 - b137  - [macosx] ArrayIndexOOB exception when displaying
   Devanagari text in JEditorPane

There are two proposals requesting feedback via mailing lists :

 - More proposals for open JPMS issues [1]

 * One proposal to call out is #AwkwardStrongEncapsulation as this
   proposes to change setAccessible(true) so that it can't be used to
   break into non-public types/members in exported packages. This is a
   non-issue when using setAccessible to get access to non-public
   types/members of classes on the class path but will be an issue for
   code that uses this method to break into JDK-internals. We would
   appreciate as much help as possible testing these builds. If
   InaccessibleObjectException is thrown then examine the stack trace
   (run with -Dsun.reflect.debugModuleAccessChecks=true to uncover
   failed access attempts in code that shallows exceptions). If it
   looks like a library is attempting to access a non-public method or
   field of a platform class and make sure to *submit a bug in the
   issue tracker for the library.*

 - Proposal to Reorganize source classes in src.zip by modules [2]

 * This proposal might have a compatibility impact on IDEs or other
   tools that look in src.zip
 * Feedback via the jigsaw-dev mailing list

Other points of interest:

 * JavaOne Presentations
 o Recorded Presentations
   
 * JDK 9 Schedule change proposal
 o for proposed schedule proposal see [3]


Rgds,Rory

[1] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009365.html
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009550.html
[3] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004887.html



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

Re: [RNG] RNG-17 - LFG

[Gilles]

Hello.

On Thu, 6 Oct 2016 18:20:24 +0300, Artem Barger wrote:

Hi,


I was considering​ to give a try and implement RNG-17
 (LFG),


Fine.
But the Javadoc must then contain a warning akin to the one on
the Wikipedia page:
   Marsaglia observed very poor behavior with R(24,55) and smaller
   generators, and advised against using generators of this type
   altogether.
:-{


while I'm complete a
newbie in RNG topic.


Fortunately, one doesn't need to be an expert in order to port
a few lines of code from C (probably) to Java. :-)
But there are quite a few caveats.
That's why I've added those "contribution requirements"...


So I've read a couple of tutorials and IMO I've got an
idea behind the LFG (which doesn't seem that complex).


Most RNG are not complex.
What is complex is to find a _simple_ code that produces
sequences with the expected properties.
Even more so if those properties must be provable.

"Commons RNG" should not have the ambition to ship "home-made"
algorithms.
That's why I've added those "contribution requirements"...



I haven't found in the literature the explanation of how to seed the 
LFG

though,
e.g. I have to create first "m" slots using the seed. However I've 
read in
some article, that Mersenne Twister could be used to seed the LFG. 
And here

comes my first question for you, is that  correct?


Probably, but any procedure that produces a "sufficiently diverse"
initial state would be fine.
Such a procedure could be the output of another RNG.
The "create" factory method does that (i.e. generates an array of
length 128 filled with the output of a WELL generator) when no seed
is provided.

But the seed choice is a _user_ input so either
 (1) he does not give one (and the "create" method does its thing,
 as explained above), or
 (2) he gives one with more elements than the state actually needs,
 and the generator implementation should honor it (i.e. copy the
 seed into the state) since we assume that the user wanted the
 diversity of the seed he gave (no more, no less), or
 (3) he gives one with less elements than the state actually needs,
 and the implementation copies the seed to the state, and then
 uses a procedure to replace the remaining zeroes in the state
 with a more diverse contents based on the seed.


And second question I
was trying to understand how to reuse state initialization within 
current

Mersenne Twister for LFG?


There is a public "fillState" method in "SeedFactory" for taking
care of case (3) above.

I must note that I made up a simple one (for use whenever the
reference code did not provide that functionality).

It's a matter of convention (for "Commons RNG") but we could well
prefer to use the one provided by "MersenneTwister" (which has
changed since its first version), to be on the safe side...

I'll open a JIRA ticket for that.



Also I was thinking whenever it's could be beneficial to de-couple 
seeding

abstraction from actual number generation?


I don't follow (because I think that I did just that).
Could you give an example?

Regards,
Gilles



Best regards,
  Artem Barger.



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

Re: [RNG] Release of v1.0: Schedule update

[Eric Barnhill]

On Fri, Oct 7, 2016 at 8:54 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Dave Brosius wrote:
>
> > I'd just release it, and
> > get some momentum going.
>


+1

Re: [RNG] Release of v1.0: Schedule update

[Jörg Schaible]

Dave Brosius wrote:

> i think people understand an early product having breaking changes. The
> interface is 'small' enough that having to redo a small amount of change
> by clients is not an issue here. Whatever you do, it's likely that you
> will get feedback from clients that you don't expect, which probably
> prompts you to want breaking changes anyway. I'd just release it, and
> get some momentum going.

+1

- Jörg


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