JDK-8025705

Keith McGuigan kmcguigan at twitter.com
Tue Apr 22 04:42:25 UTC 2014


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> wrote:

> 2014/4/16 14:52 -0700, 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
>



More information about the build-dev mailing list