Overriding javaHome in launcher-custom.yml doesn't work

[iamdanfox]

What happened?

As part of the Java8 -> Java11 migration, we've advised people that if anything goes wrong in prod you can just add javaHome: $JAVA_8_HOME to your launcher-custom.yml and restart to get back to the old behaviour.

What did you want to happen?

Unfortunately, go-java-launcher seems to ignore this field (and doesn't actually fail).

[nathklei]

@iamdanfox I hit this exact issue just now trying to go the other direction - take a gotham service with java 8 in its launcher-static and run it on java 11 to test.

Is there a workaround? What I'm going to try next is just edit the launcher-static in my dist but that seems a bit hacky.

[iamdanfox]

@nathklei I remember asking around about this and I think the consensus was that it was actually an intentional decision originally to make the choice of java version a product-owner decision instead of an operator-decision.

The risk of making it an operator decision is that a product teams might get a deluge of support tickets from deployments who are using the product on a different java version than it was intended to run on (or possibly even tested on).

Changing this would just involve adding some extra info the launcher custom type and changing how they're merged, but I think we'd want to acknowledge the risk in long tail of support problems before doing this!

[nathklei]

Thanks, I understand the rationale and have a workaround for my own ad hoc initial test. It does definitely add some rollout risk for our bigger internal services should we encounter issues, but I think a downgrade is a fine alternative. Will note this for planning.