Just out of curiosity, between <applet> vs <object> for a Java applet, which one should I use? I know that <applet> is deprecated, however Sun still recommends the use of <applet>.
Is there any drawback between the two tags? Because when I use <object> for Mac in Safari, it causes a problem saying that the page can't load, even though the page loaded properly, and when I check the activity window it said that the class was not found/cancelled. For example:
Use applet if you have found that it works more often. The object element was introduced as a theoretical unification that would be a catch-all for any embedding of external data. It never worked well, and modern HTML development has effectively abandoned the unification idea. HTML5 introduces audio and video, for example and keeps img (logical unification would surely deprecate img, because an image can be embedded with object).
Use deployJava.js as mentioned in the applet info. page..
..To avoid browser compatibility issues, the Deployment Toolkit script provides JavaScript functions that automatically generate the HTML required to deploy RIAs. Developers should invoke these functions to deploy their solutions in a consistent fashion across various browsers.
Then you don't have worry about whether the script writes an applet, object or embed element.
As an aside. Copy/pasting the text from the Activity window would be a lot more useful than a screen-shot. Now I look (squint) at it, it seems the only two lines of output that are in any way relevant are:
http://admin.file-lift.com/css/none not found
http://admin.file-lift.com/com.pspinc.util.FileUploaderApplet.class cancelled
The css/none is not a class or a Jar, and neither of them exist on the server. So that applet has problems beyond the HTML elements used to deploy it.
Use <object>. <applet> was deprecated back in HTML 4.01.
Unless you're targeting a stone-age environment, there is not reason to acknowledge the existence of the applet tag.
I think Sun has a point. HTML5 says:
The applet element is now obsoleted so that all extension frameworks
(Java, .NET, Flash, etc) are handled in a consistent manner.
In other words, it's no longer valid for reasons of theoretical purity and not because of any practical problem. Frankly, I find <applet> simpler and more reliable to use in the real world and continue to use it.
While deployJava.js might hide the gory details away, the reality is that under the hood, it still uses <applet> in some circumstances.
Related
I'm a pretty skilled java programmer that has dabbled in web development but I find that I'm much better at doing desktop based stuff than I am at anything related to web development. I've been trying to find an easy way of porting some of my desktop apps to run in browser but can't seem to find anything. I guess what I'm looking for is something similar to an applet but they a largely unsupported and get more buggy by the day. Is there anything similar that would allow me to keep my desktop style mindset and still run in browser or should I just break down and rewrite the whole thing in rails or another common web platform.
Java WebStart has been mentioned by others - It's a technology that aids redistribution of Java applications that then have the full rights of desktop applications, but they also have auto-update support built in. It's basically a launcher that fetches a JAR from the internet and runs it as a desktop application. These don't run within the browser.
Applets are an old technology that can be embedded directly into the web-page. They are not buggy, but they have several security restrictions. Also, the support is steadily declining because of the amount of critical bugs found in the technology. Desktop users that want applet support typically don't have trouble ensuring it, however. Currently, both the Chrome and the Java platform itself issue a warning before an applet is allowed to run - and that assumes the Java Runtime Environment is already installed.
Google Web Toolkit is a framework that allows creating single-page applications in Java, which are then compiled to Javascript. GWT handles multiple things behind the scenes, including server-client communication, localisation and internationalisation, and its own layout engine.
When translating an existing application to GWT, you need to:
separate the code into a part that runs on the client and a part that runs on the server. The server does not have direct access to the user, and the client does not have direct access to the database. If your application does not use centralised storage, it probably can run entirely within the web browser. Since client-server communication happens over the internet, you should reduce it to the minimum.
translate the front-end to GWT widgets. Forget Swing or AWT - they are impossible to compile efficiently to Javascript.
remove dependency on other Java classes that the GWT does not know how to translate into Javascript in the client part of the application. A large part of java.util. is supported but none of javax. (as of Jan 2014). The GWT site hosts the list of supported Java classes. Also, Javascript's regexes are less powerful than those of Java. Lookbehinds, in particular, are not supported. The server-side is a full-blown Java environment, but remember - you want to reduce the server-client communication to the minimum.
But, the most common strategy is to code the client side directly in Javascript.
Javascript is a language very similar in syntax to C/C++ and Java. It uses curly braces to denote blocks of code, and it uses semicolons to separate statements (though Javascript features automatic semicolon insertion, sometimes it understands two lines as a single statement if the first line is not terminated by a semicolon. Its data types include numbers (double-precision floating point), strings, booleans, two types of null, plain objects (which are basically hash-maps [string -> x]), arrays (untyped and dynamically extensible), regexes and functions (named or anonymous), all of which have their own literal syntax.
When coding in Javascript, your mindset should be:
Javascript is single-threaded and event-driven. You don't have to worry about concurrency issues, but you cannot say "now wait for x" either. Since Your Java code should be event-driven as well, this should not be an issue.
Lots of things in Javascript are asynchronous. Want to know something from the user? You should paint a dialog, and attach event handlers to its components. Want to get the user's GPS position? Ask for permission, passing it an event handler for when the user decides if the permission should be granted, from which you ask for the position, which also takes an event handler as an argument. Talking to the server? Asynchronous. Do you want to display something before doing a long calculation? You have to actually wait a little before you start computing. Ecmascript 6 improves the syntax a lot, but it's not yet supported in modern browsers.
Browsers only let you do so much. Disk access? Only to a file or folder the user explicitly points to. Clipboard access? The only reliable way is copy/paste into a textbox. Talking to a foreign webserver? Only if that webserver explicitly lets you (and lot of them don't even know how to). Of course, "foreign" includes a different sub-domain, different port number or a different protocol (http:// or https://). Desktop notifications? Geolocation? Ask for permissions first. Java applets have comparable security restrictions, and for the very same reason.
In Java, everything is a class. In Javascript, you can enjoy bare functions without any class. A typical event handler is just an anonymous function that you pass as an argument to a library function. Also, you can have anonymous objects using a very conscise syntax. This makes Javascript code much denser than that of Java and with very few classes, if any. Object Oriented Programming is still possible in Javascript, but much less pronounced.
When layouting your display, you need to think in terms of HTML and CSS. The best approach is to modify only the document structure (adding/removing elements or HTML classes) using the Document Object Model (DOM), and leave all CSS in an external file. In any case, you need to know CSS enough to be able to layout your page. Modern browsers support canvas, but it has no built-in layouting engine - its closest Java relative is JCanvas - just a blank area where you can draw graphics primitives - or a WebGL canvas - where you can place triangles in a 3D space.
When designing your own API, you need to know which operations might need to be asynchronous. If they are, either take a function as an argument (a callback), or return an object that does (a promise).
Except for the this variable, Javascript is function-scoped and lexically scoped and has closures. If a variable exists in a surrounding scope, it can be read from and written to - even from within a function that is only defined in that scope and called much later. In Java, you can't close over non-final function-local variables.
However, you need to be careful about timing - don't think you can just assign to a variable within a callback and use it outside. When you try to use it, it won't have been assigned to yet. Many have tried to cheat the time this way, and failed.
When the user leaves your page, it's a game over. If you want to remember anything past that point, you need to store it somewhere, be it cookies (very little space, outdated API), localStorage (decent amount of space, not supported by very old browsers) or the server (lots of space, but talking to the server when your page is being shut down is tricky).
the DOM API is often criticised, but there are several frameworks and libraries that ease the usage of it, of which the most popular is jQuery, which also handles browser inconsistencies, improves the AJAX API, event delegation (you can't attach an event handler to an element that doesn't yet exist) and includes an animation engine (though modern CSS is almost as powerful and often easier to use).
I think java web start could help you
http://www.java.com/it/download/faq/java_webstart.xml
I suggest you to take a look at Java Web Start. It offers you a possibility to start your application software for the Java Platform directly from the Internet using a web browser.
For more details see: Java Web Start
Nowadays Web Start is not a good option since, the user needs to have JVM installed and with all the vulnerabilities buzz around Java is more difficult to convince users to download it. The latest versions of JDK 1.8+ include scripts to pack your application along the jvm runtime in just one installer: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/
For using your application in a browser like an applet, you can use Bck2Brwsr or TeaVM both can run java applications in a browser without Java Plugin. Bck2Brwsr also uses Java Plug in if it is available.
You can also use GWT to compile your Java application to JavaScript. Note: Swing is not supported.
Regards
Most browsers allow extensions for them. But, as I understand, there separate extensions needed for different browsers.
Is there any way to write one extension for all browsers? Can such thing be created Java, .NET, or Python?
In my opinion you can use Crossrider, with Crossrider you will write one JavaScript code, that will produce an Chrome,Firefox and Internet Explorer compatible extension.
Crossrider have a powerful API that hide all complexity while writing cross-browser code.
Try to give it a shot in: http://www.crossrider.com
Disclaimer: I worked at Crossrider
It depends what your extension does. Theoretically if your extension is quite simple (e.g. it doesn't require any special APIs like http, or filesystem access and it doesn't modify browser layout), than theoretically you can reuse the same code between browsers (but since each browser has its own extension format, you must create descriptors/browser specific code for each extension). Writing extensions in language other than javascript is possible by using some Name our language to JS compiler. For example SpeedTracer for Chrome is partially written in GWT (Java to JavaScript compiler).
So in short, you can reuse the same code between extensions for different browsers and you can use languages other than javascript to create browser extensions.
I am using GWT/Spring to develop web applications. currently my appln supports only IE7. it also supports other browsers like firefox. but alignments are changed across the browsers. how can make the web application view is same in all the browsers? PLease help me.
Thanks!
There is no silver bullet in terms of cross browser compatibility. This is a huge area and highly dependent on the specific HTML and CSS you developed for your application. Going for that "pixel perfect" compatibility can easily eat up hours and hours in tweaking and is often not worth the effort. Like Piyush mentioned, it might be more productive to make sure your site looks nice (not broken layout) in the browsers you are looking to support rather than trying to make it look identical everywhere.
Best advice I can give you is to adhere to HTML standards (which tags can be nested inside which etc), use CSS for styling, don't over-use tables unless you absolutely have to and don't create layouts that will break if one element is a pixel off (like moving a an inline div to a new line just because it rendered 101 pixels wide instead of 100).
EDIT: this is a very useful little javascript library I have used on several occasions, http://rafael.adm.br/css_browser_selector/. What it does is to add classes to your <html> element based on the browser. That way, you can create specific CSS to target a single (or family) of browsers for those exceptional cases where you have to go in and style specifically for one browser.
I also have a GWT-Spring application . I use EXT-GWT - GXT from Sencha . GWT basically compiles the components for different browsers .
The
<module>
<set-property name="user.agent" value="gecko1_8,ie6" />
</module>
compiles the code for different browsers . But as is common with all apps , We use different css for different browsers and tweak these as necessary . There are quite few javascript libraries that would help you but you may come across integration issues with GWT .
Dojo is a nice UI library to look at...
Although, JQuery is more known for its browser support, dojo is much simpler.
But in general, there is no method without hardcoding for each browser to display things exactly the same. The point in browser support is to have a nice interface for all browsers rather than the exact same interface. In General, you will be fine as long as you use a strict HTML standard.
Hope this Helps
JQuery might be helpful for you, but remember 100% cross browser support without some dirty tweaking is really hard to achieve..
this is a nice link for cross browser jQuery support
I've read a bit on client-side browser languages and tried a few out but I'm not convinced I know of all the options. To make it clear, I'm looking for something that can be processed either through the browser or otherwise on the clients computer with minimal need for additional installations/configurations.
At the moment I know of JavaScript, Java, and Flash ( I'm aware this isn't actually a language, but seems pertinent to mention it still as an option). If at all possible it seems like avoiding Flash would be best, but it's still a consideration. I know there are various flavors of JS and Java but I don't really know of any that make the end-product that different than just the raw language. Java and JavaScript both seem relatively slow when it comes down to more complex and weighty apps, though performance is always improving as our browsers and libraries get better.
All this said, is there anything available or about to be available that will do things better?
JavaScript is the only native browser language that’s widely supported. Flash isn’t native, but it’s the most widely-supported plug-in.
Nothing else yet seems to be installed widely enough to be worth considering in general, although obviously you should always try to figure out what the actual/intended audience of your specific project has installed.
JavaScript performance has come on leaps and bounds in the latest versions of all browsers as it’s become more widely used.
As far as interface programming goes, the only thing JavaScript has built in is the DOM interface, which lets you programmatically control the HTML page that the JavaScript is running on. The DOM interface is pretty raw and basic, so there are lots of frameworks that try to make it more palatable (like jQuery), and frameworks that seek to provide libraries of desktop-like UI controls (e.g. jQuery UI, Cappucino).
JavaScript is the main language for client-side browser development that interacts with the elements on the page, does ajax requests (update screen without a full page refresh), etc. Depending on your specific requirements, I would recommend JavaScript, as its most likely the tool that will accomplish your needs.
Java is NOT a client-side browser language, Java is a programming language, you can write apps in Java and embed them in a website, that is called a Java Applet. This will require that all users have a JRE installed on their machine for your applet to work.
Java has nothing to do with Javascript -- they share some similar syntax, and thats about it.
Flash is a browser plugin, if you want to write a flash application, ActionScript is the language it uses. It still requires that anyone going to view your application have the Flash plugin installed.
HTML5 is the future.
Currently many features are achieved with JavaScript, but these are being wrapped in libraries (e.g. the "polyfill" library Modernizer and even in other languages, e.g. Java with GWT. This is an area in a greater state of flux than most.
You forgot unity.
Unity is an up-coming client-side application development platform. It does require installing just like flash but it's a lot more powerful then flash and seems to be picking up popularity.
Unity has a lot more inbuild framework rather then doing it in HTML5+JavaScript. I would say these are your two main options. For an example of javascript & html5 in action look at cloud9ide
One of the big advantages of unity is the 3D engines.
Java applets are so 1998 and are not an option.
My understanding is that APPLET is deprecated and OBJECT is the preferred tag to use for Java applets. Is this correct? A lot of Java applet examples, both on the web and in books, still seem to use the APPLET tag.
Are there any browser compatibility issues that OBJECT suffers from (compared to APPLET)?
Also, can you provide an example of proper OBJECT tag usage for Java applets?
Here is your best bet. And here are the examples for all tags.