We've currently got a hard-dependency on groovy. Unlike our normal server deployment, which can be configured at startup time for either groovy or python, we shouldn't need groovy for the embedded python server (which will always have a classpath explicitly for a python session script session).
public static <T> Type getDeclaredType(final T value) {
...
else if (value instanceof Closure) {
type = Closure.class;
}
...
}
And of course, the script session itself:
io.deephaven.engine.util.GroovyDeephavenSession
By presenting proper script session abstractions, we should be able to remove the hard-dependency on groovy-language specifics. This may have benefits of allowing us to remove python-specific dependencies when we know we only want to have a classpath for groovy, and it may have other benefits for potential future script session types (Scala, et al).
When starting up a python embedded server w/ the groovy.jar manually removed, we run into classloading errors:
java.lang.NoClassDefFoundError: groovy/lang/Closure
at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3166)
at java.base/java.lang.Class.privateGetPublicMethods(Class.java:3191)
at java.base/java.lang.Class.getMethods(Class.java:1904)
at org.jpy.PyLib.importModule(Native Method)
at org.jpy.PyModule.importModule(PyModule.java:94)
at io.deephaven.engine.util.PythonDeephavenSession.<init>(PythonDeephavenSession.java:86)
at io.deephaven.server.console.python.PythonConsoleSessionModule.bindPythonSession(PythonConsoleSessionModule.java:31)
at io.deephaven.server.console.python.PythonConsoleSessionModule_BindPythonSessionFactory.bindPythonSession(PythonConsoleSessionModule_BindPythonSessionFactory.java:53)
at io.deephaven.server.console.python.PythonConsoleSessionModule_BindPythonSessionFactory.get(PythonConsoleSessionModule_BindPythonSessionFactory.java:40)
at io.deephaven.server.console.python.PythonConsoleSessionModule_BindPythonSessionFactory.get(PythonConsoleSessionModule_BindPythonSessionFactory.java:12)
at io.deephaven.server.console.python.PythonConsoleSessionModule_BindScriptSessionFactory.get(PythonConsoleSessionModule_BindScriptSessionFactory.java:31)
at io.deephaven.server.console.python.PythonConsoleSessionModule_BindScriptSessionFactory.get(PythonConsoleSessionModule_BindScriptSessionFactory.java:10)
at io.deephaven.server.runner.DeephavenApiServerModule.provideScriptSession(DeephavenApiServerModule.java:94)
at io.deephaven.server.runner.DeephavenApiServerModule_ProvideScriptSessionFactory.provideScriptSession(DeephavenApiServerModule_ProvideScriptSessionFactory.java:42)
at io.deephaven.server.runner.DeephavenApiServerModule_ProvideScriptSessionFactory.get(DeephavenApiServerModule_ProvideScriptSessionFactory.java:31)
at io.deephaven.server.runner.DeephavenApiServerModule_ProvideScriptSessionFactory.get(DeephavenApiServerModule_ProvideScriptSessionFactory.java:10)
at dagger.internal.DoubleCheck.get(DoubleCheck.java:47)
at io.deephaven.server.runner.DeephavenApiServer.run(DeephavenApiServer.java:113)
at io.deephaven.python.server.EmbeddedServer.start(EmbeddedServer.java:79)
We've currently got a hard-dependency on groovy. Unlike our normal server deployment, which can be configured at startup time for either groovy or python, we shouldn't need groovy for the embedded python server (which will always have a classpath explicitly for a python session script session).
Some of our public apis have groovy:
io.deephaven.engine.util.ToMapListener#get(K, groovy.lang.Closure<T>, groovy.lang.Closure<T>)
io.deephaven.engine.util.SourceClosure extends groovy.lang.Closure
io.deephaven.plot.Figure#plot(java.lang.Comparable, groovy.lang.Closure<T>)
Some of our implementation details have groovy:
io.deephaven.engine.table.impl.lang.QueryLanguageParser
:io.deephaven.engine.table.impl.select.QueryScopeParamTypeUtil
:And of course, the script session itself:
io.deephaven.engine.util.GroovyDeephavenSession
By presenting proper script session abstractions, we should be able to remove the hard-dependency on groovy-language specifics. This may have benefits of allowing us to remove python-specific dependencies when we know we only want to have a classpath for groovy, and it may have other benefits for potential future script session types (Scala, et al).
When starting up a python embedded server w/ the groovy.jar manually removed, we run into classloading errors: