Bad class file: version 52.0 not supported

[OCTAGRAM]

I am experiencing issue with classes in rt.jar being versioned artificially higher than enough for them. Community version of jvm2ada does not handle this. It can only handle 50.0 (found in JDK 1.6). There are other tools suffering from this rush toward artificial incompatibility.

cheerpj-strip is known to throw out the real bytecode. If bytecode is omitted, then most new features are omitted as well, and class format version can be set to the least compatible one which is likely to be in 1.4 .. 1.6 range.

[alexp-sssup]

rt.jar is a CheerpJ implementation detail to support reflection at runtime. Could you clarify what is your goal?

[OCTAGRAM]

There are custom JavaScript APIs, and I thought there are custom Java APIs as well. I thought there is additional benefit in binding it as opposed to targeting vanilla JDK.

[alexp-sssup]

There are internal Java classes, mainly (but not exclusively) to implement AWT. All the internal classes have significant native (i.e. JS) code since they are used to interface with the browser networking and graphical capabilities. How would binding work in this context?

[OCTAGRAM]

Binding generator would write Ada specification files to enable calling custom APIs. AFAICS the wiki only mentions JavaScript APIs, but I would expect JVM APIs to appear if not now then soon enough.

[alexp-sssup]

CheerpJ is a technology to run Java applications in the browser, so it's only natural that its APIs are only in JS. I am missing something, could you elaborate a bit more on your idea?

[OCTAGRAM]

JavaScript is a disaster. When in 2000s there was a hype about memory leaks through circular references, I thought, weak references will be introduced. JavaSctipt's "parent" Java language also had them, and for reference counted environments it is a more strict requirement. We used Delphi happily enough with RC via COM interfaces, but weak references were always there. Of course, there will be circular references if there are no tools to make them non-circular.

Ten years from those days, weak references are still not there, and instead of fixing the problem, the situation went worse due to mandating tracing garbage collector as the primary tool to manage deallocation. EcmaScript is managed by crazy people for some reason not providing what we are waiting since past century. We need weak references, and we still cannot have them. We need destructors, preferably RAII, and we still cannot have them.

Browser virtually forces to write any advanced stuff in CPS style, and it is too easy to leak memory by capturing static contexts despite all this TGC disaster constantly pushing hard to deallocate at least something. So I would suspect any JavaScript library written by human to be leaking more than solution transformed to CPS by tool. CheerpJ's multithreading simulation with such CPS transformation tool is a huge win. If I am given a choice between Ada library, Java library or JavaScript library, I would pick them in this order, and if I am to write my code, the order of preference is the same.

I played with Flapjax. Interesting toy, but it is doomed to remain a toy. RDP (reactive demand programming) cannot be put on top of FRP (functional reactive programming) in JavaScript easily. There is no portable way to know if some behavior is not demanded anymore, everything stucks forever. Of course, with strict discipline it is possible to manage reference count or write code that is subject to Dispose-aware TGC, but I would more expect special tools to produce JavaScript code having this high degree of integrity than a human writing it without errors.

CheerpJ shields from disasters happening outside. Let people behind EcmaScript be crazy, we don't understand them, we don't support them, we can't wait until their alien brains become wired sanely, we force take what we need another way. CheerpJ has custom TGC supporting Dispose and weak references, CheerpJ simulates multithreading, and Swing support makes it easier to do advanced stuff without suffering from crossbrowser issues.

So I was more interested in APIs visible inside JVM than outside, in JavaScript, or at least I was expecting both flavors to exist.

Browser environment differs slightly from normal one. There can be several "displays" accessible from the same code: iframe, frame, window.open, and it might make sense to have explicit control over it. Pluggable filesystem can probably be implemented via custom class loader, but it is more a hack for what could be done by API.

[alexp-sssup]

Thanks for sharing with us these interesting ideas. For the time being, though, the focus of the CheerpJ project will be on running existing/unmodified Java applications in the browser. CheerpJ is still in the Beta phase and expanding the scope of the project so much and so early seems premature.

Thanks again for your support.