WebView has built-in javascript engine. What engine is used for it? Is it the same for openjdk and oracle jdk? May it be used separately from WebView, just as JSR 223 engine?
JavaScript Runtimes in the Oracle JRE
The full Oracle Java Runtime 8 ships with two JavaScript engines:
Nashorn: "Nashorn's goal is to implement a lightweight high-performance JavaScript runtime in Java with a native JVM. This Project intends to enable Java developers embedding of JavaScript in Java applications via JSR-223 and to develop free standing JavaScript applications using the jrunscript command-line tool."
JavaScriptCore: The JavaScript engine built into the WebKit implementation wrapped by WebView component the JavaFX system.
JavaScript Runtime Used by WebView and JavaFX applications
JavaFX Webkit does not use Nashorn, it uses JavaScriptCore.
You can use Nashorn to program JavaFX applications and APIs (as an alternative to programming in Java) and you can use Nashorn as a JavaFX script engine for JavaFX FXML documents, but you cannot use Nashorn as the JavaScript engine within WebView.
Background Source Information
There is some information on the JavaScript implementation in WebView provided by the JavaFX developers on the JavaFX mailing list. Quoting Richard Bair, an Oracle JavaFX developer (who in turn quotes Olivier Hunt, a WebKit Developer):
Well…. it goes like this. WebKit comes with JavaScriptCore by default, and this is the JS engine that we use. It is pretty good. My understanding is that JavaScriptCore (aka SquirrelFish aka Nitro) is the same JS engine used by Safari. When Chrome and Apple were both part of WebKit, one of the abstraction layers that Google had put into WebKit was the ability to swap out the JavaScript engine. When Google forked WebKit into Blink, the need for the WebKit project to have an abstraction for a different JS VM disappeared. As a consequence, the WebKit guys have been talking about removing those abstractions such that you won't be able to swap out the JS engine, [further info]. If/When that happens, it will be hard (or impossible) for us to switch over to Nashorn for WebView. We aren't going to fork WebKit, so we sort of have to follow along with what WebKit does.
"Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
Additionally we will only be supporting JSC in WebKit2, so I don't think anything could
convince me at least that maintaining support for multiple JS engines is good for the project." - Oliver Hunt
Disclaimer
This answer is related to Oracle Java 8 releases only; alternate and future JavaFX and Java implementations may have different internal implementations.
May it be used separately from WebView, just as JSR 223 engine?
JavaScriptCore in WebView cannot be used separately from WebView as a JSR 223 engine (as far as I know).
I think it is best to treat the JavaScriptCore implementation shipped to support WebView as an internal implementation detail of the WebView component and not treat the JavaScript implementation as a general purpose JavaScript Runtime to be used elsewhere. It is not an officially supported component outside of its specific use within WebView, and, when used there, the public WebView API shields you from the implementation details of the JavaScript runtime it uses: Such that it is deliberately opaque to users which JavaScript runtime is actually used to execute JavaScript within the WebView component.
Update
Since OP is more concerned about JavaFX WebView, it uses JavaScriptCore. Please read JewelSea's answer for a better understanding.
JavaFX Webkit does not use Nashorn, it uses JavaScriptCore
Oracle Nashorn is the JavaScript engine in Java 8. Until Java 7, the JavaScript engine used was based on Mozilla Rhino.
Yes, it is same for Oracle JDK and OpenJDK.
You can find more information on Nashorn on the Oracle Site.
Related
We have developed a Windows based Desktop application using Java Swing and build a exe of it using javapackager available in Java 8.
Now we are trying to automate the testing of it using Karate-Robot but Robot could not detect the fields on the GUI of Application. To further dig we have installed AccessibilityInsights suggested by Karate Community to figure out how to access elements on the GUI but it seems that our application is not getting detcetd in it. See attached screenshot.
Can someone help us on how to fix the application?
Will Java Accessibility Bridge help here? As per documentation https://docs.oracle.com/en/java/javase/11/access/java-accessibility-guide.pdf, Application needs to implement Java Accessibility APIs when it needs to be available to Windows Assistive technologies.
Edit 1: As per https://docs.oracle.com/javase/tutorial/uiswing/misc/access.html, "Because support for the Accessibility API is built into the Swing components, your Swing program will probably work just fine with assistive technologies, even if you do nothing special."
Ashish--
There have been multiple iterations of Windows-based assistive technologies over the years. The current iteration has existed since 2005 and is called UI Automation. This is the technology that is required for OS-provided tools like Magnifier and Narrator. It's also the technology that is required by Accessibility Insights for Windows. From your description, it might also be the technology that is required by Karate-Robot.
Java Accessibility Bridge uses an older iteration of assistive technology that is no longer recognized by OS-provided accessibility tools. It is recognized by some third-party accessibility tools (JAWS and NVDA, for example), but it is not recognized by OS-provided accessibility tools. To the best of my knowledge, Oracle has no plans to support UI Automation in the future. When their docs say that your apps will "work just fine", they're referring to users who rely on these third-party tools.
Accessibility Insights for Windows has made a conscious decision to support only UI Automation, since supporting 2 platforms would make things much more difficult. We chose to go with UI Automation because it is the only technology that is:
Actively supported by the operating system, with new features being regularly added and documented.
Supported by native Windows controls and most actively supported language frameworks.
The technology that we would expect new assistive technology tools to implement first.
I'm sorry to be the bearer of bad news on this.
DaveTryon (Accessibility Insights team)
Question: embed a portable web browser without cache into a java app? Using Java SE.
Can this be done? Are there any JNI supports for e.g. Chrome or Firefox?
Maybe Qt? QtJambi would allow interfacing with the Webbrowser? From what I understand QtJambi is now maintained by the community and LPGL, is QtWebbrowser embeddable for this purpose in the same licence?
Examining the available documentation and over the past few days this is what has emerged:
The open source browsers are Webkit (which is used for e.g. Safari), and the Mozilla flavoured Firefox. There is also Chromium which is the open source version of the Google flavoured Chrome which uses a lesser javascript engine (squirrel as opposed to v8) and does not have the multi-separate-thread modularisation of Google Chrome.
Additional information on Firefox: Mozilla Firefox is based on an application called xulrunner which uses xml and javascript to provide the additional functionality of firefox (other than the 'not so basic' browser - such things as the html parser, css renderer and javascript parser). Xulrunner is the implementation of the browser.
Firefox implements its own private xulrunner, however additionally there is xulrunner as a standalone install.
Xulrunner can be used to create standalone applications, that are based on a web-browser, and has support for javascript. Xulrunner is also used to create the plugins for firefox providing additional functionality.
In order to connect the front end to something a bit more sustained and powerful than javascript (which has improved in leaps and bounds in recent years), but is still not the strongest sustained engine, there is a C-library called xpcom.
Xulrunner uses xpcom (written in C) to expose the javascript variables and parse the dom, and link javascript variables, and do other 'browsery' things like read headers etc. More on Xulrunner and xpcom in a moment.
If you want a browser that is recent and functional (html 4 or 5, good support for css2 at least, and some css3, and solid rendering of javascript), your best bet other than compiling and embedding one of these open source browsers is to use SWT.
SWT is a gui interface, similar to swing, except that it implements a webbrowser type interface, and can be used to implement a browser. SWT also has some developed interfaces to interact both with the dom and the like. SWT was developed by IBM and is actively maintained.
What SWT does is implement the OS system browser, and has support for every major os. On the upside, this means that there is no need to embed your own browser, on the downside you are stuck with whatever browser / parsers exist on the operating systems, at whichever version. The default behaviour on a windows os for SWT is to use Internet Explorer.
It is also possible to implement non-os linked browsers like firefox by installing xulrunner, but this is an additional 20mb (not extensive but something to note), as the more recent versions of firefox are not recognised.
It is a requirement to have javaxpcom support and xulrunner to implement a firefox style browser in SWT. The easiest way to go about getting the last version supported by Firefox (xulrunner 1.9.) for javaxpcom is to download an application called prism. Prism uses xulrunner as its base to create browsers that are standalone to specific urls. There is a known hacked xulrunner 1.9. which has some issues - see wikipedia for information on this, if you aim to download xulrunner 1.9.* compiled already from source.
Xulrunner is developed alongside each and every new edition of the Firefox browser. Until v 1.9.* (firefox 3.* if I am not mistaken), there was additional support for a function called javaxpcom which was an interface written to link the c library Xpcom's functions to java.
Firefox's initial announcement of how easy and simple it was to embed and style your own flavour of xulrunner, and that it was easy to port to many different languages (support for C, initially support for Java, Python amongst others), but obviously there is some overhead to accessing and adding libraries.
Xulrunner is being promoted as a potential software solution to compete in the same playing field as java, but suffers the same limitations of javascript / html applications. Within those parameters it functions.
Since version 2 of xulrunner, support for javaxpcom has withered, as there is no active maintainer of that code. It is open source solution so presumably interest from someone with requisite skills might pick that up. Xulrunner is now recently in version 6 at the time of writing this answer. Xpcom however is still going strong. Presumably there was insufficient interest / activity in the community, amongst other potential issues.
Since javaxpcom has been reported to have broken, and requires someone to maintain an interest in the code; that work would have to come from someone who has a vested understanding of Xulrunners xpcom, or at least a collaboration from someone who has an understanding of changes made in xpcom. Comments from what I have read suggest that documentation on xulrunner may not be a detailed as it could be, nor on javaxpcom, but I am not in a position to evaluate these comments.
I had hoped that the basic core functionality could simply have been maintained, keeping the hard work involved in recent browser improvements in functionality 'embeddable'. Firefox's amendments have resulted in extensions breaking in newer versions, a function of keeping up with the times.
A non-open source solution that embeds a web-browser and the like is called webrenderer.com. It is maintained, but there is a price tag attached, which is not insignificant.
Another possible route to implement a web-browser in a java application is to go the route of a cross platform development platform called Qt. QtJambi is a LPGL licensed (previously commercial) webbrowser that has extensive documentation and support for Java implementation. There is obviously learning curve attached to using any new platform. Reasons for the move from commercial to LPGL? Presumably viability and commercial demand for java supported browsers has .... waned? A function of the times we live in no doubt.
GWT is the java / webbrowser google solution. GWT works by allowing developers to write java solutions, and then ports and converts this solution into a stable javascript that can be obfuscated. However GWT is not suited to developing a desktop type application, in the sense that it requires a 'server' implementation for the backend. In this sense it is most suited or similar to a PHP or ASP style client / server solution.
Whilst it is not impossible to write GWT as a desktop application, presumably you would have to implement Apache Derby, or Jetty or similar as an in-house server to do all the to-ing and fro-ing. Its not neat, elegant or specifically designed for this, but madder solutions have been tried. There have been php style desktop applications.
For a number of political and financially motivated reasons it appears that support for porting / embedding java and open source browsers is not on the up and up, a trend which began with apple's lack of interest in supporting java applications. Mind you, the browsers are open source and presumably with enough time and energy, javaxpcom etc. could be sustained, but who is going to do this for free, I do not know.
Java promised a java browser implementation but this was not released with the Java 7, and requires like most other things, an amount of work. Perhaps in 8? It is unclear even there if it will be ready by then, I can't quite work out if its currently on the roadmap or not, and doesn't appear to be their highest priority include.
SWT requires some additional libraries and installation to work on various platforms.
Some other open source solutions which do at least in part appear to work, but the maintenance, support and current interest in appears mixed to none, include JRex, MozSwing. Rhino is a javascript engine, flying saucer an html4 renderer.
If you are talking about Java SE based application I would highly recommend swt 'Browser' component. I have used it myself within Eclipse RCP based app and it works like a charm (flash, javascript support)
Which functionality will be shipping with version 2 and are there any additions known to be planned for later versions?
Will it reuse parts of the Applet/WebStart technology which are a bit more mature now or is the browser integration technique completely new? Will it be possible to access the whole JavaSE library or is it limited to a subset like Silverlight?
What about the overall rendering speed and architecture? Is it comparable to Swing/AWT?
It's just a JavaSE library, so you can use the whole Java SE API.
You can use java webstart or addtional integration features too (javascript).
In the end its really a full featured java SE application or Applet, but not on swing, but on JavaFX.
But if you want, you can mix Swing and JavaFX too.
I'm currently using the javax.script package for interpreting and executing Javascript code on the fly. Incidentally, this is the same engine used by Mozilla's Rhino JS interpreter.
Question: is there any Java-based Javascript Engine that is faster than Rhino?
In Java 8, Oracle plan to release Nashorn, which is their own JavaScript engine built into Java. It plans to be much faster than Rhino, and aims to be the reference implementation of JavaScript in Java for the future.
See a recent interview about it with Oracle # DZone:
If you are happy to use a pre-release JDK, you can download it here.
I haven't heard of any Rhino alternatives. According to this list: http://en.wikipedia.org/wiki/List_of_ECMAScript_engines, Rhino is the only Java-based JavaScript interpeter.
javax.script is way older (and slightly modified) than the current version of Mozilla's Rhino which you can download from the Internet. Have you tried getting the latest Rhino and using that?
Also depending on for what you're using it and what kind of integration you require, using node.js may be more suitable for you.
What is the equivalent of a Java applet in .NET? Is it Silverlight? Is Java applet still widely in use?
Java applets were "the new hot thing" in 1997, when Java 1.0 came out. After a few years, they became less and less popular, mainly because installing Java on a computer was a big hurdle for many people (you had to download the whole JRE, which was big, it took a long time to install and Java was not that fast at that time - so many people saw it as a slow, bloated thing).
Macromedia Flash (which became Adobe Flash later, ofcourse) had advantages over Java applets in this regard - the plug-in was quick and easy to install, and so it became the dominant thing for interactive multimedia stuff on the web.
Microsoft's Silverlight is meant to be a competitor for Flash and Sun's JavaFX.
JavaFX is Sun's technology that should make it easy to do Flash-like things on the Java virtual machine. If JavaFX becomes a success, then Java applets using JavaFX might become popular again.
Note that earlier this year, Sun released a completely rewritten Java browser plug-in which is quicker and easier to install than the old plug-in. On of the things Sun is working on is making it just as easy to install the Java plug-in as it is to install the Flash plug-in.
Silverlight is analagous to Java applets, but not really equivalent. In my experience, Java applets are being used less and less.
Java applets are seriously out of vogue now - I haven't heard of any new apps using them in years. .NET has silverlight, which is more of a response to Flash than to Java applets.
In this day and age with JQuery and Mootools, MVC architecture, and Chrome's V8 engine, it might actually be better to just write your application in Javascript.
Silverlight.
However, while Silverlight may be the new hotness, Java applets are still a lot more popular... most people have a JVM, but most do not appreciate a massive Silverlight install just to see your web page.
Now, many things that could only be reasonably done in Java or ActiveX are done in plain old JavaScript using new AJAX/DHTML libraries like JQuery and Ext JS. Example: Google Maps. Unless you're doing fancy graphics, try JavaScript first.
From a language perspective, there is a Java-like language available in .NET called J#, which can ease your pain if you are translating Java code to the .NET platform. It doesn't emulate the Java GUI libraries, etc. but at least emulates the syntax.
Silverlight or XBAP. See the FAQ for differences.
Basically XBAP applications work on Windows only and run on the full .NET Framework. Silverlight on the other hand uses different core and set of libraries and is designed to be cross-platform.
Either SilverLight, or an ActiveX control (still in use on some sites). Java applet will work only if a JVM is installed on the client machine.
You'll see applets in use more in enterprises where tight control is maintained over installed Java versions and the browsers i.e. where the execution environment is constrained.
However I'm seeing fewer and fewer applet solutions even in these environments, especially with the rise of RIAs.