Hi Erik,
On 18/06/2013 6:06 PM, Erik Joelsson wrote:
On 2013-06-18 08:57, Daniel Fuchs wrote:
On 6/18/13 8:28 AM, David Holmes wrote:
On 18/06/2013 4:02 PM, Jonathan Gibbons wrote:
The only problem with using N is that you don't know whether you have
broken building with N-1. Therefore the general recommendation for most
people should be to always use N-1. I think Stuart is just searching
for ways to make people aware that using N-1 is "the right thing to
do".
There was certainly an issue here that caused a problem because the
code used a JDK8 API that was not available when the source was
compiled with JDK7. And sure compiling with 7u boot JDK would have
caught that.
But we have lots of code that only compiles with JDK8 and that is the
way we want it, else JDK8 could not take advantage of any new
language features or APIs in JDK8. The real problem here was that the
code in question is code that is not built in a way that allows it to
use the latest language features or APIs. In which case perhaps the
real fix is to use build commands that enforce this restriction ie by
using -source 7 -target 7 ?
David
Hi David,
In the case of Jaxp - I'm not sure why exactly is Jaxp compiled with
the boot JDK.
It comes early in the build cycle - at a time when the N JDK hasn't
been compiled yet.
But is this a mere convenience - or is there a good technical reason
for this?
Because personally - I would love to be able to use JDK N feature in
the JAXP source
code.
One could argue that using N features impairs the ability to port the
fixes to N-1, but
this is already the case today anyway: for many of the fixes I ported
from 8 to 7 I had to
modify my patches because I was using N-1 features in N, and therefore
had to convert
the code to only use N-2 features when porting from N to N-1.
So if that is possible (and it may not be - I'm not a build expert) -
I would argue to
remove the restriction for Jaxp - rather than enforce it.
After langtools has been built (which is first), the rest, including
jaxp, is compiled using the bootstrap javac, which is a special version
of the newly built javac that runs on the boot jdk but acts as the JDK N
javac. This means JDK N language features are available, but not library
features, since there is no access to the rest of the JDK N classes.
Thanks for clarifying that. So to use new APIs you either have to be
part of the build that constructs that API, or else your component has
to be built after the new classes destined for rt.jar are available?
But anyway this is getting a little off-track :)
David
------
This separation is just convenience as far as I can tell. It's
technically possible to work around, but the gains will have to be
weighed against the added complexity. Easiest solution would be to get
rid of the separate jaxp repository and just put the source back with
the jdk.
/Erik
best regards,
-- daniel
-- Jon
On 06/17/2013 10:04 PM, David Holmes wrote:
I thought the only rule was "must be buildable by N-1", not that you
must not try to use N!
Can the problem preventing a build using JDK8 as the boot JDK not be
corrected? I'm assuming it is one of the more unusual parts of the
build where we mess with bootclasspath etc?
David
On 18/06/2013 10:21 AM, Stuart Marks wrote:
On 6/17/13 4:02 PM, Kelly O'Hair wrote:
Rule #1 Nobody reads the README
Rule #2 When things go wrong, blame the README
I of course have no objection to the change, however, I'm not
convinced it will
help much the next time someone runs into this. :^(
Hi Kelly! You still read this stuff here? :-)
Yeah, I have no illusions that changing the README will prevent
many, if
any, future occurrences of this problem. However, we had an internal
discussion on this incident where the N-1 rule was asserted. There
was
no dispute about the rule, but I went off to find where it was
documented, and found only the fairly weak statement in the
README. So,
at the very least, that ought to be fixed.
A stronger step would be to modify configure to check the version
of the
boot JDK and to complain if it doesn't match N-1. Or perhaps even N-1
and update >= 7. What do you think? I was considering filing an RFE.
A restriction in configure would probably be more effective at
preventing these kinds of errors.
s'marks
