Looking ahead: proposed Hg forest consolidation for JDK 10

[Erik Helin]

On 2016-10-19, Maurizio Cimadamore wrote:
> 
> 
> On 19/10/16 01:22, Jonathan Gibbons wrote:
> >
> >
> >On 10/18/2016 06:59 AM, Erik Helin wrote:
> >>>
> >>
> >>You mean that you can work on the langtools repository only? Do you only
> >>need a boot JDK? How do you build in those cases? I assumed that
> >>langtools, like all the other repositories, were building from the top
> >>repository?
> >
> >Currently, with the langtools repo, you only need the repo and a
> >reasonably-recent build of JDK.  The langtools repo has its own Ant script
> >to build the langtools modules, which is easy enough since it's all Java
> >code. The Ant script is set up to support IDE integration and debugging:
> >some of us use NetBeans, others use IntelliJ. The --patch-path option is
> >used to override the langtools modules in the JDK image with the new
> >locally built versions.
> >
> >The technique should be reasonably applicable to anyone just working on
> >plain old Java code.
> Pretty much what Jon said - you can work in langtools in isolation, provided
> you have a pointer to a reasonably recent JDK 9 image (the degree of
> freshness of such JDK image depends on how much work is going on - if things
> are stable, 'recent' could well mean 3-4 months old; if things are hot - as
> now - 'recent' typically means a couple of weeks).

And you will be able to work in langtools in isolation (or rather the
langtools modules in isolation). The only difference is that you know
will get the entire source tree, you can't just get the langtools
directory. However, you can still change directory to the module you are
working on and use your ant build files in combination with a reasonably
recent build of JDK. Again, the only difference is the number of files
of the initial clone (or local clone, or share).

Thanks,
Erik

> Yesterday I did some experiments to compare build times of the local
> langtools script vs. toplevel make; the table below summarizes the results.
> I've compared both 'cold  build' times (i.e. build from a clean state) and
> 'incremental build' times. I did the latter by touching a file in a given
> module, and then relaunching the build command again.
> 
> 
> *Test type*
> 	*Time (make)*
> 	*Time (ant)*
> all 5 langtools modules (cold build)
> 	4m
> 	18s
> java.compiler (incremental)
> 	28s
> 	3s
> jdk.compiler (incremental)
> 	25s
> 	3s
> jdk.javadoc (incremental)
> 	12s
> 	2s
> jdk.jdeps (incremental)
> 	7s
> 	2s
> jdk.jshell (incremental)
> 	5s
> 	2s
> 
> 
> 
> As you can see, the different in the cold case is pretty stark. Now, you
> should normally not pay the price for this always - however, any change that
> triggers a 'reconfigure' can potentially spawn a cold build time.
> 
> If we move on to consider incremental build times, we can see two
> categories:
> 
> * java.compiler, jdk.compiler, jdk.javadoc - those tools have an 'interim'
> stage in the toplevel make build - which make incremental compilation quite
> slower compared to ant
> * jdk.jdeps and jdk.jshell are simple leaves - while the ant build is
> faster, I think the difference is not significant
> 
> I tend to work on jdk.compiler most of the time, and, for me, the difference
> in usability between a 30s incremental build and a 3s one is pretty
> significant, especially when working with an IDE. Which is why, at the
> moment at least, I'm sticking with the internal ant build.
> 
> Of course, should things improve for the modules in the first category, then
> the extra benefits of using a single build would be enough to offset the
> minor incremental slow down (and the one off 'cold' big slow down).
> 
> P.S.
> I've seen other ant builds around (Nashorn IIRC) - I'd be interested to know
> what other folks in similar situation think about this.
> 
> Maurizio
>