Hi Jiri,
This is open issue #2 from JEP-220 [1] that we still need to address for
JDK 9, so your patch will likely be moot soon. It's possible that the
jar will be going away.
If you would like to watch the progress, please add yourself to:
JDK-8061842: Package jurisdiction policy files as something other than JAR
Thanks for the forward Erik, I'm not able to follow build-dev all that
closely lately.
Brad
[1] http://openjdk.java.net/jeps/220
On 5/20/2016 2:04 AM, Jiri Vanek wrote:
On 05/20/2016 10:12 AM, Erik Joelsson wrote:
(Adding Brad from the team owning these files)
I think I understand the problem now. Each time we create the jars,
they come out with binary
differences because there are different timestamps on the file inside
them, while the files inside
Exactly.
them are actually the same. Does the timestamp on the jar files matter
or just the contents of the
Timestamp of the file itself does not meter in this case. My idea was,
that once the jars become artificially reproducible, they may keep the
artificial timestamps too and so really relay only the changed policies
inside whose will be keepers of the change.
jar files? I can't imagine jlink/jmod affecting the timestamps inside
the jars, only the jars
themselves.
You are of course right - jlink/jmod is not affecting timestamps inside,
but is affecting only outside timestamp. I consider it as bad, as
although the file is somehow generated, it should reflect the policies
themselves. And so keep the timestamp.
Anyway - I don't insists on this part. It just give me (a lot of) sense.
Regarding GendataPolicyJars.gmk vs CreateSecurityJars.gmk, one is in
JDK 8, the other in JDK 9.
Aaargh. My apologize. I wonted to blame you that CreateSecurityJars is
rotten dead code in Jdk9, but It was me, I copied CreateSecurityJars
nex to GendataPolicyJars.gmk. And that CreateSecurityJars come from
icedtea, but I forget. So.. Sorry!
Regarding your proposed change, I think the security team needs to
approve the approach before I
judge it from a build point of view.
That would be really nice! Thank you very much!
J.
/Erik
On 2016-05-20 09:25, Jiri Vanek wrote:
Hello!
Thank you for quick answer.
However. .not exactly the one I hoped for:(
Generally - IMHO the CreateSecurityJars.gmk is never used to generate
policies, only the
GendataPolicyJars.gmk is used for that.
Thats why my unhappy patch is here.
In one way or another - the GendataPolicyJars should be removed, or
he lines regarding policies'
jars from CreateSecurityJars should e removed (second is probably
more correct way, If you light
on green light to this patch, I will remove the lines from
CreateSecurityJars and test)
jmod? jlink? Crap :) The policies had remained simple jars, and are
nothing but copied into image.
I was looking to Images.gmk pretty much, and found quite a usages of
JLINK_TOOL but found much
less looking to it,, not its usages nor it documentation did not
resolved how the jars get to the
old good.../lib/security/ directory. It does not have much to do with
modules....
And even if the jlink tool should be responsible for copying the jars
(which is pretty obfuscated
way) then perhaps it should keep time stamps? (just thought)
I'm much much more troubled about way how the GendataPolicyJars and
CreateSecurityJars are mixed up:(
Again, thank you very much for looking into it!
J.
On 05/19/2016 07:07 PM, Erik Joelsson wrote:
Hello Jiri,
If I understand the question correctly, you are wondering how the
policy files from
CreateSecurityJars.gmk end up in the final image? This is done in
two steps. First the new JDK 9
tool jmod packages each module into a distribution format (typically
java.base.jmod). Then the next
new tool jlink links all the jmods together to create an image.
Somewhere inside those tools, I
assume timestamps are changing.
/Erik
On 2016-05-19 18:52, Jiri Vanek wrote:
Hello again!
webrev
https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/
Recent Feature Complete milestone have scared me, as I have
long-time persisting issue when
packaging openjdk (6..7...8 and 9)
The policy jars, always from same source, never the same. As they
are considered as configure
files, the RPM update treat them alike.
Not so do jdk build system, and every build have its "special" but
still the same. .policies.
This is fixed in my RPMS since [1] like [2]
Well, not nice. I checked icedtea, and they since [3] already have
this change [4]
So I looked into JDK9 and.. it ahave teh change in
CreateSecurityJars.gmk ! Not whole, but
definitely not used. I really do not understand why.
So there is patch for jdk9's -
https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/reproduciblePolicies/v1/
which is making the
policies truly static even with all this necessary stamping.
However, I must apologise for missing part, which I had not found
how to solve.
Up to "make" (build) everything is ok. but "make images" corrupts
the timestamps, I did not
found, where the built files flow to images:(to stamp them again,
and last time)
Best regards from CZ
J.
[1]
http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/commit/?h=f21&id=ae70e5d64fbe2fb042c0cee088316b39ee8bf8c9
[2]http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackReproduciblePolycies
[3]
http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/afd392dfaed5
http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/edf1cacfe015
http://icedtea.classpath.org/hg/icedtea8-forest/jdk/rev/9b6cfe5f5078
[4]
http://icedtea.classpath.org/hg/icedtea8-forest/jdk/file/tip/make/CreateSecurityJars.gmk
