Due to limitations in an lsp protocol a relationship between jdtls and boot-ls is somewhat complex.

boot-ls is a separate process similar to jdtls and thus needs same type of facilities to control its lifecycle.
boot-ls is using jdtls extension points(osgi fun) to extend jdtls itself(you started by adding some boot-ls jars into jdtls), meaning part of boot-ls code runs within jdtls.
lsp protocol don't have any kind of server to server communication, thus some boot-ls related code running on jdtls need to communicate with separate boot-ls process itself.
Order to hook boot-ls and jdtls together an lsp client is used to dispatch these messages. That's where classpath.ts and java-data.ts comes into play.
This client side logic to dispatch messages from jdtls to boot-ls is somewhat similar what i.e. nvim-jdtls do in jdtls.lua. We need to handle all those boot-ls messages send from jdtls and run workspace commands which neovim would then send to boot-ls. We need to mimic this logic from classpath.ts and java-data.ts.
There's additional complexities i.e in vscode where syntax server may be launched before main lsp server takes over. Syntax server provides limited features until full lsp is available. boot-ls needs a full lsp to be available. This is not an issue in neovim until nvim-jdtls implements this syntax server functionality.

Sunbelt Computer Software

PL/B Language Development and Support