Can we use -source 1.8 for 8u60?

[Andrew Hughes]

----- Original Message -----
> Generally, the rule is that most of the code base for any JDK N
> is that it can use -source N.
> 
> The primary exception is the code for javac, which is constrained
> to use -source N-1 and the API for JDK N-1.  This constraint allows
> us to build a version of javac which can be used to build the rest
> of JDK.
> 

Yeah, the first stage of the build is to bootstrap the compiler, which
then allows the rest of the build to use JDK N code. I seem to remember
javac in 7 even had to use some stubs to get around the use of new
JDK code that the bootstrap compiler may not be able to build.

You'll find diamond operators, multi-catch blocks, try-resources blocks
and String-based switch statements throughout the 7 codebase (which
require source 7) and @Override on interfaces pop up in the 6 codebase
(which require source 6 officially). I'd prefer we didn't do this
personally, but the ship has long since sailed.

> -- Jon
> 
> On 02/20/2015 07:07 AM, Stanislav Baiduzhyi wrote:
> > On Friday 20 February 2015 15:57:33 Mario Torre wrote:
> >> Wouldn't that make it impossible to build with a jdk7?
> > Lambda expressions are already used in jdk8 MetalLookAndFeel:
> >
> > $ grep -e '->'
> > jdk/src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java
> >          LazyValue dialogBorder = t -> new MetalBorders.DialogBorder();
> >          LazyValue questionDialogBorder = t -> new
> > MetalBorders.QuestionDialogBorder();
> >              "ToolBar.rolloverBorder", (LazyValue) t ->
> > MetalBorders.getToolBarRolloverBorder(),
> >              "ToolBar.nonrolloverBorder", (LazyValue) t ->
> > MetalBorders.getToolBarNonrolloverBorder(),
> >              "RootPane.frameBorder", (LazyValue) t -> new
> > MetalBorders.FrameBorder(),
> >              "RootPane.errorDialogBorder", (LazyValue) t -> new
> > MetalBorders.ErrorDialogBorder(),
> >              "RootPane.warningDialogBorder", (LazyValue) t -> new
> > MetalBorders.WarningDialogBorder(),
> >
> > So I would assume that to use or not to use Java 8 source constructs
> > depends
> > on where exactly you want to use them.
> >
> >
> >> 2015-02-20 15:50 GMT+01:00 Attila Szegedi <attila.szegedi at oracle.com>:
> >>> Quick question: are we allowed to use Java 8 source constructs for code
> >>> going into 8u-dev for 8u60? I'd need to evolve an interface in Nashorn by
> >>> adding a method to it and would like to provide a default implementation
> >>> for it.
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07