Hi Stuart,
> I would like people to review the README change as well. Thanks.
I don't think we should simply say
"Do not use a build of JDK 8 as the boot JDK for building JDK 8."
as that doesn't explain what the issue is. If I'm building the JDK for
my own use I can use JDK8. So how about:
"JDK 8 developers should not use JDK 8 as the boot JDK, to ensure that
code changes are compatible with building using JDK 7."
?
David
On 18/06/2013 5:42 PM, Stuart Marks wrote:
Hi folks,
Looks like I generated a bit of discussion here. Let's try to tease
apart some of the issues.
1) I think we need a better articulation of the rule about the boot JDK
being N-1, thus my proposed change to the README. I don't mean to ever
prohibit anybody from ever trying to build JDK N with a boot JDK N, but
that should be a special case. If the wording I proposed isn't
satisfactory, please suggest alternatives.
2) Boot cycle build. Yes, after building JDK N, we must support a boot
cycle build where the just-built JDK N is used as the boot JDK to build
itself again. This is really a special case within the build system,
however. At configure time, the boot JDK always should be N-1, and when
the build gets to the boot cycle phase, it either knows or can be taught
to treat this phase differently from the first phase.
3) Rules enforcement / mistake avoidance. I think it makes the most
sense for configure to ensure that the configured boot JDK is N-1.
(Naturally the configured boot JDK will be overridden during the boot
cycle phase. It could also be overridden by specifying an additional
option explicitly.) The main point here is to avoid mistakes, so that
someone who happens to have a JDK 8 in their path doesn't accidentally
have it picked up by configure.
Unfortunately the -source 7 -target 7 approach is insufficient, because
while it rolls back the language level and classfile version, it does
*not* roll back the API version. To get the old API version, one has to
construct a bootclasspath with the old class libraries, and at that
point one might as well just use the N-1 JDK.
#include <lecture_from_joe_darcy_with_link_to_his_blogpost_on_this_topic>
4) Could jaxp, jaxws, and corba be built with the current JDK, not the
boot JDK? Sure, probably. I spoke with Jon G on this topic the other day
and we didn't come up with any really good reasons why they need to be
built with the boot JDK. Historically they were upstream repositories so
they were usually based on a backrev JDK anyway, so there was no real
need for them to use the latest features. Also, using the boot JDK was
probably an incidental outcome of the way the old build system was put
together. (Old-timers lurking -- or not :-) -- on this list will
certainly know better than me.) The new build system does the same,
since one of its requirements is that it slavishly match the output of
the old build system.
In principle I don't see any reason why these libraries couldn't be
built with the current JDK instead of the boot JDK. This might be a
fairly large restructuring of the build system, though.
Of course, langtools still needs to be built with the JDK N-1 boot JDK.
I'm not sure about the Java files in hotspot. Can someone enlighten us?
--
If people think it's a good idea I could file RFEs for #3 and #4.
I would like people to review the README change as well. Thanks.
s'marks
On 6/17/13 11:57 PM, 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.
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
