Has anyone had experience taking a full-fledged Java desktop application and replicating the functionality using Flex?
If you have, what are some of the biggest things to watch out for or pay attention to?
What are some recommendations you can make based on your experience?
There could be any number of issues to watch out for. Here's a few that just come to the top of my head:
Flash Player restrictions that do not exist in the JVM, such as the ability to reach "outside" of the Player's bounds rectangle (and myriad others).
ActionScript 3 has no equivalent of java.lang.reflect.Proxy, unfortunately. This means that (so far) there are no decent mock object frameworks, and limitations with respect to reflection in general.
I am not aware of any AOP capabilities on the order of what you will find in Java.
Whether or not the Java application is using libraries that have no equivalent in Flex and which you do not wish to write yourself.
Java applications can call out to native code with the JNI, whereas this is not yet possible with the Flash Player.
Even if by "Flex" you include the Adobe AIR platform, the environment tends to be much more restricted in general than the JVM. However, don't let that discourage you - you get a lot of benefits from using Flex, such as an ubiquitous runtime, a great language and component development framework, etc. If your Java desktop application is an RIA, then Flex is probably a good candidate for a port.
I'm not sure if replacing a full-fledged Java desktop application with Flex is the best alternative. From Adobe Flex page: Flex is a highly productive, free open source framework for building and maintaining expressive web applications that deploy consistently on all major browsers, desktops, and operating systems.
Adobe AIR is probably a better replacement for desktop applications, if you're considering Adobe realms of products.
Related
I am a java developer and I would like to develop rich clients for the web. My problem is that I hate javascript, flash, etc. and most of the programming languages usually used for web client. I would be happy to keep doing java to develop web clients that may be used on common web browsers and, why not, on new fashion mobile devices. I am looking for some advices/warnings to make a good choice.
Java applet seems perfect for my case, but according to some rumors, it is not a really sustainable solution. Should I have a look at JavaFX? GWT? Are there some other possibilities?
What do you want to do? Vaadin is based on GWT and therefore utilizes HTML5 + JavaScript which is much slower than a Java Applet. I have tried boat and Applets with Swing is A LOT
faster than Vaadin.
With Java Applets, Swing and Hessian you have unbeatable performance for business applications. Hessian is a very fast binary web service protocol. With JavaScript you are usually limited to text-encoded web service protocols like Json and various XML-based protocols. Text-based protocols consume a lot of CPU, memory and bandwidth compared to binary protocols - and they don't really provide you with any advantage at all.
The weak point of Applets is hardware accelerated graphics like OpenGL and multimedia. If you are developing games or movie players Applets is not that great.
JavaFX promise to fix hardware accelerated graphics performance and video codecs. With your description it is not clear if you need to wait for that.
However if you really need more than what standard applets will provide you than web start may be a solution. Its a bit like the old ActiveX with signed or unsigned application that gets extra privileges - either by being signed by sun or by asking the user. This will allow you to use JOGL or a 3d scene graph engine.
You are a perfect fit for JavaServer Faces (JSF). Yes just try them on. Look, you look great in them. The appeal of JSF is 1. It is a standardardized technology, part of Java EE 2. It relies a lot on Java programming over any JavaScript coding (which is not done at all). 3. JSF has been around for awhile, and it works quite well. In addition, JSF works with Ajax, out of the box (an added bonus), without writing a single syllable of JavaScript. The only downside is that you will have to code some html, and the "facelets" are basically html pages with some extra tags thrown in that you need to learn. But the vast majority of the real processing is done in Java. JSF also works without the extra baggage of Java EE, it was built to work with a plain Tomcat like server (or Glassfish or JBoss, etc) and a browser, and Java SE (the desktop version).
I think JavaFX looks very promising as a Java-based RIA technology. It's cutting edge though. Mac OS X and Linux versions are only available as a preview yet. Mobile and other device support has been announced but its not out yet, AFAIK.
Vaadin would also be suitable, requiring no Javascript or HTML at all, even for new component development. Page layout is done using layout managers (like Swing). New components can be composed from existing components (again, like Swing), or written from scratch using GWT (fairly straightforward, and pure Java).
There is a reasonable selection of add-ons covering some features not in the core framework.
The framework is very easy to use for Java developers with Swing experience, and has a polished look and feel out of the box. However, the layout managers do make it difficult to change the look and feel using CSS - simple tasks like adding borders are hard.
The layout is also quite "heavy", which means that Vaadin websites can feel slightly sluggish. In my experience, the feel is still better than some of the heavier JSF frameworks.
It is compatible with all major browsers.
Demonstrator: http://demo.vaadin.com/sampler/
You could also consider Wicket. This has a similar component-based approach, but the components are defined using simple HTML fragments, which results in a much lighter DOM (and therefore better browser performance) and far better control over the look and feel. Wicket has a steeper learning curve, however.
After trying GWT and struggling with its so-called "super-dev mode", I discovered JavaScript programming was not so painful. I forced myself to learn and practice and I finally fully adopted it. There are numbers of nice things in JavaScript and a huge number of libraries. My recommendation for people in my case is just to persevere in learning JavaScript using for example w3schools tutorial.
What is the Microsoft version of an embedded Java web applet? Is there a good example of one on the web?
Also, why is the dynamic web dominated by ajax and not embedded applications?
Silverlight is probably the closest thing now.
As far as why the web is dominated by JS driven websites rather than embedded proprietary applications I'd venture to guess it's the openness of the resulting web pages. Almost every web browser out today ships with a JS engine, and most users run JS; this is important because it means the user doesn't have to have any other applications (beyond the browser) installed on their computer.
JavaScript driven sites are also more portable than embedded applications -- the developer only needs to worry about a browser being installed (though perhaps a particular browser), not what operating system the end user is running. In terms of being on the web, only having to worry about browsers is better than having to worry about browsers and operating systems.
Furthermore, the pages that result from JS execution are selectable, the text can be copied and pasted -- in general, JS-driven websites are often more accessible (though often not as accessible as plain-old-text websites).
Perhaps something that helped JS/Ajax rise to the top was that it could so easily access to the DOM, so it plays nice with HTML (and the existing web infrastructure).
An ActiveX control?
Also, to your second question, well these "embedded applications" as you call them aren't really web applications. They are components that require browsers to support some sort of way of hosting them that are outside of the realm of traditional Web standards and specifications. As for why these applications don't "dominate" the markert, they tend to break out of the way the web works and many kinds of platforms and devices don't support them such as mobile phones.
The Microsoft equivalent of an "applet" is roughly an activeX control, although they are only vaugely similar - the similarity is that they are both embeddable into the browser. The most notable difference other than windows vs cross platform is in the region of security. With ActiveX, it is all or nothing - you either don't run it, or you trust it with everything - the activeX control runs as a regular windows "program" and has the same level of access as other programs running under your account. With an applet, security is more finely controlled, with the default being a controlled environment - the "sandbox".
As to why AJAX is more popular might be considered a subjective question, but from the technical perspective, some objective points in favor are:
it is implemented on top of a browser model that aims to provide a safe/secure execution environment
is cross platform (in as much as the browsers adhering to the various standards involved.)
has a suite of development tools and libraries for getting results quick
it can manipulate the components in the browser rather than working inside an isolated embedded box
it provides a better end user experience - seamless integration with the webpage with no security warnings, certificates, popups etc.
You could consider ActiveX or Silverlight both as alternatives to Java Applets.
Ajax is built on open standards, is natively supported by most modern browsers without requiring a plugin download, and when done correctly is often the best option from a performance standpoint.
I have spent most of my web-development career in the Microsoft camp, but for different reasons I am trying to look at options.
Some years back I did a bit of Java/Struts development in eclipse, which was nice for its time but my memories of it are not close to what Visual Studio delivers today.
Some of the strengths of the MS stack as I see it are:
Ease of use. Free tools (express
editions), easy to set up, easy to deploy, loads of components and
support, even for cutting edge
features like ajax and jQuery.
Intellisense, so that the API
reference is there as you need it.
Size of the community. Things like www.asp.net,
with the free video tutorials,
samples, documentation etc. Free,
official and reliably updated
information from MSDN.
Enterprise scalable and decent
performance.
Fully object-oriented, (semi)compiled
languages, allowing for sound design,
patterns and practices.
There are of course weaknesses as well, like:
Pricing, once you go live with
anything semi-serious.
Vendor lock-in.
Total lack of cross-platform support.
I have spent some time this evening trying to get a grip on how things are outside of the microsoft world, and
I have found loads of PHP frameworks, Ruby on Rails and relatives, several Java frameworks and a few very odd alternatives.
Some of these seem very interesting, so I would like to hear from actual developers using the different frameworks, and try to find out how they compare to what MS has at the moment.
Which framework are you using, why is it great, what could be better and what kind of sites have you built using it?
Jeff & co made most of Stack Overflow in a few months using ASP.NET MVC. If you had to do the same using a non-MS framework and tools, what would you pick and why?
We have a pretty heavy investment in the Microsoft framework at the office and so I'm mostly doing ASP.NET MVC stuff now. If I were to pick an alternative at this point, I'd probably go with RubyOnRails. It has a very clean MVC implementation -- playing around with it made it pretty easy to get started with ASP.NET MVC when it came along. There's also a lot going on with improving testability -- particularly natural language-like testing frameworks coming out of the RoR camp with Cucumber, et. al. All the investment in testing makes TDD/BDD much more natural in that framework.
If I wanted to go opensource I would go with:
RAD web development: tomcat running Railo, a Java based open source CFML implementation because CFML is a good RAD tool. Railo performs well, is capable of clustering, is able to be extended through editing the source or adding your own extensions.
DB: MySQL for a DB backend because it performs well and just works.
IDE: - Eclipse + CFEclipse because that is what's available, although I want some improvements. Since CFML is a dynamic language you don't have Intellisense, just context help for the api.
OS: Any opensource unix based OS. Probably Ubuntu.
MVC Frameworks: Mach-II or Model-Glue because I'm familiar with them, although I'm open to checking out ColdBox.
I build web apps with:
PHP
Zend Framework
ExtJS toolkit
Aptana IDE
Disadvantages are the typical ones: lack of integration between the tools, weakness of debugging tools, complexity of deployment (although the deployment issue is true for pretty much anything except ASP when you're talking about windows servers).
I'm not too aware of ASP.NET, having only marginal experience with it, but the advantages as I would see them are cross-platform support, cheap hosting ability, architectural control (PHP is more low level, and Zend Framework is easy to buy into one module at a time, so you can more strictly control the behavior of each page).
I am using Django. It is easy to learn, very well documented and most of the brainy stuff happens in Python (assuming you like python). I develop all my HTML and CSS by hand using Aptana - gives better control but has nice helpful features.
Using many IDEs / editors you can get auto-complete based on the Django code-base (Netbeans, PyScripter, Komodo). You can then host on either Windows or Unix (Linux, Solaris, Mac).
There are many RIA frameworks popping up (flex, extjs, gwt to name very few).
If my server is written in Java, why not use java web start?
The benefits I see: I get to program in a language that is easy to debug (compared to javascript), I can use the same code in server and client side (validations, model objects). With SWT I get nice looking GUI.
Even if it means requiring a plugin in the browser (or using a cli tool), if my application is an enterprise application, does it matter?
For webstart you need Java installed on the client. For Flex Flash. For Silverlight .Net. For other RIA platforms a JavaScript enabled browser. It is a lot of product politic in that question.
And Java is very intenting, because "all seems to be a nail". Of course one of the great advantages of Java: same language, same knowledge, same code on every platform or environment (server/client/middleware).
For enterprise internal use, no it does'nt matter at all. If your biz is on the internet the decison is much more complicated (or even you have to offer the same functionality in diferent platforms).
The only contra argument is that in a lot of cases it's impossible to force the clients of your rich client app to have Java runtime installed on their machines. Everything else is a matter of taste, already existing knowledge and experience.
I think that until now the perfect client technology simply does not exist. We were excited about ajax and then there is another "hot" technology like Adobe Air. What is the difference between these techs and the "old-fashion" client-server apps? My friends we are back to the early 90s!
The AIR for example needs a runtime installed on the client machine, it has access to local system resources and communicates with the server using a binary protocol. On the other hand we are developing "RIA" applications (and very good ones :) using pure java swing clients communicating with the server through the Spring's binary remoting protocol. And i must say, in such a development life-cycle Java-Webstart is the winner. Especially in large-scale projects (and i mean laaaarge-scale, not just e-shops) in the java field i haven't found something more productive and maintainable (ah! maintainence... another big story) than this.
IMO if your users can live with a nice look-and-feel and you don't have to adopt another technology just because it is young and sexy use webstart. Put more work in your business model. After all enterprise apps is about business, not animations. And money is where the business is ;)
Yes I think it does matter, seeing that some big companies still have IE6 as their standard browser and as a requirement for web based applications. And those won't allow you to install any third party plugins into their dinosaur browser.
And you don't make a difference between RIA technologies that use existing browser technologies like JavaScript, CSS and HTML (including GWT which just generates client side JavaScript and ExtJS which is just a JavaScript Component library) and the ones that require an additional runtime environment (Flash, Flex or client side ).
Of course some things are easier to accomplish with proprietary or third party solutions (or you just have more knowledge in one of these platforms), but I still think that there is a huge potential in technologies that are standardized and already implemented in every modern browser (the differences between the browsers are slowly but steadily getting better, too).
If you ship it as a 3rd party application you can define a JRE as a System requirement, anyway but then instead of JavaWeb Start ship it as a normal Java Application as well.
Why Java is still used in web development? I'm just curious..
There are a number of reasons:
1. It is by no means a dead language. There are thousands of Java developers out there.
2. Many available Java developers means that it relatively easy to find maintenance programmers if necessary.
3. The Java / J2EE architecture is robust and reasonably elegant. It makes it possible to architect well built applications.
4. The free tools available for it are enterprise ready. For example, Apache / Tomcat / JBoss are a solid foundation to build a web-app from.
5. Excellent support for developers. Eclipse is one of the best developer platforms available. Ant and Maven support for Java is excellent.
6. There is a good availability of third-party (and open-source) libraries and Eclipse plug-ins for most of the additional functionality that might be needed but does not come in the core libraries.
7. There is also great support tools from commercial vendors: ORacle; IBM / Rational; etc.
8. Updated versions with newer language constructs are constantly being developed.
In short, it is a good tool for the job. It is compares favourably to other development platforms (.Net, Ruby, etc), and perhaps is better than some.
Simple. It's a cross platform environment, that is clearly defined, and controlled. Sure, Sun has a big deal of say in what is available in the Java environment, but there is plenty of 3rd party support and development in the Java environment.
Yes, Java applications start up slightly slower than Native applications, but take a look at VUZE... Once it's started, it's nearly native speed (or at least it was when I was using it). With the JIT (Just in Time) compilers, code caching, and other features, there isn't much of a reason that there would be a major speed penalty...
One big reason I think is because it's platform independent meaning they can easily run on all operating systems as long as you have the Java Runtime Environment installed. This could allow you to, for example, compile code in Windows and deploy on Unix.
I would also add that while this is only a con against .Net, your application server doesn't have to be Windows so it is cheaper to throw more hardware at it.
For the same reason as why COBOL and FORTRAN still exist. Because the language has proven itself to be robust and reliable.
Compare it with cars. Some people want the latest models because it has more power, better speed, improved features and whatever more. Others will just use a reliable car that's made to last for many years without much need for additional maintenance. Some buy a new car every 3 years, others will use their cars for half a century or more.
When talking about Java & the web, people seem to happily mix things by concentrating on Java applications deployed with Web Start (or even Applets), and forgetting that Java is a common language for implementing plain old dynamic web sites (or web applications). The latter is especially true for larger, more "enterprisey" systems. Even if on the desktop Java never really took off, on the server side it certainly did.
Without going into much detail, a couple of reasons why Java is used for creating web sites / applications:
It's a tried and true approach for building large-scale web apps. Either using just the basic (Java EE) technologies of Servlets and JSP, or newer frameworks built on top of those, such as JSF, Wicket or Google Web Toolkit. (Just one example of high scalability: Gmail is implemented in Java, using Google Web Toolkit.)
A mind-boggling amount of Java libraries exist, for all kinds of tasks — both open-source and commercial ones. If you need some in the backend of your app it may make a lot of sense to do the whole app using the same technology.
There are a lot of skilled Java developers out there — something that may affect tech desicions when launching (larger) projects
When creating a web interface for, or integrating into, an existing Java enterprise system (which are common) it may be beneficial to use the same language
Edit: I also agree with Doug about the tools and developer support. For example, IntelliJ IDEA may well be the most advanced IDE for any language (and I've heard this also from people who've used Eclipse and Visual Studio extensively... ;-) )
It's ubiquitous. The tools are great across the board. It's powerful. The community is huge. There is an amazing amount of available libraries / products / toolkits / frameworks. The JVM is great.
You can build cathedrals with this language. Those tend to stand for centuries.
Since Java doesn't run on the iPad, doesn't that hurt Java web development? Developing a web application that supports desktop and mobile is a possible path, but if your site uses Java or Flash, you have eliminated that opportunity.
We have a web application that is for both desktop and mobile (supports swiping, zooming, and such using jQuery). We decided against Java, Flash, and Silverlight because they do not work with iPad. The iPad is a growing base and web applications will have to keep up to support it.
It will be interesting to see how this affects web development with Java... time will tell.