Read Java classpath config file and load all the classes into scope

[dhuebner]

• Load and read the config file
• Send path information to the java backend
• Insert all the returned class information into the scope

Note: Consider to change the JavaClass type so that it contains only members instead of fields and methods, similar to BbjClasses.

[dhuebner]

@StephanWald In the BBj.properties file there is an entry pointing to bbj_internal classpath: basis.classpath.bbj_default=(bbj_internal)

The entry for bbj_internal is not listed. Could your provide a list of jars that should be in? I suppose they are located in the ~/BBJ/lib/ ?

[StephanWald]

• BBjAPI() has to be hardcoded, it's a built-in scalar / factory method that is wired to the interpreter and not directly available from a JAR
• for the BBj types, look at the dependencies in this POM. If you include the three provided from the BBj lib you should have what you nee: https://github.com/DwcJava/engine/blob/main/dwcj-engine/pom.xml However, these JARs might bring more than what's allowed in the actual interpreter. The problem here is that the interpreter masks some of the types that can be found in these JARs. TBD

[dhuebner]

@StephanWald Thanks for detailed explanation!

BBjAPI() has to be hardcoded, it's a built-in scalar / factory method that is wired to the interpreter and not directly available from a JAR

Sounds like the BBjAPI can be described with BBj Classes and Methods. If so, this looks for me like another good use case for the built-in library approach. I will open a new Issue for that.

[StephanWald]

The return object you get from BBjAPI in turn returns types that can be found in one of the JARs mentioned. It's just that the factory method is hardcoded and does not need a use statement (and is itself not coming with a package)

It returns com.basis.bbj.proxies.BBjAPI

[dhuebner]

I think we can close this one