On Scripting Languages

By Sibers CTO Andrey Gavrilov

Whatever they do, scripting languages all have a big flaw, namely interaction with the parent objects system. It so fell out, I am now scripting a Java application on JavaScript. If you don’t know, Mozilla Rhino is perhaps the strongest realization of script languages under Java. Full concordance to the ECMA standards, stability, optimizations etc. All you need.

As you understand, scripting language (also called an extension language) is used not alone by itself but to control some parent application. It means that it accesses Java classes. And that’s where rock-n-roll begins – some classes exist both in JavaScript and in Java. Like String. And these Strings are very very different Strings.

What comes next? Many methods of these classes match each other. For example there exists a method replace in both “Javas”. But again – these are very very different replaces.

And you know what? The script generates no errors – it just uses the Java’s replace because somewhere before it had used the wrong String. That’s it.

It’s all spiced with the fact that some allotted in API classes are accessed only by JavaScript and use classes of Rhino.

A workaround? Explicit definition of types – everywhere! It helps although it does annoy.

JavaFX Thoughts

By Sibers CTO Andrey Gavrilov

Recently I’ve decided to make a short review of JavaFX which represents another case of a good idea implemented poorly.

The idea behind JavaFX is very simple – developer creates an interface oriented application using some script. Then this application can be launched from a web browser, desktop, or even from J2ME.

First point: JavaFX Mobile.
JavaFX is presented as an interface oriented language, and the interface is exactly the element which is copied with guarantee during its porting to a mobile phone. Why should be an extra extension for J2ME if mobiles have the issues with capacity even without such extensions?

Second point: Competition.
JavaFX functions on the regular Java machine, i.e. user of Windows XP and its higher versions should download full Java-Runtime in order to launch it. Taking its size into account, this is almost impossible to do. Actually it is better than Mozilla XUL, which works only in Mozilla, but worse than Microsoft Silverlight, which realizes absolutely the same ideas as Java FX but on any .NET platform. All these issues put together make JavaFX less suited for work than Adobe AIR, which is a desktop Flash, and can be launched on the web without any problems.

Third point: Extra layer.
JavaFX uses Swing which is launched on Java only. While everything functions stably, it can be used without any problems, but as soon as any errors or issues arise with Silver – all Hell breaks loose. I’ve encountered similar problems during my experiments with Grails.

It’s a pity that JavaFX has these problems because I can’t wait to see a cool Open-Source Flash Killer since I don’t trust any languages with proprietary kernel.

Google Releases Guice – opensource ioc framework

By Anatoly Ivanov, Sibers Java Team Leader

Google again and again proves its high class. It has released a wonderful creation for most projects, especially small and mid-sized.

Evaluate excellent binding api:
binder.bind(Service.class).to(ServiceImpl.class);
Looks like a natural language (in elaboration of hibernate ideas).

The new Guice can perform annotation based dependecy injection (without any xml nightmare (Spring), fast and elegant) and aop (based on aop alliance).

Nevertheless, to be suitable for large projects Guice lacks some useful Hivemind features:

• module organization (which is absent in Spring as well). Modules are very convenient to write utility libraries or to divide the project into parts, and Hivemind finds and picks up modules automatically, which is its certain advantage.
• configurations. Hivemind allows describing the configuration scheme (like xml schema or dtd) and then configurating files in the config file; no parsers, much easier than dtd.

Google doesn’t surprise with configuration through annotations as Hivemind 2 had such a feature as well. Google feature seems to work faster, but it’s not essential as main delays usually appear at the level of making the repository and are negligible compared with the Hibernate initialization.

Summing up, if you ask me, both GWT and Guice cater for novice developers and not very difficult tasks. The tasks are not necessarily simple, but Guice doesn’t seem to be good for writing big repositiries (with more than 100 servers). It is also unilikely to be wide spread in big projects, where Spring seems to prevail. Small and mid-size projects, however, can fully use its advantages as Spring’s and Hivemind’s power is not always necessary and the latter are quite difficult to master.

Liferay: Overcoming Obstacles

By Anatoly Ivanov, Sibers Java Team Leader

Liferay Portal, which we have already announced and are using for our Java projects, as any application presents certain difficulties, which you may have encountered. Interested in our practices on how to make it work correct? This is what I come up with.

1. Filters
Portlet container should completely emulate servlet container work, namely wrap each request with filters. In fact, it initializes servlet filters, but only one in two or even more is activated each time (without noticeable regularity). It is due to the transaction per request approach, where the beginning of every request starts a transaction with the base and when the request is over, the transaction commits in the absence of any exceptions. Such an approach allows canceling any changes in the base during the current request (for example, in case of exceptions) as the portlet didn’t fix them and the database didn’t update with conflicts in different requests. Besides, without filters updating work with hibernate in the portlet, the session regularly failed.

Way out: Using subproject apache bridges (portlet filters) with working filters for the portlet. The problem is that portlet specification makes no provision for such filters on the supposition of servlet filters working correctly.

2. Myfaces bugs
The library is not fully debugged and sometimes digresses of the JSF specification, which results in time consuming looking for ways to do without bugs or changing to new library versions.

3. Debugging
Debugging under Liferay is quite awkward as it takes much time to start or shutdown the server, redeploy it, etc. Debugger can’t get involved and the search for problems is quite a task.

4. Liferay bugs
Liferay itself is not free of bugs. For instance, it doesn’t always form application classpath correctly, which leads to its malfunctioning. Sometimes Liferay goes into mysterious loops.

5. Changing library versions
This change may cause fall of jobsites because of the library’s bugs or its conflicts with other libraries.

6. JFS Porting
JFS porting for the portal is still an experimental area. As Lifray doesn’t provide standard compatibility means and portlet and JFS have different life cycles, an interlayer is essential for correct work.

Way out: In order to launch our JFS project under Liferay Portal, we are using an exterior project Tomahawk Bridge (http://palab.blogspot.com/) and its library. After lowering the version of myfaces-core till 1.1.4.1 there appeared some bugs in representation and navigation. However, developers are aware of these problems and are working on compatibility. In general, Liferay is starting to develop towards JFS compatibility.

Moreover, with JFS specifications satisfied, the project can work almost anywhere and be independent on the container. In our case JFS can be debugged in the frameworks of Tomahawk, which minimizes the time.

We are migrating!!! From JBoss to Liferay

No, no we do not move our office anywhere and don’t immigrate. Siberian woods in front of our office windows are too beautiful site to move from and the bears we usually feed on our way to work, would feel too lonely without us.

Our Java development team simply decided to choose Liferay Portal over JBoss Portal for our Java projects and thus we migrate our current projects. We came up with this decision for the following reasons:

1. New technologies support. This is one of the essential issues in choosing enterprise portals. Such popular new technologies as AJAX and Java Server Faces are better supported by Liferay portal since JBoss support of these two technologies is in the process of testing

2. Cross-platform support. Unlike JBoss, supported by any OS that runs JVM, Liferay does not have such limitation and is supported by any OS

3. Architecture. Organization structure in Liferay provides easier control over the tasks that users could perform.
    

4. Additional portlets. The number and variety of portlets used in Liferay is much larger than JBoss portlets.

5. Configuration. In order to configure Liferay you don’t have to edit its configuration file as you do while configuring JBoss.

So from now on Liferay becomes our favorite enterprise portal making life easier for you and for our development team as well!