Switching to java 1.8 ==> +1 from my side But please use a major version increase, to clearly communicate that change.
Besides the already mentioned arguments from the core developers, are their any numbers on the user base available? I mean: select 'java.version' from 'maven_users', where day(last_usage) > 20150101 Does such exists? Or maybe the core developers may raise a poll on Twitter, to get some feedback ;) What do you think? Regards Martin PS: My background: I'm Maven user since a handful years now and just did one pull request #71 2015-11-30 23:19 GMT+01:00 Tibor Digana <[email protected]>: > As I spoke with Andreas and Kristian about my ideas now I am going to > forward this email to Maven mailinglist. > I can see the opportunity of Java 8 but I don't say that all artifacts must > be necessarily compiled with Java8. I can imaging few of them which make > sense. > This is the email and you can tell us what you think of it. Maybe it's > crazy. > > After i made a post [1] in JUnit on GitHub I found that it might be useful > in Maven. > Usually JUnit committers are very reserved to new features if you push them > somewhere they don't want to be. :-) > > So there are two things how we can utilize Java 8 in Surefire extensions. > > The first is simple abstraction of Runners independent of JUnit and TestNG > and easily customized by the user. > > Second is the same Runner abstraction used with CLI console. > --- > [1] https://github.com/junit-team/junit/issues/1078#issuecomment-158706736 > > 1. > You should see [1]. JUnitTest is an interface and has default methods. The > test(string, function) methods needs to be called in users code. These > methods only register function -> test name. > The function is real test name. Since JUnitTest is interface it can be > implemented in extension. The Surefire Provider will only create a Proxy > around it and around test() methods and simply only report to > SurefireListener. > That's all, simple. All features like parameterized producer, categories, > filters, rules are up to AOP in SPI. Due to Java Proxy the AOP is possible. > > 2. With Nashorn console embedded in our CLI you can just halt the build in > test phase and run tests and tune them as you like: > > >> surefire.run(MyTest.class) > ... > >> surefire.exit() > > You can just change the test or main code, recompile in IDEA and you do not > need to trigger the buid again because you are still in the JavaScript > console. > > So run the TDD round again: > > >> surefire.run(MyTest.class) > > WDYT ? > > > Cheers > Tibor > > > > On Mon, Nov 30, 2015 at 10:18 PM, Stephen Connolly < > [email protected]> wrote: > > > Picking up from > > > > > http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E > > (and my follow up to that but archive.apache.org is being a tad slow) > > > > Here is our policy: > > > > The development line of Maven core should require a minimum JRE version > > > that is no older than 18 months after the end of Oracle's public > updates > > > for that JRE version at the time that the first version of the > > development > > > line was released, but may require a higher minimum JRE version if > other > > > requirements dictate a higher JRE version > > > > > > (Source: > > https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy) > > > > OK, so it's a draft policy... but we've all been silent on the draft, so > > lazy consensus! > > > > Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html > they > > state: > > > > after April 2015, Oracle will not post further updates of Java SE 7 to > its > > > public download sites > > > > > > So per our (draft) version number policy, we can keep Java 7 as the > > baseline :-( or we can choose to upgrade code to Java 8 (because we want > to > > use lambdas... there's a requirement) > > > > > > So assuming we bump the master branch of Maven core to 3.4.0, what Java > > version do we want to use as the baseline? > > > > There are thankfully only two options: > > > > Java 7 > > + Not actually changing things > > + May make it easier to drive adoption > > - Still can't use newer language features in core > > - Java 7 is EOL and it may get harder for developers to source JDKs to > > test and develop against > > > > Java 8 > > + We're not as old hat any more > > + We can use lambdas > > + We can use Nashorn (may make integrating with Node easier... > certainly > > could make integrating with JavaScript tooling easier) > > + EOL for Java 8 is at least Sep 2017 (and may be later) > > - May be harder to drive adoption in shops that have issues upgrading > > Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway > > unless there are features dragging their change controlled heels over the > > line) > > > > So... > > > > Let's have a heated debate! > > > > -Stephen > > > > P.S. > > > > I'm waiting for Chris to chime in about how IBM is still supporting > Java > > 1.3 or something like that ;-) > > > > > > -- > Cheers > Tibor >
