[
https://issues.apache.org/jira/browse/DERBY-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17395294#comment-17395294
]
Richard N. Hillegas edited comment on DERBY-7122 at 8/7/21, 7:26 PM:
---------------------------------------------------------------------
The contract of java.util.Properties.store() says that after writing a
user-supplied comment, store() writes a system comment which includes the
current timestamp. This is almost certainly the reason that Properties.store0()
is calling getFormattedTimestamp()--which, in turn, ends up reading
SOURCE_DATE_EPOCH.
My source code for both Java 11 and Java 17 does not include the problematic
code. There is no call to Properties.getFormattedTimestamp(). In fact, that
method doesn't even exist. Instead, the Mac OSX version of Properties.store0()
generates the timestamp thusly:
{noformat}
bw.write("#" + new Date().toString());
{noformat}
was (Author: rhillegas):
The contract of java.util.Properties.store() says that after writing a
user-supplied comment, store() writes a system comment which includes the
current timestamp. This is almost certainly the reason that Properties.store0()
is calling getFormattedTimestamp()--which, in turn, ends up reading
SOURCE_DATE_EPOCH.
My source code for both Java 11 and Java 17 does not include the problematic
code. There is no call to Properties.getFormattedTimestamp(). In fact, that
method doesn't even exist. Instead, the Mac OSX version of Properties.store()
generates the timestamp thusly:
{noformat}
bw.write("#" + new Date().toString());
{noformat}
> java.security.AccessControlException when creating a DB remotely: Permission
> getenv.SOURCE_DATE_EPOCH
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-7122
> URL: https://issues.apache.org/jira/browse/DERBY-7122
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.14.2.0, 10.15.2.0
> Reporter: Art O Cathain
> Priority: Major
> Attachments: derby.log
>
>
> Following the tutorial at
> [https://db.apache.org/derby/docs/10.15/getstart/twwdactivity2.html] I get an
> AccessControlException in the server log when trying to create a DB (via
> CONNECT 'jdbc:derby://localhost:1527/seconddb;create=true')
> This is with derby 10.15.2.0 but the same is observed in 10.14
> OS version: Ubuntu 21.04
> Java version:
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2)
> OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2, mixed mode)
> but OpenJDK 16 and 17(early access) have the same problem
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
