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)
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)
I'm working on research to move an existing applet (extends Applet) to Java Web Start due to the deprecation in Java 9. However, it seems like most of Oracle's migration docs instruct the dev to use the "applet-desc" tag to create a new JNLP and migrate. Does this mean that launching applets outside of the browser will not be deprecated?
If not, then what is the recommended approach? Saying "rewrite your applet" doesn't help... that's what everyone says. Doesn't really give me the "how".
What are possible solutions and examples/tutorials of migration? I can't seem to find much newer documentation out there, I see a lot of stuff between 2001 and 2011. It seems like most websites that provide examples no longer host the applications, or they aren't properly signed.
EDIT
My most important part of the question is: Is Oracle deprecating the Applet class when deprecating the browser plugin? Or, can we still use classes extending Applet within the tag in a JNLP, without a deprecation warning?
My applet requires user authentication and session cookies that are dynamically generated in our JSP. I've seen online that this is possible. This JWS application is not to be used offline, and is meant to be launched from an HREF. Is this still valid?
The thing that is deprecated is done by the browser manufacturers (though Oracle, realising the situation now advises not to develop them). So Oracle has not 'deprecated' the applet tag(1) in the same way that it has deprecated other classes, methods or attributes as occasionally mentioned in the Java Docs.
As to launching the applet using JWS, yes that should still 'work'. But note that whereas (for example) Chrome used to pass a JNLP direct to the program registered as a consumer of that file type (wherein it would be passed to the Java Web Start Client included in the JRE), it now causes the user to first download the JNLP, then explicitly choose to launch that file.
Update: Oracle may not have deprecated the applet tag, but they'll do effectively the same thing come Java 9. From JDK 9 and the Java Plugin:
By late 2015, many browser vendors have either removed or announced timelines for the removal of standards based plugin support, eliminating the ability to embed Silverlight, Java, Flash and other standards-based plugin technologies.
Oracle plans to deprecate the Java browser plugin in Java Standard Edition Development Kit 9 (JDK 9). Deprecation is a warning for developers to stop using this technology. JRE 9 will continue to provide the Java Plugin and support launching applets on browsers that still offer standard plugin support. This browser plugin will be removed from the Oracle JDK and JRE in a future Java SE release. Developers and users who want to learn more about this planned change can find out more in this blog post.
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.
Greetings,
I have read that QuickTime for Java is esentially broken on both Windows 7 and Snow Leopard. I can't tell how broken -- doesn't seem broken, but could just be my setup. I'm trying to determine whether this is a good technology stack, or if I should look elsewhere.
Objective: I want to build a specialized desktop video player and annotation program for both Mac and Windows (and Linux if possible). I think I want to use JavaFX (JavaFX as a Flash/Flex alternative that can use all Java libs and can build a decent UI.) I need to use something like QuickTime vs. Flash video as I need frame-accurate playback and wide codec support. I'd prefer to code in a relatively high-level language (not C++).
Thanks,
Cameron
Apple seems to have abandon QT for Java. Wikipedia's QuickTime for Java page seems to sum it up well. A select quote:
Currently most of QTJ is broken on
recent windows-running computers.
Windows machines that use the
no-execute (NX) page-protection
security feature of recent CPUs cannot
run even the demos without changing
the configuration. This can be easily
verified by a developer via a test-run
of one of the demos coming with QTJ.
An "execution protection violation" is
reported and the program is aborted by
Windows. This renders QTJ unsuitable
for end-user application development
due to the necessary complicated
configuration of the NX feature.
So, not good.
Following the 2003 release of QTJ 6.1,
Apple has made few updates to QTJ,
mostly fixing bugs. Notably, QuickTime
7 was the first version of QuickTime
not to be accompanied or followed by a
QTJ release that wrapped the new
native API's. QuickTime 7's new API's,
such as those for working with
metadata and with frame-reordering
codecs, are not available to QTJ
programmers. Apple has also not
offered new classes to provide the
capture preview functionality that was
present in versions of QTJ prior to
6.1. Indeed, QTJ is dependent on some native API's that Apple no longer
recommends, most notably QuickDraw.
And probably not going to look good. Ever.
Have you tried Xuggler? It should work 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.