JDK-8025705

[Keith McGuigan]

On Wed, Apr 16, 2014 at 9:15 PM, David Holmes <david.holmes at oracle.com>wrote:

> Hi Keith,
>
>
> On 17/04/2014 7:13 AM, Keith McGuigan wrote:
>
>> Hello,
>>
>> I just added a comment to this bug -- see there for the details, but in
>> short I'd like to update a number of tests in the makefiles that check
>> OPENJDK and change them to check instead of the inverse definition of some
>> new variable, such as ORACLEJDK.
>>
>
> Please no! It's bad enough this is implicitly in the build without making
> it explicit!
>

As I mentioned, I agree that moving all this to closed makefiles is the
best solution (and is something that we could push for even if we took this
partial step), but doing at least this step would be a vast improvement
from our point of view and is much easier to implement, especially for
someone like me who cannot do the make/closed refactoring.


> Would file existence tests suffice? There should be a CUSTOM_SRC variable
> for src/closed as there is CUSTOM_MAKE for make/closed.


It's not really feasible for the jdk makefiles.  Almost each location where
there is an OPENJDK test, when it is discovered that this isn't OpenJDK, it
ends up referring to files in src/closed (which for us don't exist).  In
Hotspot it's only a few makefiles, so not too bad there, but jdk is a
different story.

But really, there's three situations here, OpenJDK, OracleJDK, and
OtherJDK/custom, which can't be encoded using one boolean makefile
variable.  We really need at least one more here.  Why is ORACLEJDK so
abhorent?

 This would simply non-OpenJDK (i.e.,
>> src/closed builds), non-Oracle builds for those who are making their own
>> distributions using the src/closed mechanism.  As you can guess, that is
>> something we are doing here at Twitter :)
>>
>
> Hopefully you use src/custom (or whatever) not src/closed, as otherwise
> there's no way to tell the difference between our custom sources and yours.
>

The makefiles are already setup to use src/closed, so really that's the
most convenient way to add augmented sources to the build.  We'd very much
like to avoid changing mainline code to reduce the maintenance/merge costs
when things change.  I'm not sure it would help even if we did use a custom
directory instead of 'closed' though -- unless we went ahead and duplicated
all of the 'closed' logic for 'custom' (which again, would incur
maintenance costs and is not generally good engineering practice).

--
- Keith