JavaScript support in NetBeans 6.1

NetBeans 6.1 contains a number of features that are very promising. More specifically, the JavaScript support has improved dramatically.

In a number of web-based projects we are currently involved in, there is a "clean" separation between HTML and development. At least, that is the theory.
In practice, however, templates are JSP-pages containing HTML elements, JSTL tags and JavaScript. Today, the JavaScript part is often increasing, as is the number of JavaScript libraries that are concurrently being used.
Small errors and typos in JavaScript are often not noticed until the page is rendered. In many cases, some JavaScript code gets only executed in a specific situation, and errors might be discovered way too late.

I didn't expect drastic changes in a point-release, but NetBeans 6.1 makes our lives somewhat easier, on the JavaScript front. The IDE now contains JavaScript support features including syntax highlighting, code folding, background parsing, error notification, bracket matching (!), formatting,…
As a result of this, our JavaScript development is moving from vi to NetBeans (but again, nothing wrong with vi!).

Have a look at http://wiki.netbean s.org/JavaScript for a summary of the JavaScript support in NetBeans 6.1

GlassFish v3 and OSGi

I have been a member of the OSGi Core Platform Expert Group for several years, and I was one of the founders of the OSGi Vehicle Expert Groups. Hence, I know the technologies pretty well. Unfortunately, the OSGi membership model makes it very difficult (read: expensive) for small companies like LodgON to become a participating member — and I am not interested in a membership that does not allow me to participate in the specification process.
Nevertheless, I am following the OSGi activities very closely, and we are doing some customer projects based on the OSGi specifications. At LodgON, we convinced a major customer to use OSGi for a very cool but secret prototype.

GlassFish v3 can hardly be compared with the previous generation of Application Servers. That is, it provides backward compatibility from a functional point of view. It will provide e.g. a container for WAR's and a container for EJB's.
But it can do much more (or much less) than the previous generations. In the past, an Application Server was a huge block of software providing some well-defined functionality to the user. What I have seen in a number of cases, though, is that only a small part of this functionality is used in a large number of projects. This leads almost inevitably to some sort of a penalty. If you have a simple web-project that only needs a WAR container, lots of standard functionality in the Application Server is rather a curse than a help.
As a consequence, the use of these full-featured Application Servers is often limited to high-end enterprise applications — although they provide at least the same functionality required for more simple web-projects.
On the other hand, Application Servers in many cases do not offer all the infrastructure that is needed in projects. I haven't seen many mobile applications running on an Application Server. Maybe this sounds weird, but I am pretty sure that this will be commodity within a few years. One could of course question whether we are still talking about Application Servers in this case, but my point is that the same technology can be used.

The OSGi model provides a very good architecture for solving both issues. The heart of an OSGi-based application is an implementation of the OSGi Framework. The OSGi Framework itself consists of a small number of classes and interfaces, that can be implemented by different vendors (actually, I wrote an implementation of the framework myself when I was working at Acunia, it isn't that hard).
The model then allows you to develop bundles and services (I am not going to explain the difference here again, I've done that thousands of times in the past and I am sure there are decent on-line resources describing this). Bundles may have dependencies on some packages, and they may export some packages. Apart from that, they can operate pretty independent from each other. The idea is that for a given project, you use only the bundles that are needed for that project. Suppose that the WAR container is a bundle, and the EJB container is another bundle, then you probably don't need the EJB bundle in the case of a simple web-project. And in the case you are working with mobile clients, you might need a MIDP bundle [long discussion about co-existence of OSGi and MIDP infrastructure on mobile devices omitted].

At this moment, GlassFish v3 only uses OSGi internally, hence no external API's are exposed. Work is currently being done to make the different parts of the Application Server code more modular, and fitting it into a number of bundles.
The efforts that this operation requires should not be underestimated. I have "OSGi'zed" a number of smaller projects, and it is not always easy to remove spaghetti-dependencies and make interactions cleaner and compliant with the OSGi model. However, the end result is often much more readable and better code.
It would be great, however, if GlassFish v3 goes one step further. Developers of middleware software can make some OSGi bundles as well, and deploy them in the Application Server. Those bundles can then depend on other bundles available in GlassFish, and only the required bundles are packaged together. The result is an Application Server that exactly contains what the application needs. In case of a complex enterprise application, this is probably a huge set of code. In case of a mobile application, we are probably talking about a much smaller number of bundles, and much less code.

Let's see how things evolve. 

A JavaOne session with lots of wisdom

 On my way back home, I am thinking about which JavaOne sessions I really learned from. There were a couple of interesting things about OpenSocial and Shindig, and of course I attended a number of interesting GlassFish sessions. But the session that gave in my opinion the best information to developers was Adam Bien 's session on the Java SE and Java EE platform.

Adam discussed some of the issues that EJB developers encounter in everyday's projects. I particularly liked his session since it had a high "cut the crap" attitude. More concrete, I remember two of his statements that may sound controversial:

• Don't distribute (when it's not really really needed)
• Be careful with adding external frameworks/libraries

It wouldn't do justice to Adam's talk if I was just minimizing his session to these two points, but for me they are pretty important.

Don't distribute
Today, many projects get layered and prepared for scalability without a reasonable guess on the expected load. In many cases, a system designed for local access (e.g. a war and an ejb-jar inside the same EAR on one server) can handle a considerable amount of load. If you don't expect high loads, you shouldn't use remote EJB's including all the penalties they come with. Nothing wrong with remote EJB's, they're one of the best inventions since RMI, but you should use them when they are required.

External frameworks
I am careful when commenting on this, since I know that a lot of people out there are very happy about the external framework and libraries they use. Also, if you look at DaliCMS, we use a number of external jar files there.
However, as the members of the DaliCMS development team are very much aware of, I am strongly against adding another library unless it is really, really required. And really, really required means that you can't do the same with the standard Java API's.
This is also something Adam Bien pointed out during his talk: there are a lot of Java API's, use them. Personally, I think that history had an influence here. In the early days of Java, the J2SE set was not that rich. External organizations came up with very useful libraries. Today, however, the Java API itself (well, everything starting with java.) it very rich. In my opinion, it contains more than enough utilities for String operations, logging,…

Keep it simple, keep it standard. Keep it Java.

Performance in Remote EJB’s

In a number of projects, we have to use @Remote EJB's. There are pros and cons for using @Remote EJB's, but in some cases the pros outweigh the cons. At least in GlassFish, you can boost the performance of remote EJB's relatively easily.

In case the client is in most cases running in the same VM, you can instruct the EJB container in GlassFish to pass values by reference where possible. You have to create a sun-ejb-jar.xml file in the META-INF directory of the ejb-jar, and in the entry describing the ejb, you have to add

 <pass-by-reference>true</pass-by-reference>

For the full syntax, see https://glassfish.dev.java.net/javaee5/docs/ADG/beaqi.html

Is this the most clean way to do this? Probably not. I'm not going to win the prize for the cleanest performance improvement. But important, it won't break Java EE compatibility, since it is not in an official Java EE deployment descriptor.
And at least for me, it works great.

Testing web projects with Selenium

Actually, I already heard about Selenium in another session, where it was presented as a way to help debugging Java Web based projects. I wrote it down, and wanted to download it when I noticed that there was another session devoted to Selenium.

It is not yet clear to me how the different parts of Selenium relate to each other, but at least I could already use it. I installed the Selenium IDE, which is an extension to Firefox (if you go to Tools – Add-ons, you should be able to find and install it).
That extension allows you to "record" your behavior on any website. The recorded behavior can be played again. But more interesting to a developer, the actions that were recorded can be exported in a number of languages, including Java.

If you install the Selenium Server (http://selenium-rc.openqa.org/download.html), you can create a test-case around the recorded behavior. The actions that you performed on the website can then be initiated from the Java test program, and a number of methods exist for manipulating and testing the actions and results.
I think I am going to use this for automated regression testing, although it requires a lot of discipline while working on web pages (i.e. give names or classes to divs).

Many thanks to the Selenium developers, this is a great tool!

MSA at JavaOne

Yesterday, I attended a number of sessions on MSA (Mobile Services Architecture). I didn't hear big announcements, I didn't see real flashy demo's, but the important message is that devices with MSA are shipping right now.
This is great news for Java Mobile developers. It has been a long and painful track, where developers had to develop using vendor-specific API's, not knowing whether their applications would work on other phones. With the first release of MSA, a number of profiles are being defined (the word "profile" is back: I heard this in a number of JavaOne presentations) .
When you use the full MSA stack, you can leverage e.g. the Location API (JSR 179). A number of JSR's are not available in the subset of MSA, but at least the specification is now very clear on what is expected from phones that claim to be compliant with MSA or the MSA subset.

Meanwhile, MSA 2 is being specified, but don't expect anything soon.

How to organize developer communities

I prefer to attend technical sessions where I can learn technical things, but there is a good reason why I attended two sessions about building a developer community. My company LodgON made our DaliCMS Content and Community Management System available under the Apache Open Source license.

Managing an Open Source project requires more than just making the code available. You need documentation, and a community that facilitates development. Recently, DaliCMS became a GlassFish incubator project, and it is available now at http://dalicms.dev.java.net. Being part of the Java.net co mmunity is something important to me. It shows our commitment to Java in general and to GlassFish in particular.

At LodgON, we know that we have a lot of work to do on the organization of the DaliCMS developer community. We also have to simplify and clarify the build procedure. We will do that, and more code, examples and documentation will be added to the dalicms.dev.java.net site. Meanwhile, people that are interested can have a look at the current site at dalicms.org, or drop us a mail at info(at)dalicms.org.

Bringing designers and developers together with JavaFX

Although tools like NetBeans provide tools for constructing e.g. JSP's in a rather graphical way, it is very unlikely that web designers will use these tools. Designers typically want to use tools like Photoshop and Illustrator. In a number of projects, I have seen the graphical team delivering a number of images, that were then integrated in JSP's by the development team. When new versions of the images are delivered, they often have to be re-integrated in the JSP's.

This is not completely solved by what I saw yesterday, but there is hope. A designer was working on a Photoshop file, and a developer was working on animations with JavaFX. They used a plugin for Photoshop (also available for Illustrator) that allowed the designer to export the design for JavaFX. It required a USB stick to transfer the files to the developer's system, but once it was in the right location, he could use the different layers of the design as separate objects, and apply transformations and functionalities to this.

This was only a very basic integration, but at least it shows that the problem I often encounter (designers and developers using completely different tools) is recognized, and I do expect more work will be done on this topic.

CommunityOne impressions

The border between JavaOne and CommunityOne is not completely clear to me. Lots of Java technology is currently Open Source and is
developed inside communities. The combination of open source, open development and Java is not a marginal phenomenon anymore.
There was a whole GlassFish track at CommunityOne. During the JavaOne conference, there will be more sessions on GlassFish though.

Important to notice, however, is the growing attention for CommunityOne. If I understood it correctly, there were 3000 attendees compared with 2000 last year.
It is not always clear how projects in a community should be organized. Who is allowed to do what? How do you find contributors for your project?
How can you maintain quality? These are typical issues in software development, and the Java Community world should address these as well.

More specifically, it is a challenge to encourage developers to spend some time on an open source java project that doesn't generate immediate revenues.
Large companies can address this more easily: if they allocate one person on an open-source project, it doesn't have a big impact on their organization.
For smaller companies as LodgON, however, this is more tricky. Assigning one person full-time to an open-source project, has a big impact on the ongoing projects and operations.

In the end, we all expect that working on an open-source project somehow
generates revenue, it can be cash or recognition or something else.

 

 

First day at JavaOne

I went to the GlassFish Unconference today at the Moscone Center. This is a prelude to CommunityOne, which is a prelude to JavaOne. Well, maybe it should be the other way round since the level of interactivity is very high at the unconferences. I had the opportunity to have some discussions with the spec leads for the different parts of the GlassFish project. It is interesting to see that GlassFish is currently much more than just the reference implementation of Java EE 5. Besides being the reference implementation of the forthcoming Java EE 6 specification, it has its own life and ambitions. A more modular system, with an OSGi framework in the heart, and with a number of distribution builds, to name a few.

I am pretty confident in the future of GlassFish. It is open-source and cleverly written. The OSGi integration has only started, and may become a very interesting opportunity for developers that want to write code in the OSGi way.

Stay tuned for more JavaOne news.