Run a jar from a java process.

[jabrena]

In order to help the users and increase the performance, it is necessary to create a visual utility that it could be possible to deployed to the EV3 brick with template_project in order to run a UI. That UI could execute other projects.

Benefits:

Once a JVM process is running, all Classes are loaded in the classpath so run another lightweight jar which only contains the classes compiled is fast and the user benefit is clear. Using this idea, the users developing with Java could participate in FLL competitions.

Initial Roadmap

• Run a Jar from another Jar
• Develop a UI to load files in a default folder from EV3

** Repository:**
https://github.com/ev3dev-lang-java/menu

Jar loader idea:
https://sourceforge.net/p/lejos/ev3/code/ci/master/tree/EV3Menu/src/lejos/ev3/startup/JarMain.java

[JakubVanek]

Supersedes #445, as this way the classes could remain loaded in the daemon.

[jartu]

Hi @jabrena,

My understanding of this task is this: You want to shorten the startup overhead caused by starting the JVM and by loading a whole jar (by running something like "java -jar xxx.jar"). This should be accomplished by essentially running this command (the "java -jar xxx.jar") just once (where the jar already contains almost all the necessary ev3dev classes) and then only load a - perhaps - separately uploaded jar (with nearly the same contents except for a few different classes) into the already running JVM so that only a few classes would be somehow hot-swapped in the running JVM? Is that correct?

Should the [re-]loading of the freshly uploaded jar to the existing JVM happen automatically (e.g. by copying a new jar into a pre-defined directory) or by having the user request the loading explicitly through some interactive console running from the original jar?

Thanks, J.

[jabrena]

Yes, this is the idea. It is a POC, but it could open many possibilities for this year...

Once we have an example running, we will refine evolve...

From the template project we can:

• Install general libraries
• Deploy and Run JartuJarLoader.jar
• Deploy and Run UserProgram.jar on JartuJarLoader.jar

The programs should fly...

Cheers

[jabrena]

I have created an initial demo here:
https://github.com/ev3dev-lang-java/menu

I will continue working on there in the next weeks.

[jabrena]

It is necessary to finish the following issue:
#607

To close the support for EV3 Display for EV3Dev Stretch.

[jabrena]

Finished issue #607

[jabrena]

For the first version, I am thinking in the following ideas:

1. List of files deployed on /root/robot/java/programs <- standard using gradle template project + gradle plugin
2. Some behaviour using the EV3 Keys to move up and down
3. When the user click in the ENTER button, the program will be executed.
4. ESCAPE button is managed by EV3Dev, so it allow the user to exit from the menu utility.

It is necessary to see if it is possible to rename the jars with a semantic name from the plugin with another param. Question for @JakubVanek
Why: Normally all programs deployed to the brick from the Gradle plugin get the name from the parent program, in this case template project. It could be nice, if the name is different or it is possible to overwrite the name with a specific configuration.

[jabrena]

Next week, I will try to tackle points 1, 2, 3 to have a mini prototype.

[JakubVanek]

Hi @jabrena ,

It is necessary to see if it is possible to rename the jars with a semantic name from the plugin with another param. Question for @JakubVanek
Why: Normally all programs deployed to the brick from the Gradle plugin get the name from the parent program, in this case template project. It could be nice, if the name is different or it is possible to overwrite the name with a specific configuration.

Yes, this should be possible to implement, it should suffice to change the name of the uploaded JAR in the uploading process.

Alternatively, it should be possible to change the jar name by simply changing the project name in the configuration. Also, I think the name does not come from the root project (but I am not sure) - the JARs from the example project (should) carry the names of the sub-projects. However, I agree that for rapid prototyping, it is useful to have multiple differently-named JARs from the (almost) same source.

If the purpose of this change is to display a nice human-readable name in the menu, there could be even better solution. It should be also possible to define a custom field in the MANIFEST.MF file that would contain the name visible in the menu. This field would then be set by a string in the project's gradle plugin configuration.

Regards,

Jakub

[jabrena]

I think that this option is enough:

Alternatively, it should be possible to change the jar name by simply changing the project name in the configuration.

I will check this week.