[MATH] Jenkins build

classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[MATH] Jenkins build

sebb-2-2
I've had to give up trying to get Continuum to use Git, so I set up a
Jenkins build for Math

It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
variables don't seem to have been set up on the Jenkins hosts, so the
-Pjava-1.5 profile does not work as is.

However I found that the JAVA_1_5_HOME variable can be defined on the
Maven command-line.

This works, provided that Java 1.5 is always installed in the same
location on different hosts.

[The JAVA_1_x_HOME variables were designed get around this
restriction, as they can be differently defined on different hosts]

Hopefully the builds will be useful in detecting accidental use of
Java 1.6+ APIs

So far I have only added Commons Math itself.
I hope to add the examples shortly.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Math] Java version (Was: [MATH] Jenkins build)

Gilles Sadowski
Hi.

Raising this issue once again.
Are we going to upgrade the requirement for the next major release?

  [ ] Java 5
  [ ] Java 6
  [ ] Java 7
  [ ] Java 8
  [ ] Java 9

?

Gilles


On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:

> I've had to give up trying to get Continuum to use Git, so I set up a
> Jenkins build for Math
>
> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
> variables don't seem to have been set up on the Jenkins hosts, so the
> -Pjava-1.5 profile does not work as is.
>
> However I found that the JAVA_1_5_HOME variable can be defined on the
> Maven command-line.
>
> This works, provided that Java 1.5 is always installed in the same
> location on different hosts.
>
> [The JAVA_1_x_HOME variables were designed get around this
> restriction, as they can be differently defined on different hosts]
>
> Hopefully the builds will be useful in detecting accidental use of
> Java 1.6+ APIs
>
> So far I have only added Commons Math itself.
> I hope to add the examples shortly.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

Martin Grotle Soukup
Hi,

I am only a user of the library, but I would be excited to see CM take
advantage of the new features of java 8.

Best regards,
Martin Grotle Soukup


2015-01-08 12:34 GMT+01:00 Gilles <[hidden email]>:

> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [x] Java 8
>  [ ] Java 9
>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
>
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

Benedikt Ritter-4
2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
[hidden email]>:

> Hi,
>
> I am only a user of the library, but I would be excited to see CM take
> advantage of the new features of java 8.
>
> Best regards,
> Martin Grotle Soukup
>
>
> 2015-01-08 12:34 GMT+01:00 Gilles <[hidden email]>:
>
> > Hi.
> >
> > Raising this issue once again.
> > Are we going to upgrade the requirement for the next major release?
> >
> >  [ ] Java 5
> >  [ ] Java 6
> >  [ ] Java 7
> >  [x] Java 8
>

The java.util.function package seems like a natural fit for a mathematics
library. OTOH my feeling is, that most users are still using Java 6/7...

Benedikt


> >  [ ] Java 9
> >
> > ?
> >
> > Gilles
> >
> >
> > On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
> >
> >> I've had to give up trying to get Continuum to use Git, so I set up a
> >> Jenkins build for Math
> >>
> >> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
> >> variables don't seem to have been set up on the Jenkins hosts, so the
> >> -Pjava-1.5 profile does not work as is.
> >>
> >> However I found that the JAVA_1_5_HOME variable can be defined on the
> >> Maven command-line.
> >>
> >> This works, provided that Java 1.5 is always installed in the same
> >> location on different hosts.
> >>
> >> [The JAVA_1_x_HOME variables were designed get around this
> >> restriction, as they can be differently defined on different hosts]
> >>
> >> Hopefully the builds will be useful in detecting accidental use of
> >> Java 1.6+ APIs
> >>
> >> So far I have only added Commons Math itself.
> >> I hope to add the examples shortly.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

Silviu Burcea
My clients started to use Java 7 a few months before, so I wouldn't choose
Java 8. I know it's new and shinny and as a developer I'd love to play with
it, but unfortunately, users are using it. I'd go for Java 7 and plan Java
8 for Math 5.0

On Thu, Jan 8, 2015 at 4:16 PM, Benedikt Ritter <[hidden email]> wrote:

> 2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup <
> [hidden email]>:
>
> > Hi,
> >
> > I am only a user of the library, but I would be excited to see CM take
> > advantage of the new features of java 8.
> >
> > Best regards,
> > Martin Grotle Soukup
> >
> >
> > 2015-01-08 12:34 GMT+01:00 Gilles <[hidden email]>:
> >
> > > Hi.
> > >
> > > Raising this issue once again.
> > > Are we going to upgrade the requirement for the next major release?
> > >
> > >  [ ] Java 5
> > >  [ ] Java 6
> > >  [ ] Java 7
> > >  [x] Java 8
> >
>
> The java.util.function package seems like a natural fit for a mathematics
> library. OTOH my feeling is, that most users are still using Java 6/7...
>
> Benedikt
>
>
> > >  [ ] Java 9
> > >
> > > ?
> > >
> > > Gilles
> > >
> > >
> > > On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
> > >
> > >> I've had to give up trying to get Continuum to use Git, so I set up a
> > >> Jenkins build for Math
> > >>
> > >> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
> > >> variables don't seem to have been set up on the Jenkins hosts, so the
> > >> -Pjava-1.5 profile does not work as is.
> > >>
> > >> However I found that the JAVA_1_5_HOME variable can be defined on the
> > >> Maven command-line.
> > >>
> > >> This works, provided that Java 1.5 is always installed in the same
> > >> location on different hosts.
> > >>
> > >> [The JAVA_1_x_HOME variables were designed get around this
> > >> restriction, as they can be differently defined on different hosts]
> > >>
> > >> Hopefully the builds will be useful in detecting accidental use of
> > >> Java 1.6+ APIs
> > >>
> > >> So far I have only added Commons Math itself.
> > >> I hope to add the examples shortly.
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



--
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

Phil Steitz
In reply to this post by Gilles Sadowski
On 1/8/15 4:34 AM, Gilles wrote:

> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [x] Java 7
>  [ ] Java 8
>  [ ] Java 9

Phil

>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
>> I've had to give up trying to get Continuum to use Git, so I set
>> up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so
>> the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on
>> the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

James Carman
In reply to this post by Gilles Sadowski
I wouldn't think you'd want to begin anything "new" using an EOLed
version of Java.  I'd go with at least 7.

On Thu, Jan 8, 2015 at 6:34 AM, Gilles <[hidden email]> wrote:

> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9
>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
>>
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version (Was: [MATH] Jenkins build)

Luc Maisonobe-2
In reply to this post by Gilles Sadowski
Le 08/01/2015 12:34, Gilles a écrit :

> Hi.
>
> Raising this issue once again.
> Are we going to upgrade the requirement for the next major release?
>
>  [ ] Java 5
>  [ ] Java 6
>  [ ] Java 7
>  [ ] Java 8
>  [ ] Java 9

I would say 7 or 8.

best regards,
Luc

>
> ?
>
> Gilles
>
>
> On Thu, 8 Jan 2015 10:34:20 +0000, sebb wrote:
>> I've had to give up trying to get Continuum to use Git, so I set up a
>> Jenkins build for Math
>>
>> It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME
>> variables don't seem to have been set up on the Jenkins hosts, so the
>> -Pjava-1.5 profile does not work as is.
>>
>> However I found that the JAVA_1_5_HOME variable can be defined on the
>> Maven command-line.
>>
>> This works, provided that Java 1.5 is always installed in the same
>> location on different hosts.
>>
>> [The JAVA_1_x_HOME variables were designed get around this
>> restriction, as they can be differently defined on different hosts]
>>
>> Hopefully the builds will be useful in detecting accidental use of
>> Java 1.6+ APIs
>>
>> So far I have only added Commons Math itself.
>> I hope to add the examples shortly.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Gilles Sadowski
>> Raising this issue once again.
>> Are we going to upgrade the requirement for the next major release?
>>
>>  [ ] Java 5
>>  [ ] Java 6
>>  [ ] Java 7
>>  [ ] Java 8
>>  [ ] Java 9

Counts up to now:

Java 7      -> 2
Java 7 or 8 -> 2
Java 8      -> 2

Any more opionions?

Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

ole ersoy
I would love to see Java 8.

Ole

On 01/13/2015 07:31 PM, Gilles wrote:

>>> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>
> Counts up to now:
>
> Java 7      -> 2
> Java 7 or 8 -> 2
> Java 8      -> 2
>
> Any more opionions?
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

garydgregory
In reply to this post by Gilles Sadowski
Java 7 or 8.

Gary

On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
wrote:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7      -> 2
> Java 7 or 8 -> 2
> Java 8      -> 2
>
> Any more opionions?
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Martin Grotle Soukup
In reply to this post by Gilles Sadowski
Hi,

My two cents in favour of java 8:

IIUC the next major release will break backwards compatibility and aims to
clean up the API. Taking a look at the release frequency of commons math
[1], it shows releases every 9-12 months (give or take). Given that the
next big release is a major one (4.0), this indicate that a release in 2016
is a more likely target than in 2015.

It might be the case that people use java 6 or 7 today, but the picture
might be a different one a year from now.

I agree with Benedikt Ritter's comment earlier in this thread: "The
java.util.function package seems like a natural fit for a mathematics
library."

Vennlig hilsen
Martin Grotle Soukup
(+47) 95 90 34 02

[1] Latest releases of commons math:
2.2: 2011-03-02
3.0: 2012-03-12
3.1: 2012-12-24
3.2: 2013-04-07
3.3: 2014-05-16
3.4: 2014-12-28



2015-01-14 2:31 GMT+01:00 Gilles <[hidden email]>:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7      -> 2
> Java 7 or 8 -> 2
> Java 8      -> 2
>
> Any more opionions?
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

sebb-2-2
On 14 January 2015 at 08:18, Martin Grotle Soukup
<[hidden email]> wrote:

> Hi,
>
> My two cents in favour of java 8:
>
> IIUC the next major release will break backwards compatibility and aims to
> clean up the API. Taking a look at the release frequency of commons math
> [1], it shows releases every 9-12 months (give or take). Given that the
> next big release is a major one (4.0), this indicate that a release in 2016
> is a more likely target than in 2015.
>
> It might be the case that people use java 6 or 7 today, but the picture
> might be a different one a year from now.

Does Java 8 offer any benefits to the user?

i.e. if CM is released for Java 7 or Java 6 would that impact on
people running Java 8?

As a comparison, libraries that have not been updated to Java 5
generics do make a difference to Java 5+ users.
But enhanced for loops have no direct impact on the user.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Phil Steitz
On 1/14/15 4:38 AM, sebb wrote:

> On 14 January 2015 at 08:18, Martin Grotle Soukup
> <[hidden email]> wrote:
>> Hi,
>>
>> My two cents in favour of java 8:
>>
>> IIUC the next major release will break backwards compatibility and aims to
>> clean up the API. Taking a look at the release frequency of commons math
>> [1], it shows releases every 9-12 months (give or take). Given that the
>> next big release is a major one (4.0), this indicate that a release in 2016
>> is a more likely target than in 2015.
>>
>> It might be the case that people use java 6 or 7 today, but the picture
>> might be a different one a year from now.
> Does Java 8 offer any benefits to the user?

No one has said much about this.  Could be some APIs could be
expressed better, but no one has provided any examples.
>
> i.e. if CM is released for Java 7 or Java 6 would that impact on
> people running Java 8?

No, unless they want to see language features used that are not used.
>
> As a comparison, libraries that have not been updated to Java 5
> generics do make a difference to Java 5+ users.
> But enhanced for loops have no direct impact on the user.

There are really three things to think about when deciding whether
to require JDK x+

 1. Are there things you can't do / express without JDK x?
 2. Does requiring JDK x+ cut out a large portion of the user base?
 3. Are there a lot of things that are easier / simpler / more fun
    to implement in JDK x+?

Items 1. and 3. really impact developers and contributors; but being
too far out in 2. can indirectly influence that as well.  We went
for a long time requiring only 1.5 because there really was nothing
material for [math] in 1. and 3. included only a few things (most
commonly the compat bug I introduced in 3.4.1 due to missing array
copy, which is something we do a lot in [math]).

I think Martin's point on timing is a good one.  The last time I
looked at stats, the thundering herd was still 6-7.  Could be by the
time we actually cut 4.0, that will have changed.

It would be great though if someone could give some positive reasons
that JDK 8+ features really help us.  I am still in the 7 camp, due
to where the users are now; but if there are compelling 1. or 3.
things, I would be OK bumping to 8.

Phil

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

ole ersoy
Converting an example from the user guide using Lambdas (Not an expert so bear with me - And note that the inputArray > inputStream):

BEFORE:

// Get a DescriptiveStatistics instance
DescriptiveStatistics stats = new DescriptiveStatistics();

// Add the data from the array
for( int i = 0; i < inputArray.length; i++) {
         stats.addValue(inputArray[i]);
}

AFTER:
DescriptiveStatistics stats = new DescriptiveStatistics();
inputStream.forEach( value -> stats.addValue(value));

And now we can use Java 8's map, reduce, filter, sum, parallel, etc. on the inputStream.

Part of the reason for the rapid growth of NodeJS is that developers like functional programming.
Constructs like forEach, filter, map, and reduce are popular.  This paper has a lot of great examples
of things that can be done with these functions, and demonstrates adding simple concurrency with parallel().
http://ref.c24.biz/whitepapers/Java-8-for-Financial-Services.pdf

Cheers,
- Ole


On 01/14/2015 10:16 AM, Phil Steitz wrote:

> On 1/14/15 4:38 AM, sebb wrote:
>> On 14 January 2015 at 08:18, Martin Grotle Soukup
>> <[hidden email]> wrote:
>>> Hi,
>>>
>>> My two cents in favour of java 8:
>>>
>>> IIUC the next major release will break backwards compatibility and aims to
>>> clean up the API. Taking a look at the release frequency of commons math
>>> [1], it shows releases every 9-12 months (give or take). Given that the
>>> next big release is a major one (4.0), this indicate that a release in 2016
>>> is a more likely target than in 2015.
>>>
>>> It might be the case that people use java 6 or 7 today, but the picture
>>> might be a different one a year from now.
>> Does Java 8 offer any benefits to the user?
> No one has said much about this.  Could be some APIs could be
> expressed better, but no one has provided any examples.
>> i.e. if CM is released for Java 7 or Java 6 would that impact on
>> people running Java 8?
> No, unless they want to see language features used that are not used.
>> As a comparison, libraries that have not been updated to Java 5
>> generics do make a difference to Java 5+ users.
>> But enhanced for loops have no direct impact on the user.
> There are really three things to think about when deciding whether
> to require JDK x+
>
>   1. Are there things you can't do / express without JDK x?
>   2. Does requiring JDK x+ cut out a large portion of the user base?
>   3. Are there a lot of things that are easier / simpler / more fun
>      to implement in JDK x+?
>
> Items 1. and 3. really impact developers and contributors; but being
> too far out in 2. can indirectly influence that as well.  We went
> for a long time requiring only 1.5 because there really was nothing
> material for [math] in 1. and 3. included only a few things (most
> commonly the compat bug I introduced in 3.4.1 due to missing array
> copy, which is something we do a lot in [math]).
>
> I think Martin's point on timing is a good one.  The last time I
> looked at stats, the thundering herd was still 6-7.  Could be by the
> time we actually cut 4.0, that will have changed.
>
> It would be great though if someone could give some positive reasons
> that JDK 8+ features really help us.  I am still in the 7 camp, due
> to where the users are now; but if there are compelling 1. or 3.
> things, I would be OK bumping to 8.
>
> Phil
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Hank Grabowski
In reply to this post by Gilles Sadowski
Java 8 has only been out for less than a year.  There is still a sizable
percentage of groups that have not converted up to Java 8 for myriad
reasons.  While I was surprised that we are requiring backwards
compatibility with the ten year old Java 5 I think jumping all the way to
requiring Java 8 may be a bit too much of a stretch.  I would vote for a
minimum required version of Java 7 with the ability to run in Java 8.  I
wish I could find metrics to quantify the penetration of each of the JDKs,
but my gut says Java 7 would a reasonable cutoff.

On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
wrote:

> Raising this issue once again.
>>> Are we going to upgrade the requirement for the next major release?
>>>
>>>  [ ] Java 5
>>>  [ ] Java 6
>>>  [ ] Java 7
>>>  [ ] Java 8
>>>  [ ] Java 9
>>>
>>
> Counts up to now:
>
> Java 7      -> 2
> Java 7 or 8 -> 2
> Java 8      -> 2
>
> Any more opionions?
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Silviu Burcea
I think Rebel Labs or Plumbr have some metrics about JDK usage.

On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <[hidden email]>
wrote:

> Java 8 has only been out for less than a year.  There is still a sizable
> percentage of groups that have not converted up to Java 8 for myriad
> reasons.  While I was surprised that we are requiring backwards
> compatibility with the ten year old Java 5 I think jumping all the way to
> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> minimum required version of Java 7 with the ability to run in Java 8.  I
> wish I could find metrics to quantify the penetration of each of the JDKs,
> but my gut says Java 7 would a reasonable cutoff.
>
> On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
> wrote:
>
> > Raising this issue once again.
> >>> Are we going to upgrade the requirement for the next major release?
> >>>
> >>>  [ ] Java 5
> >>>  [ ] Java 6
> >>>  [ ] Java 7
> >>>  [ ] Java 8
> >>>  [ ] Java 9
> >>>
> >>
> > Counts up to now:
> >
> > Java 7      -> 2
> > Java 7 or 8 -> 2
> > Java 8      -> 2
> >
> > Any more opionions?
> >
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
- OCPJP7 (90%)
- OCAJP7 (93%)
- Java and Big Data Enthusiast
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Hank Grabowski
Good call, Silviu!

The most recent version of their survey of Plumbr installations (823 in
total) was May of last year, only a few months after Java 8 came out (link
below).  At that time the break down was: Java 5 at 0.4%, Java 6 at 36%,
Java 7 at 61% and Java 8 at 2.5%.  I'm still looking for more data on this,
but Rebel Labs has a similar article (not broken down by version) that
showed that 65% of development was on Java 7 by May of last year too.  I
doubt the balance was Java 8 at that point, so there must be a sizable Java
6 contingent still.

One other thing that came to mind with the new Java 8 features is how that
is supported on Android.  As far as I can tell Android KitKat, as well as
the latest release of the Android Studio and SDK Tools doesn't support Java
8 yet.  In fact, according to the Android development setup page versions
between (and including) Gingerbread and KitKat require JDK 6, not 7.  I
haven't coded Android recently to know whether it does work on JDK 7 or if
is just a requirement but it is peculiar that the main instructions call
for JDK 7 installation and then the footnote specifically tells developers
to pull a different JDK version for those earlier platforms.  I can't tell
where the Java 7 language features were added to Android before the current
version, Lollipop.  I was surprised Lollipop wasn't on their dashboard but
according to the AppBrain statistics it accounts for far less than 1% of
the installed phones.  So best case scenario would be Jelly Bean supports 7
(no indication that's true), which means 85% of Android devices would be
covered if we set a Java 7 minimum.  Next best would be KitKat (more likely
but not according to the install instructions) which means 39%.  As for
Java 5, that was needed for pre-Gingerbread Android OS which accounts for
0.5% of the market.

I guess with all of that it's clear that Java 5 is unnecessarily being
maintained at this point.  Both surveys of servers and Android show far
less than 1% usage.  It seems Java 6 penetration may be still be pretty
substantial, even conservatively at on the order of 25% (if Java 7 and 8
adoption picked up dramatically in 6 months after the surveys as I imagine
it did to some extent).  So it seems the most reasonable conservative play
would be to stick with Java 6, especially if we can confirm that between
half to 85% of Android devices can't use Java 7 language features.  A more
aggressive play would be to set a requirement for Java 7.  Setting the
minimum at Java 8 at this time seems overly aggressive at this time though.

https://plumbr.eu/blog/most-popular-java-environments-in-2014

http://pages.zeroturnaround.com/Java-Tools-Technologies.html

http://source.android.com/source/initializing.html

https://developer.android.com/about/dashboards/index.html

http://www.appbrain.com/stats/top-android-sdk-versions


On Wed, Jan 14, 2015 at 11:20 PM, Silviu Burcea <[hidden email]>
wrote:

> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>
> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <[hidden email]>
> wrote:
>
> > Java 8 has only been out for less than a year.  There is still a sizable
> > percentage of groups that have not converted up to Java 8 for myriad
> > reasons.  While I was surprised that we are requiring backwards
> > compatibility with the ten year old Java 5 I think jumping all the way to
> > requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> > minimum required version of Java 7 with the ability to run in Java 8.  I
> > wish I could find metrics to quantify the penetration of each of the
> JDKs,
> > but my gut says Java 7 would a reasonable cutoff.
> >
> > On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
> > wrote:
> >
> > > Raising this issue once again.
> > >>> Are we going to upgrade the requirement for the next major release?
> > >>>
> > >>>  [ ] Java 5
> > >>>  [ ] Java 6
> > >>>  [ ] Java 7
> > >>>  [ ] Java 8
> > >>>  [ ] Java 9
> > >>>
> > >>
> > > Counts up to now:
> > >
> > > Java 7      -> 2
> > > Java 7 or 8 -> 2
> > > Java 8      -> 2
> > >
> > > Any more opionions?
> > >
> > > Gilles
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
>
> --
> - OCPJP7 (90%)
> - OCAJP7 (93%)
> - Java and Big Data Enthusiast
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Evan Ward
In reply to this post by Silviu Burcea
From an API perspective we can design a functional programming API in
Java 7, it will just be more verbose than in Java 8. One unique feature
that Java 8 does bring is multiple inheritance. Now that interfaces can
have method implementations classes can inherit methods from multiple
super classes. At this point I'm not sure how we would use this feature
as API designers, but it is another tool in the tool box.

I think 7 or 8 would be a good choice.

Regards,
Evan

On 01/14/2015 11:20 PM, Silviu Burcea wrote:

> I think Rebel Labs or Plumbr have some metrics about JDK usage.
>
> On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <[hidden email]>
> wrote:
>
>> Java 8 has only been out for less than a year.  There is still a sizable
>> percentage of groups that have not converted up to Java 8 for myriad
>> reasons.  While I was surprised that we are requiring backwards
>> compatibility with the ten year old Java 5 I think jumping all the way to
>> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
>> minimum required version of Java 7 with the ability to run in Java 8.  I
>> wish I could find metrics to quantify the penetration of each of the JDKs,
>> but my gut says Java 7 would a reasonable cutoff.
>>
>> On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
>> wrote:
>>
>>> Raising this issue once again.
>>>>> Are we going to upgrade the requirement for the next major release?
>>>>>
>>>>>  [ ] Java 5
>>>>>  [ ] Java 6
>>>>>  [ ] Java 7
>>>>>  [ ] Java 8
>>>>>  [ ] Java 9
>>>>>
>>> Counts up to now:
>>>
>>> Java 7      -> 2
>>> Java 7 or 8 -> 2
>>> Java 8      -> 2
>>>
>>> Any more opionions?
>>>
>>> Gilles
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Java version

Hank Grabowski
If you are referring to default functions on interfaces, it's not going to
be like multiple inheritance C++ style.  Their rationale is to help for
backwards compatibility with upgraded interfaces that add methods.
Obviously it could be used to intentionally provide default methods from
the very beginning, but since I've never designed an interface with that
construct in mind I'm personally going to tread lightly with that idea.
Thankfully, as far as I know, if two interfaces have a default method with
the same signature then the code won't compile versus just "guessing" which
one you meant.

If the real crux is lambda expressions have we thought about doing
something with either Retrolambda (back porter) or  LambdaJ (Google's
Apache 2.0 licensed pre-Java 8 lambda library)?

On Thu, Jan 15, 2015 at 7:54 AM, Evan Ward <[hidden email]> wrote:

> From an API perspective we can design a functional programming API in
> Java 7, it will just be more verbose than in Java 8. One unique feature
> that Java 8 does bring is multiple inheritance. Now that interfaces can
> have method implementations classes can inherit methods from multiple
> super classes. At this point I'm not sure how we would use this feature
> as API designers, but it is another tool in the tool box.
>
> I think 7 or 8 would be a good choice.
>
> Regards,
> Evan
>
> On 01/14/2015 11:20 PM, Silviu Burcea wrote:
> > I think Rebel Labs or Plumbr have some metrics about JDK usage.
> >
> > On Wed, Jan 14, 2015 at 10:21 PM, Hank Grabowski <
> [hidden email]>
> > wrote:
> >
> >> Java 8 has only been out for less than a year.  There is still a sizable
> >> percentage of groups that have not converted up to Java 8 for myriad
> >> reasons.  While I was surprised that we are requiring backwards
> >> compatibility with the ten year old Java 5 I think jumping all the way
> to
> >> requiring Java 8 may be a bit too much of a stretch.  I would vote for a
> >> minimum required version of Java 7 with the ability to run in Java 8.  I
> >> wish I could find metrics to quantify the penetration of each of the
> JDKs,
> >> but my gut says Java 7 would a reasonable cutoff.
> >>
> >> On Tue, Jan 13, 2015 at 8:31 PM, Gilles <[hidden email]>
> >> wrote:
> >>
> >>> Raising this issue once again.
> >>>>> Are we going to upgrade the requirement for the next major release?
> >>>>>
> >>>>>  [ ] Java 5
> >>>>>  [ ] Java 6
> >>>>>  [ ] Java 7
> >>>>>  [ ] Java 8
> >>>>>  [ ] Java 9
> >>>>>
> >>> Counts up to now:
> >>>
> >>> Java 7      -> 2
> >>> Java 7 or 8 -> 2
> >>> Java 8      -> 2
> >>>
> >>> Any more opionions?
> >>>
> >>> Gilles
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
123