[Buildroot] [PATCH 1/1] package/openjdk: modify site from mirror to official repos

Tudor Holton tudor at tudorholton.com
Mon Dec 2 06:09:33 UTC 2019

On 2019-12-02 01:18, Arnout Vandecappelle wrote:
> On 27/11/2019 06:39, Tudor Holton wrote:
>> From: Tudor Holton <buildroot at tudorholton.com>
>> Since Java 11 (and possibly earlier), OpenJDK now has its own official 
>> repository
>> at hg.openjdk.java.net which is referenced in all OpenJDK 
>> documentation.
>> This patch brings buildroot into line with that source and allows 
>> consistent
>> patching both across projects and for patches specific to buildroot 
>> environments.
>  I guess by switching to a different source repository, we're also 
> loosing some
> modifications that were done by AdoptOpenJDK, right? So could you 
> enumerate
> these changes (and possibly explain why they're not relevant/wanted
> for Buildroot)?

Thanks for looking at this. :-)

Well, it depends on who you believe and how good your crystal ball is.  
The current AdoptOpenJDK repos says "Mirror of 
http://hg.openjdk.java.net/jdk-updates/jdk12u/", but the hashes don't 
match.  Although, that could be something to do with the filename being 
ever-so-slightly different which obviously depends on how the hash is 

Either way, changing to the upstream source removes the potential for a 
code injection between the upstream source and buildroot which, in our 
case, is essential to some buildroot-specific integrations in the 
pipeline (namely new Java 9+ module management, removal of Xorg 
dependency, and uClibC integration) which would be painful to apply 
upstream, and could have the potential to break buildroot patches in the 
middle, leading to patch wars (speaking from experience).
>> Signed-off-by: Tudor Holton <buildroot at tudorholton.com>
>> ---
>>  DEVELOPERS                   | 3 +++
>>  package/openjdk/openjdk.hash | 2 +-
>>  package/openjdk/openjdk.mk   | 8 ++++----
>>  3 files changed, 8 insertions(+), 5 deletions(-)
>> index 991be89849..7c9cebfb2f 100644
>> @@ -2365,6 +2365,9 @@ F:	package/redis/
>>  N:	Trent Piepho <tpiepho at impinj.com>
>>  F:	package/libp11/
>> +N:	Tudor Holton <buildroot at tudorholton.com>
>> +F:	package/openjdk/
>> +
>>  N:	Tzu-Jung Lee <roylee17 at gmail.com>
>>  F:	package/dropwatch/
>>  F:	package/tstools/
>> diff --git a/package/openjdk/openjdk.hash 
>> b/package/openjdk/openjdk.hash
>> index 00d080aa3f..beed7a34a2 100644
>> --- a/package/openjdk/openjdk.hash
>> +++ b/package/openjdk/openjdk.hash
>> @@ -1,3 +1,3 @@
>>  # Locally computed
>> -sha256 
>> 5f73d86ed516173965b27754f1bb21374ccb1194a17c2d89d8018280ce5ffa78  
>> openjdk-12.0.2+10.tar.gz
>> +sha256 
>> b2bcad35656b00928683416f3480ad00363b00993eb711c3e1886e4fe77eefeb  
>> jdk-12.0.2+10.tar.gz
>>  sha256 
>> 4b9abebc4338048a7c2dc184e9f800deb349366bdf28eb23c2677a77b4c87726  
>> diff --git a/package/openjdk/openjdk.mk b/package/openjdk/openjdk.mk
>> index ea2555edcc..3081c2f895 100644
>> --- a/package/openjdk/openjdk.mk
>> +++ b/package/openjdk/openjdk.mk
>> @@ -7,7 +7,10 @@
>> -OPENJDK_SITE = $(call 
>> github,AdoptOpenJDK,openjdk-jdk12u,jdk-$(OPENJDK_VERSION))
>> +OPENJDK_PROJECT = jdk-updates
>> +OPENJDK_RELEASE = jdk12u
>  Is it relevant to create variables for these? Just use them directly 
> in the
> _SITE, like we do for most other packages.

This was inspired by a few other buildroot openjdk packages that have 
been floating around the internet.

It's more a style choice, but also an understanding of the upstream 
repos layout:

Since OpenJDK has multiple streams this may become needed later on.  
Things like aarch32 aren't in jdk-updates (yet).  Config.in may 
eventually be able to select the project and release, but I was trying 
to keep this all as close to the current version as possible.  Don't 
forget, also, that OpenJDK now has LTS releases, which I think would be 
preferable, but there will always be a demand for newer releases also.

I can concur to a simpler form if you prefer.

>> https://hg.openjdk.java.net/$(OPENJDK_PROJECT)/$(OPENJDK_RELEASE)/archive
>  I suspect this is an autogenerated archive, right? Do you know how 
> reliable it
> is w.r.t. changes in the hash? Long ago, we've had problems with github 
> a couple
> of times, where suddenly the generated tarball would be slightly 
> different and
> the existing hash would break.
>  I realize that it's hard to know for sure if the tarball is 
> consistent. But at
> least please check if there's nothing stupid like a download date
> embedded in it.

I can say for sure that we have now been using these archives for just 
over a year internally, since OpenJDK 11, and we haven't seen an archive 
hash change in that entire time.  This was a vast improvement on the 
previous Mercurial forest.  /archive is exactly as is sounds.  It's an 
archive that doesn't change, which is why it effectively negates the 
need for a "downstream" mirror.

Tudor Holton

More information about the buildroot mailing list