Re: [math] IIR filter library (Butterworth,Bessel,...)

[Arne Ploese]

Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:

(...)

> I'm not too crazy about proper FIR filters in JAVA because even in
> C++ 
> they are just too slow and one would need to write them as JNI calls
> to 
> C to make them run fast enough (for example a 50Hz notch for ECG at
> 1kHz 
> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how 
> excited people here are about C/JNI calls. However the FIR filter 
> _design_ = creating an impulse response is useful for a-causal
> offline 
> computation using the convolution operation (but the 1D convolution
> is 
> already implemented isn't it?).

If the Just In Time compiler of the runtime kicks in, it will go
fast...
You can avoid wrapper code (get|set) and access the fields directly -
ist will improve speed even more. Here is an example of a java
filtering (converted form the signalprocessing package of octave) I did
a couple of years ago:
 https://sourceforge.net/projects/dsp4

(...)

Arne

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

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Eric Barnhill]

Hi Bernd, sounds like we agree on basically everything there is to do.


> I've spent the weekend adding maven support to the IIRJ library. So now
> a simple "mvn install" does the job. Also done the testing properly with
> "mvn test" which generates all the different kinds of impulse responses
> and puts them in different subdirs for evaluation.
> https://github.com/berndporr/iirj


I can confirm that this builds on Ubuntu Mate 16.04 .

The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling for a
commons sub-project.

The one technical question I have is whether it is okay to use Math 3.x as
a dependency for now, presumably substituting spin-out former math
components in later, to ensure that all of our dependencies are actively
maintained. I am going to assume this is okay for reasons of momentum.

So now I must go find a potential project champion..back soon. :)

Best,
Eric

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Bernd Porr]

Opps. Link doesn't work.

Do you mean the OCTAVE/MATLAB "filter" command? If you limit that to FIR
coefficients then that's equivalent literally to a convolution operation
which we already have. (that FIR filtering is the convolution function I
have to de-bunk every year in my DSP class because in teaching nothing
is filtered in realtime so an FIR filter is sold literally as a
convolution operation, however the FIR filter does a convolution as any
other filter but it performs it with the help of a delay line which is
implemented usually as a ring buffer).

Perhaps before we talk about different things.

Can we all agree on the definition of an FIR filter:
https://en.wikipedia.org/wiki/Finite_impulse_response
it takes one sample in and spits one out by using a delay line. Usually
implemented as a ring buffer. In C that can be done very elegantly with
pointer gymnastics:
https://github.com/berndporr/fir1
Arne, do you have an efficient way of doing that in JAVA? That would be
nice.

Best,
/Bernd

On 24/10/16 09:28, Arne Ploese wrote:
> Am Samstag, den 22.10.2016, 23:25 +0100 schrieb Bernd Porr:
>
> (...)
>
>> I'm not too crazy about proper FIR filters in JAVA because even in
>> C++ 
>> they are just too slow and one would need to write them as JNI calls
>> to 
>> C to make them run fast enough (for example a 50Hz notch for ECG at
>> 1kHz 
>> requires 500taps at a bandwidth of 4Hz -- in theory!). Not sure how 
>> excited people here are about C/JNI calls. However the FIR filter 
>> _design_ = creating an impulse response is useful for a-causal
>> offline 
>> computation using the convolution operation (but the 1D convolution
>> is 
>> already implemented isn't it?).
> If the Just In Time compiler of the runtime kicks in, it will go
> fast...
> You can avoid wrapper code (get|set) and access the fields directly -
> ist will improve speed even more. Here is an example of a java
> filtering (converted form the signalprocessing package of octave) I did
> a couple of years ago:
>  https://sourceforge.net/projects/dsp4
>
> (...)
>
> Arne
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Bernd Porr]

Hi Eric,

On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
Thanks for testing. I'm working with xenial actually.
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
Thanks!
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
I think Math 3.x should be fine. I had it at 3.2 and now changed it to
3.6.1 and it works fine. All filters generate the right response.
>
> So now I must go find a potential project champion..back soon. :)
Excellent. :)
/Bernd
>
> Best,
> Eric
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Bernd Porr]

P.S.: Just tested it with 3.0.0. There the Laguerre Root function is not
yet implemented. For 3.0.0 we needed to exclude the Bessel filter. That
works from 3.1.0.


On 24/10/16 10:25, Eric Barnhill wrote:
> Hi Bernd, sounds like we agree on basically everything there is to do.
>
>
>> I've spent the weekend adding maven support to the IIRJ library. So now
>> a simple "mvn install" does the job. Also done the testing properly with
>> "mvn test" which generates all the different kinds of impulse responses
>> and puts them in different subdirs for evaluation.
>> https://github.com/berndporr/iirj
>
> I can confirm that this builds on Ubuntu Mate 16.04 .
>
> The next step, then (I think) is that as a committer, I can submit a
> proposal to get this idea established in the Incubator as a podling for a
> commons sub-project.
>
> The one technical question I have is whether it is okay to use Math 3.x as
> a dependency for now, presumably substituting spin-out former math
> components in later, to ensure that all of our dependencies are actively
> maintained. I am going to assume this is okay for reasons of momentum.
>
> So now I must go find a potential project champion..back soon. :)
>
> Best,
> Eric
>

-- 
www:http://www.berndporr.me.uk/
http://www.linux-usb-daq.co.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work:   +44 (0)141 330 5237
University of Glasgow
School of Engineering
Rankine Building, Oakfield Avenue,
Glasgow, G12 8LT


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

Re: [lang] To Java 7

[Jochen Wiedmann]

On Mon, Oct 24, 2016 at 3:42 AM, sebb  wrote:

> It seems that Java 6 is still supported until Dec 2018 if the user
> purchases Extended Support.

Given that

   a) We don't enforce users to upgrade.
   b) The decision to move to Java 7 doesn't prevent us from opening
a maintenance branch for 3.5.
   c) If we decide for an incompatible change, there is an opportunity
   for other such changes. As a consequence, the next release will
   most likely take some time, and Dec 2018 might easily be in the
   past, when we do that release.

I don't see, why we should bother to care for that fact.

Jochen



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Romain Manni-Bucau]

+1, thanks Thomas

Side note: the tck module has been deactivated cause of packaging=pom but
ran it manually and all tests passed so not an issue for the release since
we don't care of this artifact distribution, just here as a runner.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-24 8:34 GMT+02:00 Benedikt Ritter :

> Hello Thomas
>
> Thomas Vandahl  schrieb am So., 23. Okt. 2016 um 12:16 Uhr:
>
> > Hi Benedikt,
> >
> > On 23.10.16 10:51, Benedikt Ritter wrote:
> > > Hello Thomas,
> > >
> > > The build works with Java 8 and Maven 3.3.9.
> > >
> > > But the md5 and SHA1 files are missing in the dist area.
> > >
> > > -1
> > >
> >
> > I thought the signatures were sufficient. I added the check sums with
> > r16631. Please check again.
> >
>
> Sorry, if that has been decided, I must have missed it. I'll take another
> look tonight.
>
> Regards,
> Benedikt
>
>
> >
> > Bye, Thomas.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Johannes Weberhofer]

Am 21.10.2016 um 19:42 schrieb Thomas Vandahl:

I would like to beta-release the [jcs] component.

Apache Commons JCS 2.0-beta-2 RC1 is available for review at:
  https://dist.apache.org/repos/dist/dev/commons/jcs/ (r16621).

Maven artifacts are at:
  https://repository.apache.org/content/repositories/orgapachecommons-1211 .

The Subversion tag is:

https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2
 (r1766068).

The release notes are at:

https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2/RELEASE-NOTES.txt
(r1766068).

Please review the release candidate and vote.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Please be lenient with me as this is my first Commons release attempt.

Bye, Thomas

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



Dear Thomas,

thanks for releasing that version! Compared to former builds the tests are much 
faster (When I remember right, it took me more than 10 minutes to create a 
package before). This is a non-binding +1!

I have replaced a beta1 version by this version in a testing software it runs 
without any issues so far.

Best regard,
Johannes


Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /opt/apache-maven
Java version: 1.8.0_101, vendor: Oracle Corporation
Java home: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.8.2-3.g5e4310e-default", arch: "amd64", family: 
"unix"

[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Commons JCS . SUCCESS [ 25.442 s]
[INFO] Apache Commons JCS :: Core . SUCCESS [03:49 min]
[INFO] Apache Commons JCS :: JCache ... SUCCESS [  2.810 s]
[INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [  2.437 s]
[INFO] Apache Commons JCS :: JCache Extras  SUCCESS [  7.353 s]
[INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [  3.318 s]
[INFO] Apache Commons JCS :: Distribution . SUCCESS [  0.218 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 04:31 min
[INFO] Finished at: 2016-10-24T12:24:41+02:00
[INFO] Final Memory: 58M/489M
[INFO] 



--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna

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

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Gilles]

Hi.


[...]


The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling 
for a

commons sub-project.


I suggest to use the sandbox, within "Commons".


Thanks!


The one technical question I have is whether it is okay to use Math 
3.x as

a dependency for now, presumably substituting spin-out former math
components in later, to ensure that all of our dependencies are 
actively
maintained. I am going to assume this is okay for reasons of 
momentum.
I think Math 3.x should be fine. I had it at 3.2 and now changed it 
to

3.6.1 and it works fine. All filters generate the right response.


If you need to depend on "Commons Math", please depend on the
development version (a.k.a. CM version 4), as it is from there
that code must extracted to create candidate components.

Whatever you need to depend on for the "filter" package is a
strong candidate to examine thoroughly and revamp, if necessary,
for inclusion in a component of its own (or "filter" itself).

Best regards,
Gilles



[...]



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

Re: [lang] To Java 7

[Emmanuel Bourg]

Le 23/10/2016 à 09:30, Gary Gregory a écrit :

> Thoughts?

If this means doing only trivial internal code changes with no benefit
to the end users then I don't think it's worth it. I would either stick
to Java 6 or go to Java 8 and offer some real new stuff.

Emmanuel Bourg


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

Re: [lang] To Java 7

[Matt Sicker]

Keeping open a maintenance branch for 3.5 sounds like a good idea. If it
really does end up taking over a year before a 3.6 release needs to be
made, then Java 6 may be a moot point by then. Either way, it sounds like
migrating to Java 7 for a 3.6 release isn't a bad idea unless it turns out
there are no useful API additions that can be made without jumping to Java
8.

On 24 October 2016 at 08:35, Emmanuel Bourg  wrote:

> Le 23/10/2016 à 09:30, Gary Gregory a écrit :
>
> > Thoughts?
>
> If this means doing only trivial internal code changes with no benefit
> to the end users then I don't think it's worth it. I would either stick
> to Java 6 or go to Java 8 and offer some real new stuff.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: [math] IIR filter library (Butterworth,Bessel,...)

[Bernd Porr]

On 24/10/16 14:26, Gilles wrote:

Hi.


[...]


The next step, then (I think) is that as a committer, I can submit a
proposal to get this idea established in the Incubator as a podling
for a
commons sub-project.


I suggest to use the sandbox, within "Commons".

Stupid queston: where do I find that?

In terms of directory structure. Just now the "filter subdir" contains a 
couple of classes all belonging to the Kalman filter.


Then I'll be adding a couple of classes belonging the IIR filters.

At some point somebody will be adding classes for FIR filters.

Perhaps one could create subdirs:

filter - Kalman
   - IIR
   - FIR
   - ...

What do you think?




Thanks!


The one technical question I have is whether it is okay to use Math
3.x as
a dependency for now, presumably substituting spin-out former math
components in later, to ensure that all of our dependencies are actively
maintained. I am going to assume this is okay for reasons of momentum.

I think Math 3.x should be fine. I had it at 3.2 and now changed it to
3.6.1 and it works fine. All filters generate the right response.


If you need to depend on "Commons Math", please depend on the
development version (a.k.a. CM version 4), as it is from there
that code must extracted to create candidate components.
That makes sense. I use heavily the Complex numbers of Commons Math and 
the Laguerre root finder. No other dependencies.




Whatever you need to depend on for the "filter" package is a
strong candidate to examine thoroughly and revamp, if necessary,
for inclusion in a component of its own (or "filter" itself).

No sure what you mean by this. Can give an example?

So, that do I need to do at this point?

Best,
/Bernd



Best regards,
Gilles



[...]



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



--
http://www.berndporr.me.uk
http://www.linux-usb-daq.co.uk
http://www.imdb.com/name/nm3293421/
+44 (0)7840 340069

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

Re: [lang] To Java 7

[Stian Soiland-Reyes]

I don't think we need to keep arguing this, when we discussed this
last time we said we'll do an intermediate Java 7-version - if there
are too many screams (I suspect almost none) then we can be more
careful before moving to Java 8 afterwards, which would give the
biggest benefit (and need more help from Lang).

In a way Java 7 will mainly just give us style benefits and a couple
of code simplifications, which is important to make Commons Lang's
code more inviting for new contributors.

On 24 October 2016 at 14:41, Matt Sicker  wrote:
> Keeping open a maintenance branch for 3.5 sounds like a good idea. If it
> really does end up taking over a year before a 3.6 release needs to be
> made, then Java 6 may be a moot point by then. Either way, it sounds like
> migrating to Java 7 for a 3.6 release isn't a bad idea unless it turns out
> there are no useful API additions that can be made without jumping to Java
> 8.
>
> On 24 October 2016 at 08:35, Emmanuel Bourg  wrote:
>
>> Le 23/10/2016 à 09:30, Gary Gregory a écrit :
>>
>> > Thoughts?
>>
>> If this means doing only trivial internal code changes with no benefit
>> to the end users then I don't think it's worth it. I would either stick
>> to Java 6 or go to Java 8 and offer some real new stuff.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker 



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[sebb]

On 24 October 2016 at 07:34, Benedikt Ritter  wrote:
> Hello Thomas
>
> Thomas Vandahl  schrieb am So., 23. Okt. 2016 um 12:16 Uhr:
>
>> Hi Benedikt,
>>
>> On 23.10.16 10:51, Benedikt Ritter wrote:
>> > Hello Thomas,
>> >
>> > The build works with Java 8 and Maven 3.3.9.
>> >
>> > But the md5 and SHA1 files are missing in the dist area.
>> >
>> > -1
>> >
>>
>> I thought the signatures were sufficient. I added the check sums with
>> r16631. Please check again.
>>
>
> Sorry, if that has been decided, I must have missed it.

An MD5 hash is still required as well as the sig, see:

http://www.apache.org/dev/release-signing.html#basic-facts


> I'll take another
> look tonight.
>
> Regards,
> Benedikt
>
>
>>
>> Bye, Thomas.
>>
>>
>> -
>> 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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Mark Struberg]

+1

LieGrue,
strub


> Am 24.10.2016 um 14:36 schrieb Johannes Weberhofer 
> :
> 
> 
> 
> Am 21.10.2016 um 19:42 schrieb Thomas Vandahl:
>> I would like to beta-release the [jcs] component.
>> 
>> Apache Commons JCS 2.0-beta-2 RC1 is available for review at:
>>  https://dist.apache.org/repos/dist/dev/commons/jcs/ (r16621).
>> 
>> Maven artifacts are at:
>>  https://repository.apache.org/content/repositories/orgapachecommons-1211 .
>> 
>> The Subversion tag is:
>> 
>> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2
>> (r1766068).
>> 
>> The release notes are at:
>> 
>> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0-beta-2/RELEASE-NOTES.txt
>> (r1766068).
>> 
>> Please review the release candidate and vote.
>> 
>>  [ ] +1 Release these artifacts
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
>>  [ ] -1 I oppose this release because...
>> 
>> Please be lenient with me as this is my first Commons release attempt.
>> 
>> Bye, Thomas
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> Dear Thomas,
> 
> thanks for releasing that version! Compared to former builds the tests are 
> much faster (When I remember right, it took me more than 10 minutes to create 
> a package before). This is a non-binding +1!
> 
> I have replaced a beta1 version by this version in a testing software it runs 
> without any issues so far.
> 
> Best regard,
> Johannes
> 
> 
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
> 2015-11-10T17:41:47+01:00)
> Maven home: /opt/apache-maven
> Java version: 1.8.0_101, vendor: Oracle Corporation
> Java home: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "4.8.2-3.g5e4310e-default", arch: "amd64", family: 
> "unix"
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Commons JCS . SUCCESS [ 25.442 
> s]
> [INFO] Apache Commons JCS :: Core . SUCCESS [03:49 
> min]
> [INFO] Apache Commons JCS :: JCache ... SUCCESS [  2.810 
> s]
> [INFO] Apache Commons JCS :: JCache TCK ... SUCCESS [  2.437 
> s]
> [INFO] Apache Commons JCS :: JCache Extras  SUCCESS [  7.353 
> s]
> [INFO] Apache Commons JCS :: JCache OpenJPA ... SUCCESS [  3.318 
> s]
> [INFO] Apache Commons JCS :: Distribution . SUCCESS [  0.218 
> s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 04:31 min
> [INFO] Finished at: 2016-10-24T12:24:41+02:00
> [INFO] Final Memory: 58M/489M
> [INFO] 
> 
> 
> 
> 
> -- 
> Johannes Weberhofer
> Weberhofer GmbH, Austria, Vienna
> 
> -
> 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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Thomas Vandahl]

On 21.10.16 19:42, Thomas Vandahl wrote:
>   [X] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...

My own vote.

Bye, Thomas


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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Thomas Vandahl]

Hi Romain,

On 24.10.16 12:44, Romain Manni-Bucau wrote:
> +1, thanks Thomas
> 
> Side note: the tck module has been deactivated cause of packaging=pom but
> ran it manually and all tests passed so not an issue for the release since
> we don't care of this artifact distribution, just here as a runner.

The build failed with the default packaging at some point with the
message "no primary artifact", so I decided to change it to POM. I'll
see how this can be fixed later.

Bye, Thomas



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

Re: [VOTE] Release Apache Commons JCS 2.0-beta-2 based on RC1

[Romain Manni-Bucau]

2016-10-24 21:03 GMT+02:00 Thomas Vandahl :

> Hi Romain,
>
> On 24.10.16 12:44, Romain Manni-Bucau wrote:
> > +1, thanks Thomas
> >
> > Side note: the tck module has been deactivated cause of packaging=pom but
> > ran it manually and all tests passed so not an issue for the release
> since
> > we don't care of this artifact distribution, just here as a runner.
>
> The build failed with the default packaging at some point with the
> message "no primary artifact", so I decided to change it to POM. I'll
> see how this can be fixed later.
>
>
No problem, works for me so maybe linked to release profile. Happy to help
if you struggle with it too much.


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

Re: [lang] LANG-1144: Multiple calls of org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible

[Oliver Heger]

Am 23.10.2016 um 22:18 schrieb pascalschumac...@apache.org:
> Repository: commons-lang
> Updated Branches:
>   refs/heads/master 96c8ea2fb -> dc53e49b4
> 
> 
> LANG-1144: Multiple calls of 
> org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible
> 
> minimal clean-up
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/dc53e49b
> Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/dc53e49b
> Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/dc53e49b
> 
> Branch: refs/heads/master
> Commit: dc53e49b4afa5d59c533cf2b4918402c37411fbd
> Parents: 96c8ea2
> Author: pascalschumacher 
> Authored: Sun Oct 23 22:18:47 2016 +0200
> Committer: pascalschumacher 
> Committed: Sun Oct 23 22:18:47 2016 +0200
> 
> --
>  .../commons/lang3/concurrent/LazyInitializer.java  | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-lang/blob/dc53e49b/src/main/java/org/apache/commons/lang3/concurrent/LazyInitializer.java
> --
> diff --git 
> a/src/main/java/org/apache/commons/lang3/concurrent/LazyInitializer.java 
> b/src/main/java/org/apache/commons/lang3/concurrent/LazyInitializer.java
> index a0f903c..ed84049 100644
> --- a/src/main/java/org/apache/commons/lang3/concurrent/LazyInitializer.java
> +++ b/src/main/java/org/apache/commons/lang3/concurrent/LazyInitializer.java
> @@ -78,11 +78,12 @@ package org.apache.commons.lang3.concurrent;
>   * @param  the type of the object managed by this initializer class
>   */
>  public abstract class LazyInitializer implements ConcurrentInitializer 
> {
> +
> +private static final Object noInit = new Object();
> +
> +@SuppressWarnings("unchecked")
>  /** Stores the managed object. */

Minor nit: As the field is now a constant, it should - according to the
Sun coding conventions - be named in uppercase: NO_INIT.

Oliver

> -
> -private static final Object NoInit = new Object();
> -
> -private volatile T object = (T) NoInit;
> +private volatile T object = (T) noInit;
>  
>  /**
>   * Returns the object wrapped by this instance. On first access the 
> object
> @@ -98,10 +99,10 @@ public abstract class LazyInitializer implements 
> ConcurrentInitializer {
>  // volatile field
>  T result = object;
>  
> -if (result == NoInit) {
> +if (result == noInit) {
>  synchronized (this) {
>  result = object;
> -if (result == NoInit) {
> +if (result == noInit) {
>  object = result = initialize();
>  }
>  }
> 

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

Re: [lang] LANG-1144: Multiple calls of org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible

[Pascal Schumacher]

Am 24.10.2016 um 22:35 schrieb Oliver Heger:


Minor nit: As the field is now a constant, it should - according to the
Sun coding conventions - be named in uppercase: NO_INIT.
I thought that only applied to public constants, but I was wrong. I have 
changed the field name.


Thanks,
Pascal

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