Merged
Conversation
alexduf
added
the
maintenance
Contributor
alexduf
force-pushed
the
adu-standard-sbt
branch
from
084de28 to
0d8da3f
Compare
So no-one gets blocked
SiAdcock
reviewed
Feb 13, 2026
| -Xmx8G | ||
| -XX:ReservedCodeCacheSize=128m | ||
| -XX:NewRatio=4 | ||
| -Duser.timezone=Australia/Sydney |
Contributor
There was a problem hiding this comment.
Is it possible to add a comment to this file explaining why we're using an Australian timezone – I'm guessing it's to make sure we don't make assumptions in the logic that the reader is always in the UK?
Contributor
Author
There was a problem hiding this comment.
I couldn't find a description of the format for .jvmopts and therefore I'm feeling a little worried about adding a comment in there (I did think about it)
Yes the timezone set to australia is specifically to mess with the timezone so nobody makes assumptions about the timezones
Member
There was a problem hiding this comment.
Looks like we can add it as a comment! Done in #28607
SiAdcock
reviewed
Feb 13, 2026
| . ~/.sbtconfig | ||
| fi | ||
| # sleep for a few seconds to ensure the user sees the message | ||
| sleep 10 |
gu-prout
bot
added
Pending-on-ADMIN-PROD
Pending-on-FRONTS-PROD
Seen-on-ADMIN-PROD
and removed
Pending-on-ADMIN-PROD
labels
|
Seen on ADMIN-PROD (merged by @alexduf 9 minutes and 4 seconds ago)
|
|
Seen on FRONTS-PROD (merged by @alexduf 9 minutes and 25 seconds ago)
|
rtyley
added a commit
that referenced
this pull request
Feb 13, 2026
…t timezone Grant Klopper first made this change to the Frontend codebase in June 2014 with #4713 - he explained: > "dev machines will now run in a far away timezone so it is more obvious when you get a timezone wrong" With the wonderful work to drop the custom `sbt` script in #28599 in January 2026, we weren't sure (#28599 (comment)) if we could keep the helpful comment explaining why the timezone was used - can the `.jvmopts` file, where the setting now lives, accept comments!? It turns out `sbt` takes the input from `.jvmopts` here, calling `$(loadConfigFile .jvmopts)`: https://github.com/sbt/sbt/blob/v1.12.2/sbt#L869 The `loadConfigFile()` function reads in each line of the file, and crucially calls `eval` on it: ``` eval echo $line ``` https://github.com/sbt/sbt/blob/v1.12.2/sbt#L771 The definition of `eval` is: > "The eval utility shall construct a command by concatenating arguments together, separating each with a <space>. The constructed command shall be read and executed by the shell." The upshot is that this line of input: ``` -Duser.timezone=Australia/Sydney # because it is too easy for devs ``` ...becomes the shell evaluation of: ``` echo -Duser.timezone=Australia/Sydney # because it is too easy for devs ``` ...which as far as the shell is concerned, is just: ``` echo -Duser.timezone=Australia/Sydney ``` ...so we _are_ allowed comments! This behaviour was added to the sbt launcher script with this commit in June 2013, as part of sbt/sbt#6458: sbt/sbt@1835225 We can double-check it works by running `sbt -v` to see the arguments the launcher script passed to Java: ``` % sbt -v [sbt_options] declare -a sbt_options='()' [process_args] java_version = '11' [copyRt] java9_rt = '/Users/roberto_tyley/.sbt/1.0/java9-rt-ext-amazon_com_inc__11_0_22/rt.jar' # Executing command line: java -Xmx8G -XX:ReservedCodeCacheSize=128m -XX:NewRatio=4 -Duser.timezone=Australia/Sydney -DSTAGE=DEV -DAPP_SECRET=this_is_not_a_real_secret_just_for_tests -Dsbt.script=/opt/homebrew/Cellar/sbt/1.12.0/libexec/bin/sbt -Dscala.ext.dirs=/Users/roberto_tyley/.sbt/1.0/java9-rt-ext-amazon_com_inc__11_0_22 -jar /opt/homebrew/Cellar/sbt/1.12.0/libexec/bin/sbt-launch.jar [info] welcome to sbt 1.12.2 (Amazon.com Inc. Java 11.0.22) ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why?
When retracing the history of the
./sbtscript, we can go back to May 2012Back in 2012 it was good practice to embed the SBT jar in the repo as well as having a running script that could be customised to have specific JVM and SBT options.
The best practices have moved-on long ago: it is now common to assume that
sbtwill be installed on the engineers machine and the CI, and SBT itself is capable of fetching the right version based on theproject/build.properties.SBT has also added support for the
.jvmoptsfile back in 2019, meaning the last valid reason to keep the custom./sbtscript is now gone, and we can achieve the same feature using the latest best practices.What's the value?
An engineer first starting on this project will be able to use "muscle memory" and type
sbtdirectly in their terminal without having to remember that this project is a special case.It also greatly simplifies plugging a debugger in our app from IntelliJ
Habits
I've re-introduced an
./sbtscript that informs of this change to ensure as smooth a transition as possible. It displays the following: