We could simply take a vote on this - case like this is exactly what the voting procedures at Apache were originally designed for. We'd need to vote on a clearly defined issue, like "do we want to require Java 6 for T5.4 so we can upgrade dependencies that require Java 6, such as the newer closure compiler".
Kalle On Tue, May 13, 2014 at 8:31 AM, Jochen Kemnade <[email protected]>wrote: > Any new insights on this one? The current master will still FTBFS on Java > 5. > > Am 02.05.2014 18:18, schrieb Kalle Korhonen: > > On Fri, May 2, 2014 at 12:57 AM, Ulrich Stärk <[email protected]> wrote: >> >> I don't see the benefits in this. As I said earlier, Java 6 and 7 IMO >>> don't provide enough benefits >>> to justify the change. >>> >>> >> A newer Java version is required if we want to update the closure >> compiler. >> >> Kalle >> >> >> On 2014-05-01 19:01, Kalle Korhonen wrote: >> >>> I agree with Rob. A common sense approach would be to require 1.6 for >>>> >>> T5.4 >>> >>>> and then require 1.8 in a future version. >>>> >>>> Kalle >>>> >>>> >>>> On Thu, May 1, 2014 at 9:54 AM, Robert Zeigler >>>> <[email protected]>wrote: >>>> >>>> Not opposed to an upgrade to Java 8, but not sure 5.4 is the right time >>>>> for it. 5.4 has been long-enough in coming that I feel it would be >>>>> >>>> better >>> >>>> to release 5.4, and use 5.5 as the java8 upgrade, possibly with a fairly >>>>> short release time between 5.4 and 5.5. Basically, 5.5 could be “5.4 >>>>> >>>> with >>> >>>> java 8 compatibility” (and whatever new features (like the httpOnly >>>>> >>>> cookie >>> >>>> flag ticket you commented on recently) that would need > java 1.5 to >>>>> support). >>>>> >>>>> Robert >>>>> >>>>> On May 1, 2014, at 5/111:38 AM , Ulrich Stärk <[email protected]> >>>>> wrote: >>>>> >>>>> Historically I have been a strong opponent to Java version upgrades >>>>>> for >>>>>> >>>>> Tapestry because IMO the >>>>> >>>>>> disadvantages outweighed the advantages by far. >>>>>> >>>>>> Now that we have lambda expressions, default methods, Nashorn and many >>>>>> >>>>> other useful features I'm >>>>> >>>>>> leaning towards making a radical break and switch to Java 8. >>>>>> >>>>>> We should have a formal vote for such a radical change and a >>>>>> discussion >>>>>> >>>>> firstin order to gather >>>>> >>>>>> comments and opinions from the community. >>>>>> >>>>>> Uli >>>>>> >>>>>> On 2014-04-30 12:57, Jochen Kemnade wrote: >>>>>> >>>>>>> Am 29.04.2014 21:07, schrieb Jochen Kemnade: >>>>>>> >>>>>>>> I'll downgrade it tomorrow and get myself a Java 1.5 compiler... >>>>>>>> >>>>>>> >>>>>>> Which is much harder than I thought it was. I managed to find old >>>>>>> >>>>>> rt.jar and jce.jar files and to >>>>> >>>>>> make Gradle use them. >>>>>>> Now I'm getting compile errors, e.g. in VirtualResource:88, >>>>>>> >>>>>> MacOutputStream:45 and others. Mostly, >>>>> >>>>>> it's Java 6 methods being used. >>>>>>> First of all, do we still want to stick with Java 5 now that Java 8 >>>>>>> is >>>>>>> >>>>>> out and even Java 6 is EOL? >>>>> >>>>>> Second, I wonder why it builds in Jenkins. What JDK is used there? >>>>>>> >>>>>>> Jochen >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> --------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
