Currently the Go buildpack has 6 nearly identical JRE implementations (~1300 lines total): OpenJDK, SapMachine, Zulu, IBM, Oracle, GraalVM. Each has its own copy of Supply(), Finalize(), MemoryCalculatorCommand() etc. with only names/strings differing.
In the Ruby buildpack, this was solved cleanly via inheritance — e.g. ZuluJRE < OpenJDKLike was 3 lines.
Proposed fix
Introduce a shared BaseJRE struct with Go embedding:
type BaseJRE struct {
ctx *common.Context
jreName string
envVarName string
memoryCalc *MemoryCalculator
...
}
// Supply(), Finalize(), MemoryCalculatorCommand() implemented once on BaseJRE
type ZuluJRE struct { BaseJRE }
type SapMachineJRE struct { BaseJRE }
// etc.
This would reduce ~1300 lines to ~200 lines of shared logic + ~5 lines per vendor.
Context
Discovered while fixing #1257 — the LoadConfig() bug (reading only JBP_CONFIG_OPEN_JDK_JRE for all JREs) was a direct consequence of the duplicated structure. A minimal fix was applied to pass jreName to NewMemoryCalculator. The base struct refactor is the structural follow-up.
Currently the Go buildpack has 6 nearly identical JRE implementations (~1300 lines total): OpenJDK, SapMachine, Zulu, IBM, Oracle, GraalVM. Each has its own copy of
Supply(),Finalize(),MemoryCalculatorCommand()etc. with only names/strings differing.In the Ruby buildpack, this was solved cleanly via inheritance — e.g.
ZuluJRE < OpenJDKLikewas 3 lines.Proposed fix
Introduce a shared
BaseJREstruct with Go embedding:This would reduce ~1300 lines to ~200 lines of shared logic + ~5 lines per vendor.
Context
Discovered while fixing #1257 — the
LoadConfig()bug (reading onlyJBP_CONFIG_OPEN_JDK_JREfor all JREs) was a direct consequence of the duplicated structure. A minimal fix was applied to passjreNametoNewMemoryCalculator. The base struct refactor is the structural follow-up.