Sorry I should have explained more what I meant. For example, we
don't have to replace some public API methods so that they use
lambdas. We keep the APIs as is but internally we can use lambdas
(private methods, internal packages, etc). Same for the Java 8 Date
& Time. I didn't mean that we should necessarily take advantage
of the default methods to prevent API breakage.
Marc-André
On 2015-02-09 01:00 PM, Marc Dumais
wrote:
On 2015-02-09 10:09 AM, Marc
Khouzam wrote:
As for Java 8, does making the
switch require API breakage? If we modify existing code to
take advantage of java 8's nice features, yes, that could
break API, but do we have enough time to make all the
changes we'd want to? Or will we want to continue those
changes for the next major release after Mars (requiring a
10.0 version)?
I think it would be worth switching to Java 8 without breaking
the API. We wouldn't be able to Java8-ify the APIs but there is
a lot that can be done internally. Also, the "End of Public
Updates" for Java 7 is April 2015.
http://www.oracle.com/technetwork/java/eol-135779.html
Marc-André
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|