Develop Reference

Why doesn't Chrome Developer's Tools an JS Fiddle include classes and void while in the Javascript console?

I am a new developer, and usually mess around in JS Fiddle and Chrome developer tools. When looking at answers on Stack Overflow, I noticed that user started with public class and static void. Why don't I have to do this in Developer Tools?

Java and JavaScript are not the same thing.
Put simply, Java is a lower level language, designed for server side operation or operation in applets, while JavaScript was originally designed to add interactivity to websites (notably to the usually static HTML content). It has since evolved into the server-side space as well, but there's no need to confuse you with those terms right now.
Today, the two languages have no more common ground than any other two programming languages.
What you see in Dev tools is JavaScript. JS in JS Fiddle stands for "JavaScript".
It's very unlikely you're using Java in your browser, actually. Example Java apps include: Android applications, Eclipse (a code editor suite), your ATM's software, etc. Example JavaScript apps include everything you see on the web on the popular sites: whenever something animates, makes a sound, reacts to your keyboard or mouse input or shows you 3D content without loading Flash or similar plugins, you're usually dealing with JavaScript.

What is the best way to port a java desktop application to run in browser?

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

Google Web Toolkit vs Straight Javascript for reasonably large & complex application?

I've got a web conferencing client written predominantly in Java/Swing with some JNI native modules for stuff like: video, audio, and desktop sharing. In total the client is about 400k lines of Java code not including native modules.
We are investigating a long term plan for migrating away from Java/Swing and toward HTML5/Javascript for the client. As of right now, browser support is shaky/non-existent for some of our needs such voip, web cam video, and desktop sharing. So in the short term we could perhaps ship a browser plugin to do these things along with HTML5/JAvascript to do everything else.
For something of this complexity (basically a rich desktop client being ported to the web) what would make more sense: GWT (Google Web Toolkit) or straight Javascript using a JS library such as jQuery ?
EDIT: There are currently 5 developers working on this project.

If you have programmers with Java background, there are plenty of reasons why to use GWT:
powerful statically typed language also #client side
rapid development (!!!)
tools! IDEs, PMD, FindBugs and gazillion other. Also configuring Eclipse with Google plugin is just piece of cake, unlike many other frameworks.
permutations for various browsers are already handled by GWT itself
your JavaScript is optimized - handled by GWT
you STILL CAN use plain JavaScript if you want (however GWT is designed the way you don't have to)
GWT is really scalable. Your Java back-end will stay true Java, so you can use whatever favorite powerful java libraries
client side development is quite robust and Swing-like, not too hard to find a programmer to fit there
And many others. Honeslty, JavaScript is still quite slow (okay not to troll - language doesn't have "speed", but you get me). It doesn't matter if you are using jQuery or GWT. Face it, it isn't going to perform as fast as thick client. So why to sacrifice your comfort :)

Take the google wave product as an example. It was merged from plain old javascript to GWT to support more rapid development, especially considering the many developers concurrently working the project.
In my experience, manually hacking a site of what you're suggesting with jQuery would be an awful lot of work which most likely will suffer from refactoring issues, difficulty to reuse code, and probably end up with alot of code that will be really hard to grasp for any new developers coming into the team.
Don't get me wrong jQuery is really great javascript tool; but when writing complete applications in it, it quickly becomes unmanageable. That's at least my opinion.

From my experience, GWT is great for developing web applications where the intent is to mimic the look and feel of a desktop application. The fact that your team already seems to have plenty of Java/Swing experience would make this migration path easier than directly moving to a pure-JavaScript solution.
Using pure JavaScript to build a desktop-style web application, you'll be finding yourself searching for or using a lot of libraries/toolkits/plugins/widget builders (even with the use of jQuery) just in order to get the basics down. These basics can easily be provided by GWT.

What are the options for developing powerful browser hosted UI in Java?

I am interested to widen my horizons and wish to learn what are the options for developing a powerful browser hosted UI in Java. All I know is .NET based solutions, specifically Silverlight, which I find extremely powerful, although not without some regretful omissions as compared to its elder brother - WPF.
So, to rephrase my question. Are there mature Silverlight alternatives in Java?
Thanks.
P.S.
I am not starting the war of Java vs .NET, so please do not raise the benefits of Java against .NET in general. I am interested in a specific area only, anything else is put aside.
Please, do not bring Adobe AIR, flex, HTML5, etc... The questions is about Java.

The question is about Java, but front-ends for the web are almost never written in pure Java.
GWT - that's where you write pure Java which is then translated to javascript and html automatically
JSF - you reuse rich components to create your pages. Still there's html and javascript. This resembles the ASP.NET model
Vaadin - heard of it, never used it. Seems promising
ZK - Same as above.
jQuery - yes, this has nothing to do with Java, but is very powerful tool for creating rich UI
Flex - easy integration with Java back-ends. (I personally don't like Flex, but it's a viable option)
(I specifically omitted JavaFX, because in my opinion it is not yet mature)

You know, having rich applications in the browser using Java has existed since, say, 1999 : applets, that's what they're for.
They were long far from beautiful. However, with the recent apparition of JavaFX, they can now have a very nice look.

The closest thing to Silverlight in the Java world is JavaFX. I haven't worked with it myself though, and I don't think I've randomly come across any sites using it in the wild... which means your users are less likely to have whatever plugin is required... and you're likely to be cutting out most mobile users too. (I believe there's a mobile flavour of JavaFX, or at least one planned, but you really want to find out whether it exists on iPhone/Android/(whatever your target market is).
Personally I would probably try to stick to HTML 5 and JavaScript, which can still be pretty rich. (That doesn't necessarily mean writing all the UI by hand, of course - projects like GWT and jQuery are your friends.)

Open Laszlo is worth a look they have a nice interactive demo section too.
The OpenLaszlo platform consists of the LZX programming language and the OpenLaszlo Server:
LZX is an XML and JavaScript description language similar in spirit to XUL, MXML, and XAML. LZX enables a declarative, text-based development process that supports rapid prototyping and software development best practices. It is designed to be familiar to traditional web application developers who are familiar with HTML and Javascript.
The OpenLaszlo Server is a Java servlet that compiles LZX applications into executable binaries for targeted run-time environments.

I'm not sure if it fits your demand but have you looked at the Google Web Toolkit? It compiles Java to javascript and some colleges have made nice UI's with it.

I've used GWT before and more recently Vaadin which I would recommend. You can give it a go at a demo sampler here. I am currently using it to create custom portlets for the Liferay CMS/Portal and I am pretty happy with it.

Client Java vs (Adobe) Flash for web applications, what to choose and when

A few years ago client Java was unsuitable for web development because a remarkable part of web users did not have Java installed. ( I don't remember exact numbers, more than 10%).
Now I see the Google Analytics stats for a big site and it tells that >98% of users have Java installed.
Is these stats very biased by Javascript usage? As I understand Google Analytics measure only users that has Javascript.
Is the picture similar on other big sites?
Does client Java have really "stopper" drawbacks compared to Flash?
EDIT: I mean java applets mainly, java WebStart seems to be not suitable for average user.
I mention Javascript only to describe the way Google Analytics works.

When I wrote my diploma project, I had to choose between Flash and Java Applets. Here are some pros and cons:
Java Applets:
[plus] you program in Java, which is mature and stable
[plus] you can use the Java GUI frameworks that pack a lot of punch
[minus] the first time the user hits the page with the applet, the JVM must be initialized and this can take up to a few minutes even on a fast computer
[minus] Applets are not meant to be used as animation media; sure, you can do stuff, but it is like programming in C - you do everything from scratch
example: i needed to show a data packet as it moved between two routers. The packet must be a control of some sort, like a button or smth. This animation can be defined in 1 line of code in Flash, where all objects derive from some base object that can be animated. I could not find a suitable solution in Java.
Flash:
[plus] really really focused on animations;
[plus] ActionScript is actually an OO language
[minus] ActionScript is sloppy, bughish and has only a few supporters. If you are stuck, be prepared to search obscure Japanese forums for solutions
[minus] ActionSCript may be OO, but it lacks a lot of features, like Enums, fully fledged interfaces, threads (!!!!) etc.
[minus] Flash was designed to be used by non-tech people - they just use the authoring tool; I wrote code for everything and it worked, but it was a pain.
My conclusion:
I eagerly await a programming paradigm for animations and rich client interfaces.
ps: Silverlight seems to be a disappointment so far, maybe Microsoft will inject some $ into it.

Mmm, Java seems to be better supported than I though, I searched some stats and found between 92 and 96% of browsers support Java (ie. it is enabled enough to detect it! although I guess lot of Java detection algorithms use JavaScript to detect & report - as you point out - but JS support is very good too anyway, even more in our Web 2.0 era).
Adobe boasts better support, but overall the difference is rather marginal. Anyway, somebody really wanting to see/use the application will activate/upgrade/download the needed engine.
Now, we have to see what JRE is supported! Alas, I didn't found any stat for that.
There, Adobe have an edge: not everybody have Flash 9 or 10, but upgrading is quite fast. While downloading and installing a new JRE is quite a bigger task... Of course, you can target the historical lowest common denominator Java 1.1, or more realistically Java 2 (1.4), but it is still frustrating not to be able to use all 1.6 features...
I have seen some people complaining that Java applets crashes their browser (apparently on Unix systems) but it is more an issue with a minor number of browsers/systems than anything else.
And as pointed out, startup time of a Java applet is quite longer than for Flash (although some big Flash games are slow to load too).
Now, I have seen a number of Processing applets, like the notorious Webpages as graphs, most of them load quickly: lot of the power is already on the hard disk of the user, in the extensive Java library. Processing generates quite lightweight jars, while lot of Flash applets must include foreign libraries... or reinvent the wheel!

Some previous postings are obsolete in regard to comments on ActionScript. ActionScript3. became available in the Flex 2 time frame, i.e., January 2007 when Flex 2.0 and Flash player 9 shipped.
AS3 is a full blown OOP programming language comparable to Java. It has classes and interfaces, inheritance, access protection keywords for class members, constructors, statics, plus some nice things that Java doesn't have: properties, events, declarative data-binding, and closures.
By default AS3 is statically compiled, hence one declares the type of members and variables. This can be relaxed to where AS3 can revert back to dynamic typing ala JavaScript. It is less efficient at runtime, though. Sometimes when dealing dynamic data it is none-the-less useful to selectively employ dynamic classes. (A nice benefit of static type checked language is code completion in the Flex Builder IDE.)
Much of Flex development is accomplished using MXML. This is a declarative XML-based DSL for Flex. MXML gets compiled into ActionScript3 code, though. So what you do in MXML is equivalent to AS3 imperative coding, but can often be more concise, clearer, and more appropriately structured with respect to the underlying graphical Flex form it represents (i.e., MXML is good for coding the views of the MVC pattern).
The bottom line is that ActionScript3 programming of Flex is easy and natural for a Java or C# programmer to learn. The language is not at all the issue. The power of Flex comes in becoming intimate with the Flex SDK and the myriad capabilities found there.

Not an exact answer, as it would be very opinionated, just sharing my experience...
In a recent project, where we were building a WAI compliant site, we were asked to avoid flash objects as accessiblity was a major issue. Applets on a different note don't go very well with most web developers ;). One reason might be the differences in the paradigms of Rich UI vs. web UI.
However, we found applets to be irreplaceable (not speaking for .NET and ActiveX controls) when client side monitoring was needed. The application uses SmartCard based authentication and applets are loaded into browser to listen for client side events (card removal) and alert the server to end session.
In this context I tend to feel that Flash is meant to be eye candy (view) where as applet though designed to be versatile, takes the role of model on client side. It is to be noted that both applets and flash consume CPU cycles on client machine, hence were traditionally suited for tasks involving lengthy computation. Calculators, Report generators, Trend illustrators, Astrological chart generators (yes) and other tasks where data can be fed by user and are results shown immediately make use of these.
A major concern involves lack of client side software (Java, flash plugins). The user experience in such cases is more than annoying.

Noticed some comments about java not updating itself. Now 1.6.0_10 is out, and it's updating itself more easily and automated than before, and you have the option of a new install method, the java kernel one. This automates the install of java components as you need them.
Some text about this: http://java.sun.com/javase/6/6u10faq.jsp
So there are changes, Sun just wakes up with the new Ceo i think. I know it's 1-2 years until this new system propagates but you can start your project and have fun when it's ready maybe. :) Who knows.
Anyway, maybe you work +500% for easy animated features than flash, but if your app is not a simple animation, then you work +500% with flash for some simple 3 line java code substitution :) Depends on your app.

I worked in Java for the last 7 years, and then I recently started on AS3 on my newest project (1.5 years and going). I love AS3 and Flash, and here's why:
The language itself is very similar to Java. The documentation at Adobe is as good or better than JavaDocs.
The AS3 language supports XML as a native type. Parsing XML in Java is a nightmare.
There are nice animation and graphics frameworks for Flash, such as papervision 3D and tweener.
If you use the Flex 3 framework and Flex Builder 3, building interfaces that look as good or better than Swing is trivial. I loved writing UIs in Swing, but designing UIs in the visual Flex Designer is like a breath of fresh air.
I'm pretty sure that there's more browser support for Flash.
Have you ever seen a Flash applet load? It has really poor usability, and makes your user click through two or three dialogs before the applet starts. Flash apps just work.
Good luck on your project!