Hi, everyone. Kodi recently added the BD-J Menu function in v19, a feature we are waiting for. However this needs a Java environment to work. So I think it would be necessary to build a Java in LibreELEC.
because adding 65MB of JRE to an image that was only 110MB to start with, to provide a feature that everyone has managed without since Kodi first added support for BR discs, is egregious bloat. We feel it makes no sense.
I appreciate the sentiment of not wanting to increase the size of the image so drastically (relative to it's original size), but the above seems to be at odds with the whole point of developing and introducing new features?
Previously everyone managed without BD-J because Kodi didn't support it when BR support was first introduced, and so people had no choice. Only relatively recently was support added and so as a result BD-J is now a feature that some people would like.
Is JRE the only way to facilitate out-of-the-box BD-J support in LibreElec? If so, is including JRE within LibreElec not worth considering? As I say, I appreciate not wanting to increase the image size drastically, but in terms of todays hardware, software and generally available bandwidth, 176MB seems no worse than 110MB.
There is none, but currently nobody had created an package for it, also there is no way in adding at to the image, the size increase is ridiculous for that minor function. We can only do it via an addon. java is sadly horrible bloated.
I'm rewriting OC-Minecarts for 1.10.2. But the Carts won't boot. If I insert no BIOS it works as intended and tells me, that I have to insert a BIOS EEPROM, same if I insert a BIOS but no OpenOS, but if I insert a OpenOS disk and power the computer cart up. The Startup routine crashes with "Unrecoverable Error java.lang.NullPointerException"
I don't know where this is coming from. The log doesn't tell me anything, even if I enable "logCallbackErrors" (and also some other options in debug category). Debugging with breakpoints also didn't help.
noticed the new branch on your github. Maybe we can work together at some point, if you would accept to make/use a more flexible class which just adds the OC Integration to any entity (not limited to minecarts)
Java updates used to leave older updates installed, but starting with version 6.0.10 it now removes the previous update - or at least it is supposed to; it seems to have failed for you. You can safely remove all but the latest version. This article has some additional information about the change and possible security issues stemming from leaving the older versions in place.
Type "aboutlugins" in the firefox url address bar to bring up a list of installed plugins and the filenames that provide them. In Windows they are .dll files in Linux, .so files, but only one filename for a group of addons.
Are there some frameworks (or a junit addon) for this problem?I'd like to run a junit test class (or even a single test) in a different process? It would be cool if one unit test can easily access the variables of the other test (in a different process) using some sort of inter-process communication.E.g. I'd like to check if the producer really produced the things i expected, and afterwards, if the consumer consumed them. (and maybe do some fuzzing to detect some race-condition-related problems)
I would describe what you are looking to do as an integration test, and beyond the scope of JUnit as a framework (JUnit is only now dipping its toe into multi-thread testing, multi-process is certainly not in the feature set).
Others have already pointed to the fact that you would usually mock or otherwise send artificially constructed methods to the consumer, and test what the producer produces independently at the "unit test" level.
In terms of actually testing the interaction between the producer and the consumer, one approach is to forget about the inter-process testing, and test it intra-process on one thread via some sort of Dependency Injection where the
