We Keep Coding

Java single code base for desktop and mobile

Is there one or several java based technology that can help me write an application code base once (including Logic-Views-Controllers) and then compile and run it for
all platforms including main desktop and mobile operating systems as well as
in the browser. It must work and save in offline mode too so that it could sync with remote server as soon as it is connected to the internet. To me, it seems there must be a way if I use some sort of html/css/js technology to handle my views for such an application since I don't need fancy operating system dependent view technologies, and java for Logic and controllers. So far I have found Oracle ADF Mobile which seems to be commercial, eclipse RAP, eclipse scout .... But I look for something that covers Desktop as well. In addition if I can make the application run only in web browser, in case it would run and save in offline mode, it would be fine enough for me.

You could use Eclipse Scout for this with the following setup/limitations:
Since June 2016 Scout only supports web UIs (until 2015 Scout also had support for Swing/SWT, but this is gone now)
You would need to run the Scout frontend model part in a local Tomcat
or similar
You would need to add the sync code for connecting the Scout frontend
model with the Scout backend (that would sync data once a client installation gets online)
Asking for a mobile solution in combination with Java will most likely put you in a messy situation, especially with the discontinuation of RoboVM
Hint: The Scout team has started working on JS offline capability of the Scout UI. However, this is effort is still many months away from production quality (many parts/concepts still missing, not all parts open source, no documentation, etc.)
Addition: You will have the same limitations with Eclipse RAP (needs a frontend server, only web based, hint: styling rap apps is hard).

Looking for the silver bullet... Beware that "not caring about something" (the OS) will make you care a lot about a framework that does the "dirty work".
Leaving opinions aside, in 2016 you will reach your goal quicker with JavaScript, it has become the only thing supported everywhere.
It may be a good deal if you're OK with JS, and living on the bleeding edge with heterogeneous / less mature tooling (see NPM gate).
Java in the browser (applets) is dying soon due to its well documented security issues. One could argue it's been dead for a long time.
If you do want to code in Java only, GWT is still alive. It compiles your Java code into highly efficient JavaScript.
However, ever since Google reduced its involvement by giving away the project to a steering committee, the developments have slowed down drastically, and I'm not even sure they are up to date with JDK 8 yet.
Google still uses GWT in projects like inbox, for what it's worth.

I would go with GWT.
Google also uses this for projects like the inbox webapp, and the inbox android app. Using GWT a lot of code between the two apps can be shared.
It is also possible to compile as a windows desktop application.

Options to re-using an Applet's existing code?

After five and a half years full-time work on a product ranking engine project, which revolves around a 64,839 line applet, the browser companies have seen fit to dump applets.
At this point I am in no position to convert the applet to another language (unless I get a huge injection of funds to hire a team of programmers). My partner is not going to support me for another two years.
I know the questions are rather vague and I should be keeping up with the latest tech, however I've had chronic earaches for 14 years that affect memory and concentration, so programming is difficult enough without trying to keep up with the latest developments in software as well. The reason I am asking for advice is that I don't want to make another monumental screw up.
Question 1: My understanding is that Java Web Start launches the application, but it then cannot communicate back to the JSF web page any more (JSF2.0). Is there any way of getting around this?
Question 2: Can anyone suggest any other options other than re-coding the whole thing?
Question 3: Is it likely that applets will be altered to use the latest plugin format or are they gone for good? Does anyone have any inside information on this?
Overview of the applet's requirements:
The applet allows a user to customise some or all of the product ranking criteria, which has been preset by a panel of knowledgeable experts, to their own particular needs. The criteria is stored and edited via graphs (custom painted jPanels).
The ranking criteria can be altered entirely using the mouse (to change the graph shapes), though some values can be entered using the keyboard if the user wishes. Once customised, the applet is then used to submit the changes to the ranking engine server.
It is also used to allow third party experts to alter the ranking criteria to create their own product usage category ranking criteria. The third party expert can then place links on their own web site that will allow users to rank products using the third party expert's own ranking criteria. This allows anyone to create their own ranking criteria for use by others.
The applet uses a plugin bean that is also used in a standalone Java editor application, which is used to create a product usage ranking criteria file from scratch (the editor is 77,710 lines of code, though 61,257 lines of that is the plugin which is also used in the applet). This means most likely having to convert the editor as well, as the two are inextricably linked. The plugin basically is the applet and also the editor.
The plugin can capture, edit and store ranking criteria for virtually anything the human brain can rank. Thanks to the graphs, it can use any attribute that the brain uses, and for which we have no formal system of measurement; hence why the applet is so damn big.

Your question is probably too broad for Stack Overflow, but I'll give a brief response.
Java Web Start
Java Web Start is probably the best route for you. This technology is basically a convenient way for a user to obtain, install, and run a Java desktop app. The web browser is only used to initially download a small XML file describing your app and where to get the app. The Java Network Launching Protocol (JNLP) defines these pieces of information stored in that XML file. Your app will be downloaded from a server, and saved to the local machine. A Java Runtime Environment (JRE) can be downloaded and installed if need be as part of the process.
By default the app runs within a security sandbox similar to Java Applets. But you can sign your app and define security protocols to break out of some of those restrictions including making network connections.
The bulk of your programming would remain intact. The app is still pure Java, running in a JVM. You would need to do a bit of reprogramming to be a desktop app rather than packaged as an Applet. And you would have to learn about easing those sandbox restrictions. And your app will have a menu bar of its own as a full-fledged app, so you may want to take advantage of that. But the guts of your app would remain the same.
Over the years, Sun & Oracle have put efforts into improving Java Web Start. Unfortunately it came too late after Java-on-the-desktop had lost too much mind-share. And Swing never got the overhaul it so desperately needed. So Java Web Start never went big-time. But Java Web Start does work as advertised, so give it a try.
While there were some security issues years ago, I believe they have been resolved long ago. The many infamous security problems with Java were largely involving the web browser plugins bridging between browsers and the Java JRE; those problems do not affect Java Web Start (though you should do your own research to confirm).
For the general public, Java Web Start may be too much to ask of new, anonymous, and less-motivated users. For a commercial product with a user-base of eager customers, it may the perfect solution for you. I suggest you do some more study, read the Wikipedia page, study the Oracle technology page, look at the Tutorial, read this overview by John Zukowski that includes an example of network (making socket connection to time.nist.gov), and so on.
Vaadin
The Vaadin framework is an open-source free-of-cost professional user-interface development framework that uses pure Java to run your app on a server in a Java Servlet web container while automatically generating a user-interface using standard web technologies (HTTP, HTML, CSS, JavaScript, GWT, WebSocket, etc.) for presentation within a regular web browser (Firefox, Chrome, Safari, IE, Edge, etc.). As a graybeard, I think of Vaadin as an X Window System for the new millennium: The user interacts with screen widgets on their local computer but the business logic of the app is executing on the server, and the server is updating the remote UI as a result of that business logic executing.
Vaadin is not yet-another-web-templating system. Instead, your app is written in pure Java. No need for you to learn the alphabet-soup of web technologies listed above. Vaadin takes care of that for you, auto-magically. You say in Java “I want a label, then a field, and a button” and Vaadin makes those appear in the web browser.
Using Vaadin would allow you to retain your Java code for the business logic part. But you would need to re-write the user-interface parts to use Vaadin widgets instead of Swing widgets. This would not be so terribly difficult as Vaadin was inspired by the general style of Swing, defining layouts governed by layout managers in which you place your various widgets (fields, labels, buttons, etc.).
Vaadin can make very professional business-oriented apps that feel almost like desktop business apps. Tip: I prefer the Reindeer theme for business apps over the newer Valo theme.
But you mentioned some kind of free-form drawing canvas in your Swing applet. That may be a sticking point. I do not know of such a widget for use within a Vaadin app. I am not saying there is no such thing, I just do not know of any. There are slider widgets that may useful, but I don't clearly understand your needs in that regard.

experience with Vaadin touchkit

I´m soon to start a new mobile app project and I dont have that much experience with either iOS or Android development but I have used Vaadin for presentation tier on different occasions.
The app will most likely be lightweight for the mobile client but more heavy for backend servers(jboss). I feel kinda lost so i´m asking you.
Question: What are the drawbacks of using Vaadin touchkit compared to other frameworks/ build from scratch? Where might a problem occur? Any input and recommendations are welcome!

I am currently developing a small application using Vaadin TouchKit that once it enters production will have some hundreds of users. I haven't been able to locate any publicly available apps in production that have been implemented using Vaadin Touchkit, so what I'm going to list here is based solely on my personal experience with the technology.
Drawbacks compared to native applications:
I'm assuming this is what you refer by "building from scratch".
As this is web techonology, your application performance will always correlate heavily with the quality of the users Internet connection. If you have to render large UI's with a lot of components and details, it will be slower than doing so in a native application. A lot slower if the users connection is poor. Or if a connection is unavailable, then your application pretty much becomes unavailable. There is a way to use HTML5-cache for providing an offline-mode in a Vaadin Touchkit app, but it is not very useful for storing large datasets as the cache has a lot more limitations than for example an Android SQLite database. For simple UI-stuff it might be viable, but storing data for offline-access is in my opinion pretty much out of the question.
Other than the above mentioned points, I have not run into any missing capability, as you can use any Java library at any time on the server-side, and your application will be running safely in a servlet container.
Upsides compared to native applications:
You didn't spesifically ask for the upsides, but I guess this is any input and recommendations.
Your Vaadin Touchkit app can run on basically any mid-high tier mobile device launched after 2010, basically excluding only the ones with Windows Phone OS, since Internet Explorer does not use WebKit for rendering and other browsers are not available as far as I know. And since this is a web application, it does not exclude any other desktop browsers than Internet Explorer. By creating one application, you support roughly 80-95% of your users.
As mentioned, any Java library, any internal API, any authentication method supported by your hosting environment is available to your app, which is not as easy to implement for native mobile applications. This can be overcome with great software engineering, but demands a significantly higher amount of developer resources, not to mention that you are still stuck doing it for each platform separately.
And of course maintenance of a servlet app compared to the maintenance of a native application is considerably more simple: deploy once, all users get the changes without doing anything. No app store, no versioning, no hassle.
Vaadin TouchKit compared to other web development:
I am not familiar, at all, with web application development without using Vaadin, so I am not going to tell you whether or not it is the way to go compared to other modern web application technologies and frameworks. All I'll say is that in my experience Vaadin makes creating UI's and backend functionality relevantly easy and more graspable if you are familiar with Java development and desktop application development in general.
To conclude, don't rush in to create your mission critical application using Vaadin TouchKit before at least prototyping with it, and getting to know the performance and limitations it presents. For certain type of applications, it might be one of the best solutions. For a certain, larger group than the other, it is probably one of the worst. It is not a very mature or generally adopted framework, but it is useful. I'll be happy to hear more about the type of app you're planning and help you figure out if there are any showstoppers for using Vaadin TouchKit.
P.S. You've probably already run into this, but this document opens up the guts of one of the TouchKit demo apps:
http://demo.vaadin.com/vornitologist/VAADIN/tutorial/touchkit-tutorial.html

I just tried out vaadin touchkit examples on my android phones, well now I got affirmation why I prefer native software over html in some cases. Try it out - dont be confused by nice-looking styles, just try to USE it, this is what apps are made for. In my case I cannot withstand non responsive GUI or not smoothly scrolling lists. Again, for a simple gallery - a JavaScript/HTML solution is just perfect :) So the right way is the hybrid way! (imho)

Vaadin Touchkit offers very good user experience and provides wide range of UI components to apps.
Its default iOS theme provide almost iOS like UI and it also offers many other themes too.
But this will not run as smooth as platform specific mobile apps. as ultimately it will not completely leverage the real power of mobile platform features as finally it is going to run in a mobile web browser. as compared to native mobile apps
Find more detail on vaadin touchkit and comparison with similar technogies like ZK Mobile and native platform specific apps. : http://jtechnoprojects.blogspot.in/2012/12/vaadin-touchkit-vs-zk-mobile-vs.html

Developing traditional style webapps with GWT

In many JVM web frameworks survies and Indeed.com trends graphs, GWT looks to be the most (or among the top) popular JVM framework.
But AFAIK, GWT excels when the application is one page app -to some degree of course- (like GMail, Google Reader ..)
Does this mean that new developed Java webapps are one page apps mainly (not traditional request-new page response)?
Is it possible to develop SpringMVC or Struts2 style webapps with GWT? or it is not recommended?

Absolutely, it is definitely possible to build struts apps with GWT; at some level all the GWT is, is a convenient way of writing javascript (in my perl days, we called it 'syntactic sugar').
You can still use GWT-RPC, JSON, or HTML forms to communicate with the server.
You can attach to any arbitrary HTML element using RootPanel.get("id"); to add javascript widgets.
Almost every javascripty component on my employer's website is written in GWT: http://www.cohomefinder.com/ . The backend is an old fork of struts.
And here's a nice, though a bit dated, article about building 'normal' websites in GWT: http://www.canoo.com/blog/2007/03/13/building-a-regular-website-with-the-google-web-toolkit/
I'm not sure, however, that this use of GWT is where it really shines. One downside is a lot of javascript parsing on every page load. Code splitting can help with that, some.

Best server-side framework for heavy AJAX Java application

There are zillions of Java web application frameworks.
95% were designed before the modern era of AJAX/DHTML-based development, and that means these new methods are grafted on rather than designed in.
Has any framework been built from the ground up with e.g. GWT + Extjs in mind?
If not, which framework has adapted best to the world of forms with dynamic numbers of fields and pages that morph client-side?

Echo2 / Echo3 by Nextapp (www.nextapp.com) is totally awesome.
Advantages over GWT:
1) It is not limited to a sub-set of java like GWT
2) It is easier (in my estimation) to learn
3) Has extremely robust design studio for almost drag and drop designing.
4) It is very fast, and works very well on all platforms browsers
5) You can write your application using either java script or java
6) It has great and straight forward methods for handling events and actions.
Personally I think that for any web-application in which you are trying to integrate java and speedy delivery I wouldn't hesitate to pick Echo3 or Echo2.

If you're starting from scratch. I'd have to say Google Web Toolkit. I have to say it is incredibly powerful. You get keep using most of your Java tools. Plus, you don't have to duplicate code that exists on both the server and the client, it just gets compiled differently for each area.

I'd consider REST-style frameworks as well as the other recommendations here- Restlet or Jersey may be good choices for the backend, while you use something like JQuery or GWT on the front end. Both frameworks can easily produce JSON, and the REST style provides a nice clean line of demarcation between your client application and your server source; I find that JSF can make that demarcation pretty muddy.

I use JSF and IceFaces. Although JSF has a few limitations, IceFaces seems to work pretty well and has ironed out a few of the problems with JSF.
I haven't used a really good AJAX Java framework as yet, although Echo2 looks interesting.

I like the stripes framework. It lets you use whatever javascript toolkit you want.
Here is their documentation on AJAX

GWT is quite powerful and easy to use (all Java, no Javascript/HTML/CSS coding). If Google has their way it will be a dominant framework/tool in web applications development, and for good reason. It already works with Google Gears (which allows offline access to web apps) - and more than likely will be optimized to work within Google Chrome.

DWR
I use this to dynamically populate drop downs, and even filter them on the fly based on user input in other places on the form.

I like the combination of JBoss Seam and Richfaces, especially with the JBoss tools that are extentions to Eclipse - makes building these sort of RIA's incredibly easy.
Wikipedia contains some useful comparisons:
Comparison of JavaScript frameworks
List of AJAX Frameworks
Your choice depends on several different factors including whether you want the "work" done client-side (most javascript frameworks) or server-side (echo2 etc.). Other things worth looking at are tools like OpenLaszlo that provide Flash (I think) out of the box, but drop back to DHTML if there is no Flash player present.
Unfortunately I think the decision comes down to balancing several competing cocerns. Check out the comparisons and try them out - most come with online demo's for you to try.

Aptana has a server side frame work called Jaxer. This is from their site:
Jaxer's core engine is based on the same Mozilla engine that you'll find in the popular Mozilla Firefox browser. This means that the execution environment you use on both the client and the server are the same. It's Ajax all the way through and through. That means you only need one set of languages -- the languages that are native to the browser -- to create entire applications.
This framework is open source and has a very nice IDE based on Eclipse. Aptana is also working on a Javascript implementation for ActiveRecord called ActiveRecordJS. Potentially you could use this both client and server side with their framework.

GWT is one of the best AJAX framework that I used ever. Most important thing about this framework is that its maintained by Google. And Everyone know "Who is Google ?"
GWT is used by many products at Google, including Google AdWords and Google
Wallet. It's open source, completely free, and used by thousands of
enthusiastic developers around the world.
GWT provide rich widgets that can be used to built any application. Almost all the widgets they have.
Another important point is GWT is continuously developing and its also have stable release which is very good thing. Another thing Google has also released GWT-Material which is again a very good thing because everyone is moving toward material.
I hope this will help you!!!