JDK-8025705

Tue Apr 22 13:10:37 UTC 2014

Hi David,

Most of the problem resides in jdk/make, in the following files:
make/CompileDemos.gmk
make/CompileJavaClasses.gmk
make/CopyFiles.gmk
make/CopyIntoClasses.gmk
make/CreateSecurityJars.gmk
make/gensrc/GensrcIcons.gmk
make/Images.gmk
make/lib/Awt2dLibraries.gmk

Biggest offender is problem CopyFiles.gmk (but CreateSecurityJars.gmk has a
bit too).  Basically in each situation where there's a "ifndef OPENJDK", it
encloses a block of code that access something in src/closed or make/closed.

I did initially try to set a new variable in our build in an attempt to
replace these areas with something like:
ifndef OPENJDK && ifndef PRIVATEJDK

... but there's apparently no convenient way of doing that in makefiles
(conjunctions and disjunctions at the preprocessing level aren't available
-- and the workarounds are rather goofy).  Duplicating the OPENJDK only
code quickly became unreasonable too -- a few of the code blocks are
one-liners, but there's a bunch that are much more involved clauses.

On Tue, Apr 22, 2014 at 8:23 AM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Keith,
>
> Sorry I have very limited cycles right now, and just had a 4 day Easter
> break with anther long weekend ahead :)
>
> You are right that the src/closed -> CUSTOM_SRC_DIR is somewhat tangential
> to your issue.
>
> The existence checks I suggested would be a check for whatever
> file/directory is enough to indicate the "feature" is present.
>
> Most uses of OPENJDK are really used to indicate !ORACLE_JDK, so
> introducing a third variation doesn't really fit.
>
> Can you give a concrete example of something that highlights this problem
> for you and how your proposal addresses it? I may get a better sense of
> things with specifics rather than trying to generalize - because I don't
> see a general solution without a lot of refactoring.
>
> Thanks,
> David
>
>
> On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>> Hi Mark, et al.,
>>
>> The sad reality of the situation is that there is indeed Oracle-specific
>> code in the OpenJDK makefiles, and this code interferes with our
>> customization of the JDK.  Adding temporary signposts to allow us (and
>> others) to avoid this code will not make things worse.  It doesn't have
>> to be a distribution name -- we call it whatever you like:
>> TO_BE_REMOVED, KEITH_IS_A_PITA, whatever -- just something to latch onto
>> to deactivate that code when it is not needed.  This would provide
>> immediate relief to customizing distributors and give Oracle engineers
>> time to phase that code into closed makefiles (at which time the
>> signposts can be removed completely).
>>
>> Taking all this code out wholesale instead would be great, and this is
>> something I am totally willing to tackle and put the effort in on if I
>> was in a position to do so.  Unfortunately, since this is not fully
>> open-source, I can't do the refactoring needed to move this code into
>> the closed directories.  And I though I could easily strip the code from
>> OpenJDK, this would totally muck with Oracle distribution so any patch I
>> would submit would surely be immediately rejected.
>>
>> Considering that the code is question has been in OpenJDK for about 8
>> years now, I think it's safe to assume that it's not a high priority
>> item for Oracle engineers to get this fixed.  Which is totally fine, IMO
>> -- it's very much a tenant of open source development that he who has
>> the itch ought to be the one to scratch it, and different entities are
>> expected to have different sets of priorities.  No doubt I'm probably
>> the first one to complain about this :)
>>
>> Unfortunately, I'm also in the unfortunate position of having an itch
>> (and willing fingernails), but an inability to scratch it.
>>
>> So, where do we go from here and how can I help in this effort?  I
>> really do want to help, as this is an immediate problem for me and I
>> can't afford to wait years for it to get fixed.  I still think that
>> signposts are a very reasonable compromise given that:
>> (1) It is something that can be done independently and doesn't require
>> Oracle engineering resources (other than reviews and shepherding)
>> (2) It does not interfere with efforts to move closed code out of
>> OpenJDK makefiles
>> (3) it can be done quickly
>> (4) It does not avoid the Makefile-checking for existence of required
>> files/directories (which reduces build-brittleness)
>>
>> Mark/Dave, if I can't convince you that we should take this path, can
>> you please suggest an alternative design?  I'm not picky -- if we can
>> come up with something else that works then let's do it and I'll start
>> on it right away.
>>
>> --
>> - Keith (itchy)
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 8:23 PM, <mark.reinhold at oracle.com
>> <mailto:mark.reinhold at oracle.com>> wrote:
>>
>>     2014/4/16 14:52 -0700, david.holmes at oracle.com
>>     <mailto:david.holmes at oracle.com>:
>>
>>      > src/closed is Oracle's "custom source" location (hotspot calls it
>>      > alt_src). If we never saw src/closed in the makefiles, only
>>      > CUSTOM_SRC_DIR, and guarded with an existence test for a specific
>>      > directory/file, then that should address your problem. That would
>>     be a
>>      > first step in moving things to the custom makefiles where they
>>     belong.
>>      >
>>      > I'm opposed to the ORACLEJDK variable because I want to maintain
>> the
>>      > pressure to get this fixed properly. If we hack around it then it
>>     will
>>      > never get cleaned up.
>>
>>     I think it's wrong, in principle, for OpenJDK source code to contain
>>     identifiers naming specific vendors of JDK implementations.  We're not
>>     quite there at the moment, but let's please not add any more.
>>
>>     - Mark
>>
>>
>>