Slow Execution of a Java Applet using HTML5 Widget

Hi Sergio,

fearandir said Hi all. Currently, we are testing the Uniface 9.6 html5 capabilities involving the HTML widget. We have designed a form which loads a HTML page on a HTML widget and runs it. The HTML implements a couple of Javascript scripts and Java Applets.

Why do you want to use Java Applets? The HTML widget is actually just intended as a HTML renderer and not as a web browser substitution.

fearandir said The problem on this scenario is that the execution time until Java Applet executes is really slow. (MINUTES!) Meanwhile if we use the old "Web Browser" OCX implementation it take a few seconds, really similar to run the HTML file on a regular web browser. The documentation says that the new widget is based on "Chromium". Which "Chromium" version has been implemented?

It's an older version. And we plan to update the underlying Chromium Embedded Framework (CEF) in one of the next versions. But I currently cannot tell you for which version this will be done and when. And I'm also not sure if this will have any impact on the issue you described above.

fearandir said Is it configurable via ASN files or other vias?

No. The HTML widget is built with a certain version of CEF. This is not something that can be changed by an end user.

fearandir said Do Exist a method to debug the execution?

Not sure what exactly you mean by this. Maybe you could use the Developer Tools of Chromium? The tools can be started using Ctrl+Shift+I (when the HTML widget has the focus).

fearandir said Thanks and i am sorry about my poor english language Sergio.

No worries! You are doing fine. Hope this helps. Regards, Daniel

Thank you for the support.

Why do you want to use Java Applets? The HTML widget is actually just intended as a HTML renderer and not as a web browser substitution.

Well, that is a good question... We don't want ... The client wants... We are dealing with a legacy client-server uniface application that deals with external  platforms and services. In this particular case,  the uniface app connects to a certificate repository using a java signing applet. We want to integrate the HTML5 Widget  because  supports user-defined extended triggers that can be called from JavaScript in the widget content. The  Internet Explorer browser OCX extended trigger capabilities are... well you know.. "limited" but we will give it a try.

It's an older version. And we plan to update the underlying Chromium Embedded Framework (CEF) in one of the next versions. But I currently cannot tell you for which version this will be done and when. And I'm also not sure if this will have any impact on the issue you described above.

I don't think so... Google will drop the support of NPAPI which is used by Java Applets, on Linux platform this has happend, and on other platforms they are planning to drop NPAPI support in Q2 2015...   Thank you Daniel.

Thanks for your reply. And you are welcome. And I also saw that Google will drop the support for NPAPI soon. I think it's better when Web Site do not rely on any 3rd party plugins to show its content. But that is just my opinion. Just for my understanding: can you call the java signing applet locally or do you need to run it in the context of a web site? In case the applet is available locally on the client where your Uniface application is running then you could invoke the java applet using JNI. I In order to get this working you need to create a small C routine that will invoke the java applet via JNI. And the C code can be easily called from Uniface using (e.g.) a C Call-Out signature. I believe one of my colleagues has a simple sample that demonstrates this approach. So if you're interested then I could ask him if he could make this sample available as a Community Sample here on Uniface.info. Hope this helps. Daniel

Hi Sergio, Are you by any chance using UHTTP to get the web page and then putting the content into the HTML widget ? Or do you load the web page directly into the HTML widget ? I recently noticed a performance issue with the first method. Not sure if it is related. It is debatable whether (and how well) Java applets should work in the HTML widget. As Daniel explained, the widget can not be expected to have full browser capabilities. Perhaps CEF 3 (which we are planning to use in the not too distant future) will improve that, but this is just speculation on my part. The sample I have, as mentioned by Daniel, is for calling a regular Java class (using JNI) from Uniface. Unfortunately this can't be used to run an applet. Applets have a very special interface and rely heavily on their host (a browser or the Java Applet Viewer) to create their environment.   Cheers, Chris

Hi all!

Are you by any chance using UHTTP to get the web page and then putting the content into the HTML widget ? Or do you load the web page directly into the HTML widget ?

We load the webpage with "loadURL" function: $fieldhandle(navigator.dummy)->$widgetoperation("loadURL","C:\TMP\SIGN_PDF\index.html") The HTML invokes the JAVA applet via Javascript. As i said before, The uniface application its a legacy application that deals with a heavily implanted J2EE oriented enviroment. So the applet solution is not in discusion. It is the "standard". So i understand, the HTML widget is not the ideal solution because is not designed for this and struggles on performance terms The sample you were talking about could be really useful for our company for other purposes apart of this one. Could you provide some samples as Daniel said ?   Thanks a lot for your patience and support. Sergio.

Hi Sergio, I checked up on that sample. Presently it's not more than a piece of JNI code and a trivial Java class. It will need a bit more work to make it into a proper sample. I'll try to set aside some time for this. It would help if you could log a support case with the subject "Call Java class from Uniface". Please note that the sample will only deal with the Java primitive data types. Cheers, Chris

I'm well underway with the Java call-out sample now. Time permitting I will have something of generic use in a couple of days. Chris