JDK-8025705

[Erik Joelsson]

I've been following this discussion for a while now and more and more I 
agree with Keith. The current situation where "ifndef OPENJDK" 
essentially means OracleJDK really is broken. This is something I and 
Magnus have noted several times but not yet had time to fokus on fixing. 
Mostly becuase there hasn't been any urgent need for it (no external 
party has expressed enough interest in utilizing the features we have 
for including extra source), until now.

Yes, it's bad if we "pollute" OpenJDK makefiles with references to 
Oracle, but the damage really is already done since we already have all 
this Oracle specific stuff in them, just hidden under a "not-open" 
label. I think we should indeed make it explicit rather than pretending 
it's not there.

I can confirm to anyone that isn't intimately familiar with the 
makefiles that the difference in maintenance for an external party would 
potentially be much less if we made the suggested changes.

On 2014-04-25 00:10, Keith McGuigan wrote:
> Hi Mark,
>
> Well first off, the existence of src/closed triggers OPENJDK to be unset,
> so even having such directories (or subrepos) present turns on all the
> logic that looks for files in src/closed which probably don't exist in a
> non-Oracle distribution.  So having an ORACLEJDK test instead around that
> code means we can control it with a single switch somewhere in a top-level
> Makefile (maybe even a makefile in make/closed). This would let us use the
> src/closed mechanism and at the same time unset ORACLEJDK (OPENJDK would
> also be unset).
>
> If we need to have a private modification to futz with ORACLEJDK (to turn
> it off), that's not so bad -- it'd be just in one place so maintenance
> would be easier.  But it's possible that we can put this logic in a
> make/closed file that gets conditionally included, in which case we
> wouldn't even have to worry about that.
>
> As to how to get custom code compiled, I think we have a couple options to
> try.  In hotspot the code is just magically picked up and treated as if it
> were sitting in the non-closed directory, augmenting or overriding the open
> sources (depending on the filename).  If we could do something like that in
> the jdk makefiles, that would be ideal (IMO).  But it may not be feasible
> to do this -- I'd have to investigate.  Another, probably more realistic
> alternative is to add a couple generic hooks (as few as possible) in the
> open source to make/closed makefiles which may or may not exist depending
> on which distribution you are building.  Something like:
> -include make/closed/custom.gmk
> somewhere in a top-level Makefile which would include custom makefile if it
> exists, and silently skip over it if it is not there.  It would be up to
> the customizer to provide that file and have it include whatever is needed
> in order to build the custom code.  For example, I could put "ORACLEJDK="
> in there perhaps to turn off the Oracle extensions in the Makefile, as well
> as adding whatever other logic I need.  Oracle's version of
> make/closed/custom.gmk maybe just sets "ORACLEJDK=true" and that's it (for
> now, once the artifacts are removed from the Makefiles you wouldn't need
> ORACLEJDK at all).
We have some of those hooks in JDK makefiles already. In jdk8 we just 
had "-include" but in jdk9 we made it a bit more fancy with a macro that 
the closed implementor has to provide an implementation for (to give 
more freedome on the closed directory layout). It's not uniformly added 
everywhere yet but the pattern is established and if an open makefile is 
missing "$(eval $(call IncludeCustomExtension, , Main.gmk))", feel free 
to add it.

There is also some support for adding extra source directories. See 
ADD_SRC macro in spec.gmk.in and JavaCompilation.gmk. This is currently 
not used and might need some tweaking, but would be nice to see expanded 
upon.

/Erik
> My vision of this is that I'd like to get to the point where OpenJDK
> makefiles work fine as is, but will automatically pick up new logic and new
> code from make/closed and src/closed if those directories exist (and
> contain the "hook" files).  This gives custom code a nice place on the side
> where to live, with fewer worries about having to merge whenever anything
> in OpenJDK changes.  Of course it wouldn't solve all the problems, but it
> would be a very nice start.

>
> On Thu, Apr 24, 2014 at 12:43 PM, <mark.reinhold at oracle.com> wrote:
>
>> 2014/4/22 21:23 -0700, kmcguigan at twitter.com:
>>> Yes, I did consider using some ifeq tricks like that -- but they are
>> rather
>>> ugly and unreadable and have the same problem that you want to avoid:
>>> adding distribution-specific code into the open-source makefiles.
>>>
>>> My goal here is to have the public OpenJDK makefiles be in a state such
>>> that custom distribution code can be added (in make/closed, src/closed,
>> or
>>> some such alternative location) without having to perform surgery on the
>>> Makefiles and maintain the private changes.  The mechanism is already in
>>> place,it's just some leftover OracleJDK that hasn't made it out of the
>> open
>>> makefiles yet.  If we could just cordon that off somehow, then anyone
>> could
>>> make a custom distribution by augmenting OpenJDK with 'closed' style
>>> repositories -- without having to maintain private, unrelated edits to
>> jdk
>>> Makefiles.
>> I'm confused.
>>
>> Even if we replace `ifndef OPENJDK` with `ifdef ORACLEJDK`, how does
>> this help you?  In those cases where you want an open Makefile to refer
>> to code in Twitter's internal src/closed directory aren't you still
>> going to have to create and maintain your own patches to the open
>> Makefile?
>>
>> Just trying to understand the problem here ...
>>
>> - Mark
>>
>
>