28 December 2012

Adobe Flex & ActionScript Crash Course

This article will try to provide a lightning quick introduction to the Flex and ActionScript technologies. Although supposedly a dying technology, Flex does have it's somewhat large user base and perhaps, now that it is donated to the Apache Foundation, it my be resurrected. And since I am a Java evangelist, I would present this from a Java perspective. Of course, as you might have guessed, most of what I mention is also available for other server-side frameworks and languages, so the principles are the same.

First of all - what is FLEX?
Flex is, basically, a (mostly) client-side technology for building RIA applications. It's usage is free of charge, however the FlexBuilder (IDE used to help develop Flex applications) is not.
Since Flex runs inside the Adobe Flash runtime platform independance is handled by Adobe (in contrast to technologies such as JavaScript or HTML5 which are standartized and handled by the browsers themselves without the need of plugins). As such this approach has the advantage of Adobe making sure that content is visualized in the same way no matter what the browser is. This, of course, comes with the disadvantage of Adobe having to support all the platforms themselves.
In short Flex allows the creation of MXML files defining page structure (panels, forms with buttons, lists, etc.) and converting this into a SWF file, which could later on be used by the Flash runtime to display the content of the page in a browser (or somewhere else).

So where does ActionScript fit in?
In reality ActionScript is just another implementation of the ECMAScript standard (similarly to JavaScript). From an architectural perspective the ActionScript is used to write the Model and the Controller when writing an application using the MVC pattern while the MXML is used to describe the view. In other words ActionScript defines the behaviour of the visual components and the data model supplying each of them.
If you have never ever used JavaScript or any ECMAScript-like language, but you are familiar with Java you can take a quick look at this article.

Where does Java fit in this picture?
Remember how I mentioned that Flex is mostly client-side? This is because in practise we rarely create a web application that needs to be run entirely on the client because, obviously, this would defeat the purpose of having a server.
Typically we would want only a small part of the controller code to be executed on the client (for example, if we take JSF for example, we would want the validation phase, the binding phase, the converting phase and etc.) while other parts (such as database operations or heavy calculations) would still take place on the server in our (probably) stateless beans that contain the business logic.
No matter what the actual server implementation is, Flex provides a remoting mechanism called BlazeDS which handles the communication between controllers and views and the Java back end (essentially providing serialization, de-serialization and method invocation on the server and client). Adobe provides a good article on this topic that explains just how this works.

What else is there about Flex that I'd like to know?
There is a lot, actually. A quick (and incomplete) list would be:

15 November 2012

JavaEE.Next : Java 7, 8 & Beyond

by Reza Rahman

"Things that we in Oracle see"

Sparing us from the unnecessary historical overview we can actually jump in the features, that are under discussion for the next Java 7 release (JSR-342). By the way the discussion was very broad, also including technologies and improvements that are going to be released in the 8th version and beyond (as you might already know the Java EE7 is planned for April 2013).

The JMS 2 API for example would be modernized, including dependency injection and some API refactoring. Other changes to the API include:

  • any implementation of the API would also need to implement the JCA adapter
  • changes related to asynchronous sending of messages, delay settings, etc.
  • some changes to the code display - visually fewer lines of code, by injecting the whole JMS context and removing the boilerplate code for creating messages
  • JMS resource definition - a very quick and easy way to define a resource using annotations

There would also be a Java API for WebSockets that uses declarative style for creating WebSockets. Did you know what WebSockers are? Me neither ... but apperantly they are very important for online gaming and full duplex communication over the TCP protocol.

The Java API for JSON processes would put some smiles on the faces of people who actually like tinkering with JavaScript (There are such people, aren't there? Because I've heard of them but never saw one). The API would allow for parsing, generating and transforming JSON queries, taking in mind the best practices that are established. The API would also allow two models of usage - model and streaming - similar to the DOM & STAX APIs. However, as good as that might sound, binding JSON to Java objects is not planned for Java EE7 and would perhaps be there in Java EE8

"The big new thing" in JAX RS 2 will be the client API, but there would be other enhancements too such as (but not limited to) : filtering, interceptors, hypermedia support, etc. As part of the presentation there was a very good example of building up a client, but unfortunately I was not able to find this example. It was pretty impressive though.

Another big new thing (that would hopefully be part of Java EE7) was the Java Temporary Caching API (see JSR-107). It would be highly configurable by using annotations - e.g. defining a cache eviction strategy in a declarative fashion.

The same as last year there was some talk about JPA 2. There are some neat new features such as

  • Schema generation - the persistence manager generating the schema based on the JPA mappings, which was already feature of some of the implementations of JPA, but now the standard would define it.
  • There would also be support for stored procedures! Yes, we all have some bad memories from working with stored procedures, but they are there and we can't ignore them.
  • The persistence context would not be auto-flushed and thus we would be able to define the policy in the persistence manager
  • Last, but certainly not least, there would be a way to define entity conversion strategies, e.g. converting database types to Java types

The JTA 1.2 API would also be present in the release, another old API that needed actualization. It would now have declarative transactions outside the EJB and would also allow for the definition of transaction scope.

My favorite bittersweet API - the JSF 2.2 API - would also be improved:

  • HTML5 support! Yes, yes, the new big thing ... yet another new big thing
  • @FlowScoped vs @ViewScoped for CDI (stands for "Contexts and Dependency Injection" if you did not know, see JSR-299) - basically define your own regions in the whole web application and thus identify which objects need to be destroyed while navigating through the regions.
  • Finally! A FileUpload component would be defined by the API and the framework implementations would confirm to a single API, unlike the various custom implementations that are currently used.
  • View actions and multitemplating
  • Speaking of HTML5 - there is the option to use the native components and still bind them (using the framework IDs) with the rest of the application, effectively integrating them in the framework
For more information you can check this article on what's new in JSF 2.2

There was also a lot of talks about some interesting candidate APIs that might or might not make it in the next release, such as

  • API for robust batch processing (JSR 352? not sure ...) specifically designed for the EE platform and would allow for defining components via annotations, etc.
  • Bean validation
  • Servlet 3.1 - non blocking I/O, Web sockets again, etc.
  • CDI 1.1 - Servlet events, ordering of interceptors, etc.
  • EL 3.0, EJB 3.2, etc.

What about Java EE8? It would come 2 years after Java EE7 (if I am correct this would be April 2015) and would bring us to the cloud - PAAS, multitenancy, IAAS - but would also provide updates on HTML5, bring more modularity, etc.

14 November 2012

Java2Days 2012

After a prolonged and inexcusable pause I am back, sharing my impressions from this year's Java2Days conference which took place a few days ago at the InterExpo Center in Sofia.

As a whole the conference was somewhat disappointing because there was too much repetition from last years topics (and lectures) and not enough thrilling new stuff, which I believe this conference is all about :)

However I did manage to make some notes and will share some of the most interesting topics. Here is a preliminary list of all of the articles I'd like to cover:
  • JavaEE.Next : Java 7,8 & Beyond another very good inside preview by Reza Rahman
  • Multi Client Development with Spring MVC by Josh long
  • API Design a very interesting topic presented by Pavel Penchev
  • HTML5 where Andrew Lombardi synced us up on the HTML5 adoption
  • Garbage Collection & Memory Leak Detection where my friend Simeon Iliev
  • shared some experience with the JVM memory management
  • Testing Multithreaded Java Applications for Synchronization Problems - a very serious and advanced lecture by my colleague Vassil Popovski
  • Dependency Injection in OSGi by Jerome Moliere
  • Domain Driven Design with Java EE 6 another very interesting lecture by Reza Rahman
  • and finally some words on Taming NoSQL with Spring Data which is a very good overview by Sergi Almar Graupera on how Spring integrates with most popular of the currently available NoSQL database engines

The Java2Days participants have provided some of the presentations here.

09 July 2012


Today I bring you yet another set of acronyms that the software development community has invented in order to fully confuse anyone desperately trying to put order in this art.

So what is KISS?

My personal favourite principle, acronym for "Keep it simple, stupid!". In case it sounds to politically incorrect for some public presentation you could try and change it to "Keep it simple and stupid", but still this is probably the number one mistake developers tend do do. It is also applicable for almost any system that is being developed - that being a software, hardware or whatever system.
The main idea here is just that - the more complicate a solution to a problem is, the bigger the chance for it to be unsuccessful. A typical sign of overengineering is adding too many layers of complexity for solving a simple problem.
A good software engineer should always consider if the effort put into solving some problem is not an overkill, typically in the prototyping and planning cycle, but also in the development cycle when implementing the initially planed software skeleton. This principle is very tightly connected with the YAGNI principle.

So what is DRY?

Yeees it is a bad idea to "just copy this code from the other class". This principle stand behind the idea that you do not repeat yourself. Copying your code has many disadvantages - you need to maintain both pieces of code, if one changes and the other does not you introduce possible instability. And after all OOP languages give you many ways to avoid code repetition.
For me personally having duplicate code is always bad design and never a good idea. Of course there are other areas one should avoid repeating himself - tests, DB schemas, etc, but code repetition is the most common instance.

So what is YAGNI?

Another perspective of the KISS principle is "You ain't gonna need it". This is a very valid point for people like me who like the ideas behind extreme programming.
Generally the principle argues that one should not write any code that is not immediately required for solving one problem. aside from avoiding overengineering it also help keep the code base simple. You could be 100% sure that some feature would be required, but unless you are working on it you need only to make sure you do not make your code such that it would require much refactoring to include this feature. coding the feature as part of another feature or because you believe it would benefit the whole project is genuinely wrong - not only does it slow you down but it removes the focus of your work. Do not write code you are not going to use!

22 February 2012

Something really funny

Microsoft is now warning us about how dangerous platform dependability can be :

Am I the only one who sees the humor here?