Current Browsers - Applet Support - Java Applet Development

Hello everyone,
I'm developing a new applet that will be for individual and corporate users and will be digitally signed. I've been out of the applet world for awhile and was hoping to get some feedback on the current level of support for Java applets among common browsers and systems.
So the questions are:
If you were developing a new applet for use 'in the wild' what JVM version would you target?
Is Swing (or another gui toolkit) generally available now? (it wasn't last time I developed an applet but that was a long time ago)
Do most users (including companies) seem to have java support enabled in their browsers?
Any feedback is much appreciated! 

If you were developing a new applet for use 'in the wild' what JVM version would you target?1.5 until somebody screams, then 1.4. I wouldn't go further back except under duress, and then only to 1.3. The <object> tag and JNLP deployment (see below) let you define an auto-install for a later JVM than the user currently has.
Is Swing (or another gui toolkit) generally available now? (it wasn't last time I developed an applet but that was a long time ago)Yes, since the Sun/Microsoft settlement and the demise of the MS VM, about six years ago.
Do most users (including companies) seem to have java support enabled in their browsers?Pass. Probably.
See also [this thread|http://forums.sun.com/thread.jspa?threadID=5446861&tstart=0]. 

jasonward wrote:
If you were developing a new applet for use 'in the wild' what JVM version would you target?1.6.0 - It's been available for almost 4 years and contains [Java plug-in 2|https://jdk6.dev.java.net/plugin2/] which is a major update to the plug-in technology.
Do most users (including companies) seem to have java support enabled in their browsers?FWIW, the small site I run reports for the current month the most popular browser plug-ins to be :
Flash : 92.1 %
Java : 78.4 %
PDF : 70.5 %
I'd say it depends on your target audience though. If they are likely to be computer literate, then they probably have more chance of having Java installed.

Related

jre 8 compatibility

So I see according to the ol certification matrix, forms doesn't do jre 8. I'd be curious as to when that would be expected to occur. (Also it doesn't do ie 11). That too.Since the jre 8 has been unleashed I have a fear of having to deal with the jre 7 autoupdating to 8. when will that start happening one wonders?
According to this: http://www.oracle.com/technetwork/java/eol-135779.html End of Public Updates would be in April 2015 as for now, so that would be the point in time when you'll be bossed around to update to java8. cheers
No with jre 7 they started auto updating from 6 to 7 way way before the end of life of 6.I still cannot fathom why oracle doesn't create the ability to have two jre plugin versions operational at one time. For example, a jre 6 and a jre 7, or a jre 7 and a jre 8 and so on.
Let me see if I can provide an answer to all of these questions and comments: 1.  We are currently doing some new Certification testing that will apply to the v11 family.  Depending on the results of that testing, we are planning to update 11gR1 and 11gR2.  However, if problems arise during testing, the new Certification plans will likely change. 2.  If you are already running a newer version of Java 7, I do not expect that you would be prompted to install Java 8.  You would however be prompted to install the latest Java 7 release. 3.   You can install more than one Java family version on your machine.  Exactly which versions will depend on how old you wanted to go.  Exactly which one is used by your application will depend on the application configuration.
thanks for the info!  It is definitely not common knowledge how to specify what version of java will be executed, unless perhaps you are talking about ie. Due to the dangers of using ie we never tell people to use it. (However in case we had to, we would like the optionof using ie if there were no other option. It's just that ordinarily we tell people to avoid it.) My experience with firefox an chrome is that it will only call the most recent version of the jre that is installed and it might refuse to call that.  Does anyone know of anything informsweb.cfg that would be able to call the jre 6 when the jre 7 has been installed and it works in firefox or chrome?  (Hint: no one does family classids except IE.)What would be terribly useful would be this:the newest jre is installed and the previous jre is installed (i.e. 8 and 7 or  6 and 7 for example).I want a way to specify that some certain lineage can be called for example 6 despite the presence of 7 and have it happen in firefox or chrome. Similarly with the same setup I'd like to be able to specify that whatever version of 7 is present be called on a machine with 6 and 7.(no sub versions specified. I want this to keep working as updates occur to in this case, 6 and 7).
I think the first important thing to make clear about this topic is that it has nothing to do with Oracle Forms.  This is strictly about how Java and the browser work together to host an applet.  Therefore, your best resource for documentation will be in the Java deployment guides.   In general, the new behavior of the Java plugin is to always try to run the newest version in a family if more than one exists.   A "family" is a major version.  So, Java 6 is a family.  Java 7 is a different family.  The U or update version is exactly that, an update within the family.  In other words, a patch.  So, 6U40 (aka 1.6.0_40) is patch 40 in the Java 6 family.  This is important to understand when we start referring to "Family" CLSID and other similar references. So, here are some basic concepts.  Again, you can find more details in the docs (see below). For Internet Explorer:IE uses the CLSID to determine if the needed plugin is installed on the machine.  If IE finds the CLSID in the Windows Registry, it launches it.  Here are a few examples with an explanation of what each means: This is the dynamic CLSID.  It basically means that you want your application to use the newest version of the newest family that can be found on the machine. clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 This is a version specific CLSID.  This is used when you want to specify exactly which version to use.  Notice how the version number is part of the string clsid:CAFEEFAC-0017-0000-0051-ABCDEFFEDCBA This is a Family CLSID.  It tells IE that it should use the newest patch version in a specific family.  In this example, Java 7 is the family of choice. clsid:CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA  For Non-Internet Explorer (e.g. Firefox, Chrome, Safari, etc):Non-IE browsers use the mimetype to determine which plugin and version to use. This is the dynamic type.  Similar to the dynamic CLSID for IE, this will use the newest version of all that are installed application/x-java-applet This is a version specific type.  It will try to find the exact version specified. application/x-java-applet;jpi-version=1.7.0_51 This is a family type.  It will use the newest in a family. application/x-java-applet;version=1.7 In some cases, you may find it necessary to use the applet parameter "java_version" in order to specify an exact version.  This is due to a bug in some earlier Java releases.  So if you find that the above isn't working as you expect, try adding java_version as described in the Java documentation.  For Forms, you will need to add a reference to it in basejpi.htm before you can set its value in formsweb.cfg Here are some helpful references: http://www.oracle.com/technetwork/java/javase/index-141751.html http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/applet/applet_deployment.html#JRE_VERSION If you have related questions that are not specific to Oracle Forms, but are JRE related, consider posting your question in the JRE Forum: https://community.oracle.com/community/developer/english/java/java_desktop/java_runtime_environment_(jre)
Thanks for the info but how can you possibly think that running the jre has nothing to do with forms? Last time I checked forms was 100% dependent on running the proper jre in the browser as an applet, which causes many points of failure. We will recall that the fact that the jre 7 changed the vendor name from sun to oracle was enough to stop forms from running, much less any other compatibility issues. This is particularly a problem in shops that run other oracle software! So suppose we have oracle product A that requires the jre 7 and oracle product B that requires the jre 6 what to do to run them both? . People who deploy products that depend on browser plugins have to above all else pay attention to whether the customers can run the product or not!Unfortunately the reputation of the jre plugin as being the most dangerous thing on earth has not been abating despite the jre 7u51 modifications in Jan 2014 that were really good at keeping everyone from running applets, regardless of whether the applications had been compatible with the jre 7 or not. http://www.javaworld.com/article/2104862/java-security/report-half-of-all-exploits-target-java.html  It's getting really hard to justify having the jre around, period. People who deploy applets would do very well to not see running applets as not in their purview and instead work with browser vendors to solve deployment issues, or deploy their own browser. (But if it becomes the number 1 security problem on the internet they need to pay attention and fix the problem.) Argh! It gets worse (91%)  https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf"• Java comprises 91 percent of web exploits; 76 percent of companies using Cisco Web Security services arerunning Java 6, an end-of-life, unsupported version."(That's not even true. Java 6 is supported albeit for a fee. Why does the vendor or java allow these incorrect statements to be publishedall over the internet and never take action? We are soon going to be in the boat that we won't be able to run products that require the jre.) "Java exploits far outstrip those detected in Flash or Adobe PDF documents, which are alsopopular vectors for criminal activity (Figure 11).Data from Sourcefire, now part of Cisco, also shows that Java exploits make up the vastmajority (91 percent) of indicators of compromise (IoCs) that are monitored by Sourcefire’sFireAMP solution for advanced malware analysis and protection (Figure 12). FireAMPdetects live compromises on endpoints, and then records the type of software thatcaused each compromise."
"....how can you possibly think that running the jre has nothing to do with forms?..."I'm sorry.  I guess I wasn't clear.  What I mean is that the way in which the browser reacts to a CLSID or MIMETYPE has nothing to do with Forms.  In other words, I would expect the same behavior with a "Hello world" applet as I would with Oracle Forms if I configured the html in a similar manner.  The Forms applet does not get into the game until AFTER the plugin has been loaded and the applet started.  Up to that point many things occur on the client tier which are unrelated to Oracle Forms.  All Forms does leading to startup is send html content to the browser.  It is up to the browser and the OS it runs on to decide how it will render that html.  Once the browser decides how it will react to the provided html, it (the browser) will request that the appropriate plugin be started.  If the wrong plugin is started, that has nothing to do with Forms as a product.  It either means you have misconfigured something, or there is a problem with the browser, the OS, or Java Plugin. If you have product A that requires JRE X and product B that requires JRE Y then you install both JRE versions and properly code your html for each of those applications. Regarding your comments about the security of the Java Plugin, I will not go into detail, but will say this.  Whether it's the Java Plugin, an OS, database software, a credit card reader, or whatever, the issue is only magnified because of the media (TV, newspapers, Internet, etc.).   Years ago, network traffic wasn't encrypted and at that time no one really worried about it.  Did we stop using Intranets or the Internet as a result?  Well, of course not.  The technology evolved and improved.  In my opinion, many (not all, but many) security issues are the result of administrators not taking proper precautions to protect their environment.  If an admin chooses to not use SSL, well shame on them.  If the admin chooses to allow the wrong people access to the server's file system, well shame on them.  If end-users are permitted to receive email attachments from outside domains without proper scanning, well shame again.  If admins choose to not block users from having access to known malicious web sites, shame on them.  If admins permit unskilled end-user to install software on their (client) machines without an administrators supervision,review, or prior approval, well shame on them.  And so on...  I completely understand that not every situation can be foreseen, but with a pro-active approach and a properly skilled team, the engine should run smoothly most of the time. As for the article you pointed out, I can only hope that the actual point was to encourage people to use the latest Java versions rather than the older ones.  If not, then all it will do is discourage people from using a great technology and miss out on what it offers.  Oracle has made huge improvements in the latest Java releases, so much so that some users are actually complaining that it's been locked down too far.  So how exactly do you make everyone happy????  .................................................................................................................................The views expressed in this posting are my own and do not necessarily reflect the views of Oracle..................................................................................................................................
Well I see your point that the forms developers don't want to take on responsibility for deploying applets. If I were in your shoes I wouldn't want to get that assignment either!  Problem is, if the vendor has a lot of products that deploy applets, the vendor has to take some responsibility for ensuring that those applets can run. If they don't run, there are angry customers and lost sales for all the products that can't run properly. And note that there are already increasing problems with customers who can't run the jre at all such as on i-devices and android. So the endpoint pool is shrinking as it is. I'm suggested that the vendor create a division to research deploying java and in the real world.  If it is not possible to run the products in freely available off the shelf software (browsers) then get on plan B! The applications are on the server, the endpoints can't run applets in the legacy manner, what other choices are there and do it. And do it now would be my advice. Should it wait until the day that all browsers block all versions of the jre and then decide to start looking at the issue? As an example, I highly suspect that the technology to choose jre versions is dependent on the java deployment toolkit, in non ie browsers. In firefox it is blocked, at least on mine as we are still running 6u71. It's up to date (until apr 15 probably) but no one recognizes it as up to date. https://addons.mozilla.org/en-US/firefox/blocked/p428  They don't say if they block all deployment toolkit versions or just some. The vendor recognized that here:http://www.java.com/en/download/faq/deployment_toolkit.xml"What does the Java Deployment Toolkit (DT) do?The Java DT is a very useful tool, used by Java applets and applications to help manage getting the right version of Java for a user’s system. For developers, it also provides a JavaScript interface. The interface automatically generates the HTML code that is required to deploy Rich Internet Applications (RIAs)."That stuff about javascript is so vague I have no idea what they mean. Are they saying javascript from applets won't work or are they talking about something else? They say this also:"Does deployJava.js work if the Java DT Toolkit plug-in is disabled?Yes, deployJava.js contains some pure JavaScript functions, which will continue to work even if the Java DT Toolkit plug-in is disabled."I still don't get it, what javascript where doesn't work if the deployment toolkit  is blocked? If you look at chrome, it's not possible to tell what is in there. Chrome just says there are 2 java files. and then there's IE. We know forms doesnt do ie 11 so that's out. We have something like ie 7,8,9 and 10 then I guess? In IE 8 on this machine it has a whopping 6 plugins involved in java any and all of which can be disabled or removed. JQSIEStartDetectorImpl Class Publisher    Java(tm) Plug-In 2 SSV Helper Version       6.0.710.12 Class ID:    {761497BB-D6F0-462C-B6EB-D4DAF1D92D43}Java(tm) Plug-In SSV Helper Browser Helper Object 6.0.710.12 Class ID: 761497BB-D6F0-462C-B6EB-D4DAF1D92D43} Java Plug-in 1.6.0_71  ActiveX Control 1.6.0.71 Class ID: {8AD9C840-044E-11D1-B3E9-00805F499D93}Java Plug-in 1.6.0_71 ActiveX Control 1.6.0.71 Class ID: {CAFEEFAC-0016-0000-0071-ABCDEFFEDCBA} Deployment Toolkit ActiveX Control 6.0.710.12 Class ID: {CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA} Also there are options there remove all sites, allow all sites on many of those.  It does not seem to allow whitelisting the sites that should be able to run the plugins in version 6. It is all or nothing.     The only way to know what happens there is to test it and with 6 different plugins that's a lot of testing. And that requires a lot of knowledge of how it's supposed to work. It would be a great job ... for the people that wrote the java deployment plugin! Test their jre and deployment toolkit with their own products that depend on it.  Note that if you are going to have a lot of requirements for endpoint management that needs to be in the product sales literature.The deployment toolkit turns out to be thing number 1 that attackers look at according to this:http://www.fireeye.com/resources/pdfs/fireeye-java-vulnerabilities.pdfVendors and customers have to stop being helpless victims pushed around by security pundits. Instead vendors and customers need to work together to ensure the customers get their work done with a reasonable level of risk and let the money hungry security wonks go look at something else to up sales.
We are clearly off topic, although I do believe this is a good discussion, just not for a forum posting. I spent about 20 minutes dwelling over a long winded reply I was going to post, but decided it likely would not get us far.  If you are interested in discussing this further, do not hesitate to contact me directly and I will help you to understand our position on some of the comments you have raised. 

sound from microphone

Hello everybody (sorry my english is not good)
I am asking about the possibility of use JavaFx for a Web application.
My doubt is because : i must record sound from microphone (voice).
I know that i must user for example JavaSound API for that purpose but i would like to know if this code will run on client side or not?
Is it possible to do this microphone --> JavaSound --> JavaFx --> Web application?
Thanks a lot for your help!!!
(From Paris/France) 
I see in comments on http://javafx-jira.kenai.com/browse/RT-3458 "Camera and Microphone" that Randahl advised you that he is able to use Java Sound to access a microphone (which he does successfully for a stand-alone app).
If it works for stand-alone app it will work for a browser embedded app.
As Randahl points out in the comments on that jira issue:
Of course, when running in a web page, there may be certain privileges that your app needs to have. You might want to look up Java Webstart and security privileges.Signing with a self-signed certificate is straight-forward.
Signing with a certificate signed by a certificate authority, is a bit more complicated and expensive, but perhaps worthwhile depending on your application.
For info on signing see the JavaFX deployment documentation:
http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABJGFBH "Sign the JAR Files"
Further links to related info and threads are referenced from:
Signing a JavaFX application "Signing a JavaFX application"
Try your app out first without signing it first - if there are no security exceptions, then signing is not required - if there are security exceptions (i.e. stuff doesn't work in browser embedded mode but does as a stand-alone app), then you will need to sign your app.
There are many pitfalls of deploying in browser embedded mode, be careful that you understand what it means for you and your users if you choose this deployment mode. 
By the way on a related topic:
I am not sure, if it is possible to stream audio with the JavaFX MediaPlayer!?
I've looked into the Media class and it seems, it only supports a String as source (file, or http), but no InputStream.
Depending on your requirements, this could be important as well.
Does anybody know, if I am correct, or if Streaming (audio and video) is planned for JavaFX 8.0? 
Hello and thanks for your answer
Please, what are those "many pitfalls of deploying in browser embedded mode"?
The deployment Kit does not work well?
thanks 
Maybe he refers to all the Java Critical Patch Updates which were released during the past weeks!?
I mean, e.g Firefox disabled the Java plugin because of security issues.
http://support.mozilla.org/en-US/questions/946955
Or he refers to all the trouble you will get into, when you try to sign your jars and generate a JNLP file.
I tried it myself, only with self signing and stumbled over these bugs:
http://javafx-jira.kenai.com/browse/RT-28424
http://javafx-jira.kenai.com/browse/RT-24872 
By the way on a related topic: I am not sure, if it is possible to stream audio with the JavaFX MediaPlayer!?Note that this question and answer is only tangentally related to the original question of sound from microphone and entirely unrelated to the original poster's intention of using javax.sound classes to capture microphone input within an applet.
It is possible to stream audio with the JavaFX MediaPlayer.
JavaFX supports http live streaming (which includes the ability to use an audio only stream).
See the JavaFX media documentation:
http://docs.oracle.com/javafx/2/api/javafx/scene/media/package-summary.html
HTTP Live Streaming (HLS)
HLS playback handles sources with these characteristics:
- On-demand and live playlists.
- Elementary MP3 audio streams (audio/mpegurl) and multiplexed MP2T streams (application/vnd.apple.mpegurl) with one AAC audio and one H.264/AVC video track.
- Playlists with integer or float duration
Sources which do not conform to this basic profile are not guaranteed to be handled. The playlist contains information about the streams comprising the source and is downloaded at the start of playback. Switching between alternate streams, bit rates, and video resolutions is handled automatically as a function of network conditions. For further info, see the HTTP Live Streaming Specification:
http://tools.ietf.org/html/draft-pantos-http-live-streaming-10
And an HTTP Live Streaming faq:
http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
JavaFX MediaPlayer currently doesn't support some other streaming media protocols (and generally related formats) such as:
- rtsp (real time streaming protocol) - the original realnetworks realplayer protocol.
- mms (microsoft media server protocol) - a protocol for streaming windows media .wmv/.wma files.
- rtmp (real time messaging protocol) - the original flash streaming protocol.
- ogg (vorbis/theora bitstreams) - open container format for multimedia.
I don't believe support for those additional protocols or related formats is planned for JavaFX 8.
There is a feature request to support aac/aac+ radio streaming (e.g. shoutcast/icecast) - the feature is currently targeted at Lombard (JavaFX 8):
http://javafx-jira.kenai.com/browse/RT-19582 "aac/aac+ radio streaming"
http://javafx-jira.kenai.com/browse/RT-17556 "Support for shoutcast/icecast streaming (mp3/aac(+))"
One of the jira issues mentions that there is a separate feature request on file for streaming from a Java InputStream, but I don't know what the link to that is, nor when that is scheduled.
Finally, there is this issue currently scheduled for implementation in Lombard (JavaFX 8):
http://javafx-jira.kenai.com/browse/RT-2684 "Media playback needs to be extensible. User defined codecs or media sources should be supported."
Once that is implemented, it should be able to develop 3rd party add in plugins to allow the JavaFX media player to playback other media codecs (e.g. the opus codec) and utilize different streaming protocols (such as the ones that are currently not supported today).
I do have an open question on whether it is possible to "Use http live streaming to stream data from a Webcam"
Using http live streaming to stream data from a Webcam
In case somebody knows the answer to that. 
what are those "many pitfalls of deploying in browser embedded mode"?Ah, I was hoping you wouldn't ask and just do some independent research into this, but I guess I may as well answer.
Don't take this post as a negative comment on Java of JavaFX, it's really just specific to the deployment in a browser scenario.
---------------
The main issue is that embedded Java applications won't work immediately in many user's browsers.
The main competing technology for JavaFX embedded in a browser is the html/css/javascript stack, which (cross-platform browser issues not-withstanding) generally seems to work immediately for most people most of the time. And when html/css/javascript does fail, it is usually a soft fail where some small widget on the page doesn't function or isn't rendered quite right, rather than a catastrophic fail where the entire application functionality is not usable (as is the case in most deployment failures for a browser embedded JavaFX app).
Many security experts advise (and numerous tech writers) advise that user's remove or disable Java and many browser vendors have taken this to heart, making it more intrusive to the user to run Java in a browser (and sometimes stopping Java from working in a browser at all). A google search by clicking the link provides more information:
https://www.google.com/search?q=java+disable
Basically the reason for the advice to disable Java in a browser is that many zero-day vulnerabilities have been found in the Java client runtime and these have been exploited numerous times by drive by download malware attacks. In such an attack, a user just visits a url in a browser and their computer becomes seriously infected with malware.
In recent Java updates, Oracle have upped the default security profile settings for Java in applets so that every applet (even unsigned ones) will show a security warning before running - perhaps this will reduce calls to disable java in browsers as well as browser vendors aggressively disabling it (but that remains to be seen).
There are other issues besides (these are off the top of my head, so some my be slightly inaccurate or outdated):
- the Java runtime on Windows installs the ASK toolbar by default on every update
(https://www.change.org/petitions/oracle-corporation-stop-bundling-ask-toolbar-with-the-java-installer)
- there is currently (as of JavaFX 2.2) no plugin for JavaFX in a browser on Linux.
- troubleshooting issues when installations go wrong is difficult.
- internet explorer 10 doesn't allow the JavaFX browser plugin to run.
- only a subset of browsers are supported (for example JavaFX 2.2 apps don't run in Chrome on OS X).
- android, iOS and Windows RT systems are highly unlikely to let the JavaFX browser plugin run (ever).
- every java applet from an untrusted publisher will display at least one security warning message (and all publishers are untrusted by default).
- security dialogs of signed apps request all permissions from the system (even though the app may only require a few high level permissions).
- signing apps with a code signing certificate from a trusted CA is expensive and time consuming for a single developer and requires regular renewal and ongoing expense.
- when a java applet fails, often the user will be presented with a pretty uninformative error message.
- each browser vendor seems to have implemented their own method of disabling untrustworthy plugins and most of them seem to treat the java plugin and runtime as untrusted unless you are running the very latest version of the plugin and even then they can block the plugin and can make it hard to re-enable for users.
- care must be taken that the user installs the correct architecture version of the java runtime to match their browser (e.g. 32bit runtime for 32 bit browser).
- the java runtime is auto-updated and may be updated to a version which has compatibility issues with your app, causing your app to spontaneously stop working on some user systems.
- some jnlp features did not work for JavaFX 2.0 (e.g. webstart related ones such as desktop icons and custom splash screens).
- jnlp has a jar and network caching feature which seems more trouble than it is worth as you might not want the user running a cached archive.
- jnlp based updates of apps can be as slow as installing the original software.
- there are not that many applets in widespread usage, so many users don't have experience with them.
- numerous users who have used applets in the past, may be wary of the technology due to poor user experiences that had in the past with applets in general.
- a large part of your deployment is out of your control:
* how the Java runtime gets installed and the associated branding and advertising screens which come with it.
* the deployment toolkit scripts and runtime should be obtained from Oracle to function correctly with the latest Java plugin (and Oracle can drop them or stop supporting them like they did JavaFX 1.x scripts - though this is unlikely to occur for the JavaFX 2 deployment scripts during the next ten years).
* I believe the user needs admin privileges to install the Oracle Java runtime distributable.
...
Some other classic issues such as slow start up time, grey patches appearing while the applet is loading, etc. have been rectified by improvements in the underlying platform, deployment toolkit and plugin technology.
Some more background information on the technology is available here:
http://docs.oracle.com/javafx/2/deployment/jfxpub-deployment.htm
http://mindprod.com/jgloss/jnlp.html
All of that doesn't mean that you shouldn't deploy a browser embedded JavaFX app, just that it's a good idea to understand what you are doing before you start doing it so that you can set your expectations and your user's expectations appropriately.
Alternative deployment technologies to consider are standalone jars, webstart apps and self-contained (native) apps. These other deployment technologies bring some advantages, but also some disadvantages as well. Such options are not mutually exclusive with browser embedded apps. For instance, you could a offer browser embedded version of your app, and also a self-contained version for those who prefer to install your software like a "normal" app. A self-contained app would be useful if you intend to target deployment to an app store or something like a yum based rpm distribution network:
http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGIBBCI
One thing you might want to try is a hallway usability test of your chosen deployment technology - pick five or six people at random and ask them to open the ensemble app on various computers and browsers and observe them and get their comments on the usability of it.
http://download.oracle.com/otndocs/products/javafx/2.2/samples/Ensemble/index.html 
Thanks a lot for your answers, they are very very interesting and i will read all that work.
My initial post is beaucoup my client:
- needs to records voice from microphone in wav format for scientific traitments in the server (specialist in phonetic). No streaming at all
- needs Web and standalone versions (or only web at least)
that's why i thought that JavaFx was a good solution but i think that it is a risc for me
I know very very very well Flex/AIR/Flash/as3 and you can do all of that staff work without problems at all. Server could be PHP or Java.
But i needed to know if others solutions would do the job as well.
If my client decide to do only web version i think that a good solution could be HTML5/web sound API (only Chrome and Mozilla)/Ajax.
I don't like (as many people) the Applets!
Flash Player does not give me feal of a risc so flex/AIR could be also a good solution for web/standalone job
Thanks thanks a lot beacause you helped me a lot in my choice.
Java and the web is not (yet) a good solution.
Nora (from Paris, with a very bad english...)

Rapid switching between Java clients in Windows

The problem we are having is, as a University teaching Networking and
Telecommunications courses, we have older networking equipment, particularly HP, that has various Java versions imbedded in it, some of which is no longer vendor supported. The console system the instructors use requires at least two different versions of Java to be installed on it at all times. We need an older Java client (version 1.4.2) so we can access the older networking equipment control panels, and new versions of Java (version 1.5.x) for web development. Both Java versions work but, according to the professors I support, switching between them is relatively time consuming when you have one class that requires one version, and the next class five minutes later requires the other version.
These same Professors want a "quick and easy" method of switching between them, such as a script on the desktop that they can click on to change between versions. As PhD's, they are "too busy" to use the Control Panel applets as they take time that they'd rather use for setting up the days lessons. I am not a programmer, I'm a technician so I don't have the scripting knowledge to create such a script.
Therefore I'm submitting this request to see if such a script is available, or information on how to go about creating one. The console system they use is Windows XP with SP2 installed.
We use both Firefox, and IE6 for demonstration purposes.

How can I make an old Java Applet work?

I need help with an old applet which I can't use. For many years i used a Java Applet called TeamStats for different sports league tables. It was a simple but very useful applet. Then Oracle started to come up with their new security things which made almost all my Java Applets impossibe to use, unfortunately also TeamStats. After trying for a while to get this applet work, I simply gave up. For two years I've tried different programs which can be used for maintaining sports league tables, all of them more complicated to handle and not as useful as TeamStats. I even bought a buggy program for a nice sum of money which turned out to be worthless, very limited and no support at all from those who sold it to me. I've tried to construct Excel tables but it's too complicated and they take too much time to work with.  So I've decided to bring TeamStats back to life. But how? I've contacted the guy who made the original applet. Unfortunately he has moved om to other projects. He had no intentions at all to create a new applet hor help me get this one in order. Is there anyone here who can help me use this applet again? I can send it or make it downloadable if necessary. The problem I'm facing are all warning messages which shows up when I try to use the applet. I have no idea how to certify this or make it work with the recent Java uppdates. I've tried to certify the product on my computer but the recent Java versions doesn't allow me to do it Unfortunately, I only have the Swedish applet and other language versions aren't available anymore. I hope that someone might understand the principles for the applet anyway and make it work for me. Or if there are anyone who can create a new but similar useable applet for me. Thanks in advance.
Hello, Your question is not clear! what error did you face? Java still support Java applet technology, you simply could have some security issues which solve by signing a jar fileor using a old JDK version  (1.6). If you need to rewrite your java applet as desktop application you could post job on freelance platform (for example upwork), I don't think that would be expensive. Best regards,Dmitry
Take a look at this how-to article: https://java.com/en/download/help/enable_browser.xml  There are two potential causes that might cause an applet to stop working: a) a new version of browser (see the note about Chrome in the linked article) b) a new version of Java. From your description it rather seems that you are facing issues of the b) type. If you can, you might install an older version of Java and use the steps described in the how-to article to make your browser use that Java version. It might be wise to do it in a virtual image, because on the contrary your other apps might require a newer version. Alternatively, you might also try to fix the issues - e.g. by signing (see Signing Applets Using RSA Signed Certificates) as rpc1 mentioned. If you want some help with that you should share more details.
Thanks Jiri Machotka-Oracle and rpc1 for your replies and kind efforts to help. I will try to further explain the problems. I was using TeamStats for many years to maintain sports league tables, some of it for personal use and some of it for a website for an ice hockey team I was maintaining. The problems started in 2014 with the new security measures from Java. I have Chrome as my main browser but for my own HTML-site with the application I use Firefox. I have created a HTML-site for the TeamStats applet but that site is only on my computer, not on the Internet. Now, when I try to start the applet, the following message comes up: "Application blocked by Java-securityFor security reasons, applications have to fulfil the demands for security settings High or Very high or be on the list for website exceptions to be allowed to runName. embe.ts.TeamStatsPlace: file://Cause: Security settings has blocked a local application from being allowed to run." OK, I'm translating the message from Swedish. It might look a bit different in an English language browser or Java version. There is a map called embe with a "cabinet file" called ts.But there's also a compressed map called ts in the embe map and also a file map called ts in the embe map which has the following content:ComparePanel.classCompareStats.classLeague.classMatch.classMatchPanel.classMatchSeries.classMisc.classResObj.classResults.classStatPanel.classTable.classTablePanel.classTableteam.classteamStats.classTSPanel.classWS_FTP The WS_FTP text file is referring to my updates for a hockey team website which I was maintaining 10 years ago so I guess we can forget that. When this problem occurred, I contacted the person who created the TeamStats applet. Unfortunately, he had no plans to make a newer version of the applet. Instead I got the advice to look for programs on the net with a similar function. Which I did-with terrible results! I wouldn't bother to try to bring the TeamStats applet back to life if it wasn't for the fact that I need this program for certain tasks. I've tested some similar programs, both free and purchased which have turned out to be buggy or not up to the standard and functions I need. A total waste of money and time. As for your suggestions about re-installing an older version of Java, what would that do for the security of my computer? As for a "virtual image", I'm not sure what that mean. I'm a newbie when it comes to Java applets and programming. The same for "Signing Applets Using RSA Certificates" as rpc1 suggested. All this is new for me. I hope that I have explained the problems in a more detailed way now and loo forward to your reply.
Now, when I try to start the applet, the following message comes up:"Application blocked by Java-securityFor security reasons, applications have to fulfil the demands for security settings High or Very high or be on the list for website exceptions to be allowed to runName. embe.ts.TeamStatsPlace: file://Cause: Security settings has blocked a local application from being allowed to run."OK, I'm translating the message from Swedish. It might look a bit different in an English language browser or Java version.Ok - what is there about that message you don't understand? Your security settings need to be changed to allow it to run or you need to put the website on the exception list.As for your suggestions about re-installing an older version of Java, what would that do for the security of my computer?It would subject you to the security weaknesses those older versions of Java had. They had security issues - those issues were fixed in newer versions. If you don't care it won't matter. The exception message is trying to tell you what it would do using the current version of Java - it would subject you to security problems that have been discovered over the years that allow applets to be used to invade your computer. Again if you don't care then just modify your security settings to allow the applets to run. The same for "Signing Applets Using RSA Certificates" as rpc1 suggested. All this is new for me. And the same for that - sign the applet. If the applet isn't yours and  can't be signed then do what you have already been told to do by the exception and by other responders: 1. add your site to the exception list in your browser settings2. use an older version of Java Those are you ONLY options and there are PLENTY of sites on the web with example code that shows how to do both of those.
I've tried to add my site to the exception list in your browser settings. Didn't help! Same old message is coming up, and yes I do understand what that means. Using an older version of Java is..........something I don't want to do until I don't have any other options. I guess I have to find someone who can create a similar program for me, otherwise it's back to notebook, pencil and an old-fashioned calculator. At least they aren't any bugs or security alerts in them.

RFEs vs. Bugs

Where do you think the most of the efforts  in Mustang must be concentrated - on bugs or features? Fixed bugs make the platform more stable, but slow the progress of Java. We hear numerous requests for features, but how often do people start using new features when new release comes? What is the perfect combination of the amount of fixed bugs and features , for Mustang?
Here is my wish-list from highest to lowest priority:
1) Fix the *social* problem: better communication between Sun engineers and end-users. JavaDesktop.org discussion forums are an example of what we want more of. Ability of end-users to commit patches (for Bugs or RFEs) for Sun to include in the next release. Ability of end-users to include screenshots and other useful attachments when filing issues on BugParade.
2) JVM on-the-fly: Availability of a JVM that consists of Java Webstart and its dependencies and *nothing else*. The target size is under 2MB (10 mins of download time for dial-up users). If you have to make Webstart a native application instead of Java based, so be it. Just make this happen! As the user makes use of applications, Java Webstart downloads core classes "on the fly". The key here is that it should be possible to do the following:
I want to deploy a Java Webstart application, but not all end-users have Java installed. When someone clicks on the "Try now!" icon on the website it should do the following:
[ user clicks on icon ]
a) Check if user has Java Webstart installed, if so jump to step d
b) If not, pop up a dialog that reads: "The application you have selected requires Java Webstart to run. Please confirm that you wish to install Java Webstart and the application [OK/CANCEL]".
c) If the user clicks on OK, download and install Java Webstart
d) Download and install the JNLP application.
    The majority of the world's users are using dial-up connections. The JVM userbase is very small amongst desktop users. Getting a user to install a desktop application almost always requires him to install the JVM first (because of the small userbase) and for dial-up users this is an hour-long download which is not acceptance. Targeting desktop users is impossible without this new JVM.
3) Focus on "big picture" solutions which will allow us to reduce the turnaround time between an issue being filed and being fixed. For open-source projects the average time is approximately a month for most issues. For Sun it is 2+ years.
BTW: I want to note, Sun wouldn't need to write any special code to make this happen. There are already numerous mature issue-tracking packages out there. JIRA is one such example. I am sure you could negotiate a very nice contract with them which would benefit both your organizations. They would get amazing advertising of their product in exchange for your ability to use it, etc.
Management decisions aside, you could have this up and running within a few days and spend another week or so migrating the preexisting BugParade issues into it.

Categories

Resources