RFR: JDK-8078046 Remove MCS post-processing on Solaris

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Fri Apr 17 10:33:22 UTC 2015


On 2015-04-17 12:18, David Holmes wrote:
> Hi Magnus,
>
> On 17/04/2015 7:18 PM, Magnus Ihse Bursie wrote:
>> We should remove the MCS post-processing on Solaris.
>>
>> The msc command is used to post-process the binaries on Solaris, with
>> the intent of adding the version number. Post-processing of binaries is
>> a step that we'd like to avoid, if possible.
>>
>> It now turns out that the MCS processing has been broken since at least
>> JDK8, and nobody has noticed. I recommend we just remove it.
>
> In what way was it broken?

It was intended to add the version string to the comment field. However, 
sometime early during development of the original build-infra, the code 
was moved so that the variable containing the version string was put in 
spec.gmk, which made it evaluate to empty when POST_MCS_CMD was defined 
in the configure script. So it sets the comment field to "JDK " instead 
of e.g. "JDK 1.8.0".

>
> What role was it serving?

Putting the version string in the comment field of Solaris binaries. I'm 
not sure what purpose that in turn would serve. Checking some random 
Solaris binaries doesn't show any consistency in how/when this field is 
set to anything meaningful, neither can I dig up any serious use cases 
on Google.

>
> Who was the consumer of the added information?
?? Nobody that have discovered that it has been missing since JDK8 and 
complained, at least.
>
> Are the people who can answer those questions likely to be watching 
> build-dev? ;-)

SInce my guesstimate is that this set of people is ~= Ø, the answer 
would probably be yes. ;-) (But that depends on your set logic 
interpretation of member-of and empty-set :-)).

> Happy to see code removed and the build simplified, but only after 
> ensuring we understand the impact.

I have no clue how to further locate anyone who can describe the impact, 
apart from the apparent lack of anyone complaining for all this time. If 
you have any suggestions, please forward this review to them.

The reason I noticed this at all was due to the work for the new version 
string, JEP-223. So the alternative to removing this is to "fix" it and 
introduce a version string that has not been there for all of JDK8, and 
which is soon likely to change radically in format anyway.

/Magnus



More information about the build-dev mailing list