Open letter to Christian Lenz and other skilled HTML and JavaScript guys willing to help HTML/Java API to be better.
The donation of new presenters by DukeHoff has been integrated into HTML/Java API version 1.7 - [the javadoc]( https://bits.netbeans.org/html+java/1.7/) has been kindly generated by Eric. One of the new presenters is [browser presenter]( https://bits.netbeans.org/html+java/1.7/org/netbeans/html/presenters/browser/package-summary.html). I have found it quite flexible - it starts an HTTP server on a local port and let's a browser connect to it. Then it handles all the message passing to make sure Java is executed on the server and JavaScript in the browser. It has great potential, but... The code is a bit unreliable. Take a look at https://github.com/apache/netbeans-html4j/blob/master/browser/src/main/java/org/netbeans/html/presenters/browser/Browser.java#L418 that one seems to open a long polling XHR connection waiting for commands from the Java side to be executed in the JavaScript VM. Whenever the JavaScript wants to call into Java, it uses another XHR: https://github.com/apache/netbeans-html4j/blob/master/browser/src/main/java/org/netbeans/html/presenters/browser/Browser.java#L636 - it seems to work most of the time, but not always (for example I have not got it working on Windows8 IE, only Firefox). Work to change the browser<->server connection to be more reliable welcomed! Help with identifying/fixing what is wrong welcomed too. Thanks in advance for your help, I am not that good in server/browser technologies. I don't even know how to properly debug what is happening in there - maybe the server accepts too many parallel connections? Maybe each client should only have one and share it? How? Etc... -jt PS: I was thinking of using WebSocket, but alas, the [basic building block]( https://bits.netbeans.org/html+java/dev/net/java/html/js/package-summary.html) requires the connection from JavaScript to Java to be synchronous and I have no idea how to simulate that... PPS: ... synchronous XHR is indeed bad, but this one is local call - e.g. fast and it works fine on all other supported platforms. Moreover there is too much code using `@JavaScriptBody(javacall=true)` which relies on its synchronicity. E.g. this direction of thoughts isn't really useful.
