Update to buckjavaargs doesn't change java_library target's rule keys

[raviagarwal7]

╰─$ cat .buckjavaargs
-Xmx4g -XX:ReservedCodeCacheSize=512m -Xbootclasspath/p:3rdparty/jvm/com/javaxtools/javaxtools.jar

╰─$ ./buckw targets libraries/foundation/threading/threading-java/... --no-cache --show-rulekey
//libraries/foundation/threading/threading-java:src_main da6d09b92ec0fa74dd907cc7e8a73561507b315b

╰─$ cat .buckjavaargs
-Xmx4g -XX:ReservedCodeCacheSize=1024m -Xbootclasspath/p:3rdparty/jvm/com/javaxtools/javaxtools.jar

╰─$ ./buckw targets libraries/foundation/threading/threading-java/... --no-cache --show-rulekey
//libraries/foundation/threading/threading-java:src_main da6d09b92ec0fa74dd907cc7e8a73561507b315b

here updating XX:ReservedCodeCacheSize didn't have any effect on the rule key of the java library rule. This can cause inconsistent build if there are changes to the classes from the jar provided in bootclasspath is used during compilation.

is this expected?

[jtorkkola]

This is expected. .buckjavaargs is meant for Java runtime args that apply to Buck itself, not to compilation for Java targets that Buck produces. You should be using extra_arguments on java_library for the latter. I'm also unclear on why you're using -Xbootclasspath/p. Is there some reason you can't depend on a prebuilt_jar target?

[edsilfer]

Hi guys, just some context on how we are leveraging this for our particular use case. Our goal is to parse logs that comes from Buck in order to:

1. gather analytics, e.g. how long does a rule takes to build;
2. parse error messages in something actionable from developer's point of view.

We currently specify a custom java Handler in .bucklogging.properties. This handler is added, afaik, to Buck's root logger, then we can listen to anything that Buck publishes. In order for Buck to find our custom logger, I believe that we add our jar to bootclasspath by adding it in .buckjavaargs.