Not sure what java.lang.invoke utility methods you are having in mind, to
me it looks complex enough that getting such an API right is not straight
forward and could be better developed outside Lang.
Let's do what Gary proposes and an orderly upgrade - our Java 7
intermediary will mainly be syntac
How about utility methods for java.lang.invoke? There were also some
additions to java.util.concurrent that can be supported in
lang3.concurrent. I'm sure I'm missing other APIs added to JDK 7, but
there's a couple ideas.
On 22 September 2016 at 16:27, Gary Gregory wrote:
> On Thu, Sep 22, 2016
On Thu, Sep 22, 2016 at 2:17 PM, Emmanuel Bourg wrote:
> Le 22/09/2016 à 22:58, Gary Gregory a écrit :
>
> > - What else?
>
> I think the real question here is what kind of benefit Java 7 can bring
> to the Commons Lang API. Internal clean-up using the new syntax tricks
> isn't really interesting
Le 22/09/2016 à 22:58, Gary Gregory a écrit :
> - What else?
I think the real question here is what kind of benefit Java 7 can bring
to the Commons Lang API. Internal clean-up using the new syntax tricks
isn't really interesting. The benefits of Java 8 are more obvious.
Emmanuel Bourg
On Thu, Sep 22, 2016 at 1:21 PM, Oliver Heger
wrote:
>
>
> Am 21.09.2016 um 20:20 schrieb Gary Gregory:
> > I'd like to propose an orderly migration assume BC is preserved:
> >
> > - Release 3.5 RC as scheduled this weekend
> > - Release 3.6 with Java 7 changes
> > - Release 3.7 with Java 8 chang
Am 21.09.2016 um 20:20 schrieb Gary Gregory:
> I'd like to propose an orderly migration assume BC is preserved:
>
> - Release 3.5 RC as scheduled this weekend
> - Release 3.6 with Java 7 changes
> - Release 3.7 with Java 8 changes
>
> This will give us an opportunity to do some Java 7 work and
I do not think we should talk about future plans in the release notes for
3.5.
Gary
On Sep 21, 2016 2:58 PM, "Stian Soiland-Reyes" wrote:
> +1 - could we even mention this in the release notes for 3.5 and 3.6?
>
> Something like:
>
> > Commons Lang 3.5.x is planned to be the last minor version
+1 - could we even mention this in the release notes for 3.5 and 3.6?
Something like:
> Commons Lang 3.5.x is planned to be the last minor version series that
> support Java 6; future versions will target Java 7 and Java 8.
> Commons Lang 3.6.x is planned to be the last minor version series tha
I'd like to propose an orderly migration assume BC is preserved:
- Release 3.5 RC as scheduled this weekend
- Release 3.6 with Java 7 changes
- Release 3.7 with Java 8 changes
This will give us an opportunity to do some Java 7 work and put that out
without leaving Java 7-only folks out of the pic
+1 to be brave and make Lang 3.6 be Java 8, so Lambda helpers can join
here. I have a couple of Stream helpers that could also fit in there.
On 21 September 2016 at 18:19, Gary Gregory wrote:
> On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter wrote:
>
>> Hi,
>>
>> Jörg Schaible schrieb am Mi.
On Wed, Sep 21, 2016 at 8:04 AM, Benedikt Ritter wrote:
> Hi,
>
> Jörg Schaible schrieb am Mi., 21. Sep.
> 2016 um 16:55 Uhr:
>
> > Jan Matèrne (jhm) wrote:
> >
> > >
> > >> We could also have Lamda utility classes in [lang], the classes would
> > >> target Java 8 while the other classes would r
On Wed, 21 Sep 2016 15:04:12 +, Benedikt Ritter wrote:
Hi,
Jörg Schaible schrieb am Mi., 21.
Sep.
2016 um 16:55 Uhr:
Jan Matèrne (jhm) wrote:
>
>> We could also have Lamda utility classes in [lang], the classes
would
>> target Java 8 while the other classes would remain at the Java 6
Le 21/09/2016 à 15:17, Jan Matèrne (jhm) a écrit :
> I thought about creating a PR for supplying helper methods for Java8
> lambdas.
Out of curiosity, what kind of methods do you have in mind?
Emmanuel Bourg
-
To unsubscribe, e
Hi,
Jörg Schaible schrieb am Mi., 21. Sep.
2016 um 16:55 Uhr:
> Jan Matèrne (jhm) wrote:
>
> >
> >> We could also have Lamda utility classes in [lang], the classes would
> >> target Java 8 while the other classes would remain at the Java 6 level
> >> (this implies compiling the classes separatel
Jan Matèrne (jhm) wrote:
>
>> We could also have Lamda utility classes in [lang], the classes would
>> target Java 8 while the other classes would remain at the Java 6 level
>> (this implies compiling the classes separately and recombining them in
>> the final jar).
>
> From a users point of vi
> We could also have Lamda utility classes in [lang], the classes would
> target Java 8 while the other classes would remain at the Java 6 level
> (this implies compiling the classes separately and recombining them in
> the final jar).
>From a users point of view I would search in commons-lang f
Le 21/09/2016 à 15:24, Bruno P. Kinoshita a écrit :
> Thoughts?
We could also have Lamda utility classes in [lang], the classes would
target Java 8 while the other classes would remain at the Java 6 level
(this implies compiling the classes separately and recombining them in
the final jar).
Emma
___
> > From: Jan Matèrne (jhm)
> >To: 'Commons Developers List'
> >Sent: Thursday, 22 September 2016 1:17 AM
> >Subject: Java8 utilities
> >
> >
> >I thought about creating a PR for supplying helper methods for Java8
> >lam
think we could focus only in
adding interesting FP utilities, not provided in the language itself.
Thoughts?
Bruno
>
> From: Jan Matèrne (jhm)
>To: 'Commons Developers List'
>Sent: Thursday, 22 September 2016 1:17 AM
>Subject: Java8 u
I thought about creating a PR for supplying helper methods for Java8
lambdas.
My intented target was commons-lang, but this is Java6.
Where could I propose the helpers?`
Jan
20 matches
Mail list logo
