Reflection_multi-language kernel switching_path_conflicts with VP project

[xp1632]

Q: If I have A jupyter notebook that has multiple cells, the first cell is code written in python, the second cell is code written in java. I first run this notebook with IPython kernel for execution of the first cell, and I would like to use its result, changing the kernel to IJava Kernel and run the second cell of Java. Is it possible? would the data be lost while I changing the jupyter kernel?

---

A:

Unfortunately, Jupyter notebooks do not support running different cells with different kernels within the same notebook. When you change the kernel in a Jupyter notebook, it restarts the computational environment, which means that all variables and imported modules from the previous kernel are lost.

If you need to use both Python and Java in the same project, there are a few workarounds:

• Use a polyglot notebook kernel: BeakerX is a Jupyter extension that provides a kernel capable of running multiple languages in the same notebook, including Python and Java. However, it's worth noting that while BeakerX supports many features of each language, it may not support all features or libraries.

• Use a Python-Java bridge: Libraries like Jython, JPype, or Pyjnius allow you to run Java code from within Python. You could write your notebook in Python, and use one of these libraries to call your Java code when needed.

• Use inter-process communication: You could run your Python and Java code in separate processes, and use a form of inter-process communication (like writing to a file or a database, or sending messages over a network) to pass data between them. This would allow you to use separate notebooks for each language, each with its own kernel.

[xp1632]

However, while BeakerX also supports "polyglot magics" which allow you to run code from different languages within the same notebook. You can use the %%python magic to run Python code in a cell of a Java notebook, or the %%java magic to run Java code in a cell of a Python notebook.

Here's an example:

Please note that while this allows you to run code from different languages in the same notebook, it does not allow you to share variables or data directly between the languages. You would still need to use some form of inter-process communication (like writing to a file or a database, or sending messages over a network) to pass data between the languages.

[xp1632]

To summarize, in order to exchange data between different languages,

• we not only need a handler to switch the kernel for different languages
• but also we need an external inter-process communications
  • to save the data( writing to a file to database)
  • or sending messages over a network

[xp1632]

My impression of the related paper is that, they either has another external environment that contains these cells inside the same scope to achieve data exchange, Or they store all the outputs into another database and call it when needed

[xp1632]

So now we try the wrapper way of JPype and PyImageJ

[xp1632]

Final thoughts of changing path:

• In our initial plan,
• we would like first to run ImageJ functions with jupyter Java kernel

• then switch the execution kernel based on the different types of language we use

  However, after further development of the visual programming project, we find the original path might not work:

Reason 1 : data losing when changing kernel

• changing execution kernel in jupyter would lose all current data

Reason 2 : not partial execution in VP

• in the current visual programming project, even we have functions for individual node,
• the final execution happens when we add all the codes of nodes into one snippet(deleting duplication)
• it also blocked the way of execution for different nodes with different language and pass execution result to next node

---

• This is lead to the result that we can only achieve a pure java environment when running ImageJ in jupyterlab
• which conflicts with our key intention: lower the barrier of programming and features of flexibility and generalization
• Thus, we go to another path of PyImageJ, which would not make significant change of our current python compatible VP project and keeps ImageJ functionality