In my last blog entry, I shared some personal opinions about Java annotations. To briefly sum up, I think that annotations will be a very powerful weapon in the developers' arsenal and that mishandling them will lead to counter-productive and most probably disastrous development conditions. Another remark was targeted at some people (like Cédric Beust and others) who were willing to give the opportunity to developers to override annotations even though the latter had not yet made it into the mainstream development process. As I said, I think the idea is worth some research but it sounds to me like they want to make two steps at a time. Personally, I would find it much more prudent to first observe how people use annotations and then devise ways of improving their use if needed. Anyway, I wrote my last blog after reading Cédric's proposal and I actually wanted to give him some feedback as he kindly requested. Due to time constraints, I restricted myself to write some comments off the top of my head, without giving the appropriate feedback as intended. He legitimately reminded me in his comment and I thank him for that. So, I'm sharing my thoughts here. Actually, I will also comment on Bill Burke's solution since he and Cédric are both working on the same interesting problem. I can already admit that I would more easily go with Cédric's solution than with Bill's. I will elaborate why below.

On mixing Java code with XML (Bill)
Cédric states that he does not really like Bill's solution which partly consists of putting Java code into the XML deployment descriptor. I agree with him but not for the same reasons. Cédric is complaining that when renaming methods in the Java code we have to do the same mechanical and error-prone task in the deployment descriptor. Actually, Cédric's solution suffers from the same problem. If we rename the methods in the Java code, we will also have to remember to change the value of the "names" attribute in the <method> element. This problem is actually not really solvable since both Cédric and Bill advocate for having a separate file when overriding annotations. Since the Java code and the ad-hoc XML file (deployment descriptor or "annotation overriding" file) have to be in perpetual synchronization, it is unavoidable that both sides have to be updated somehow. This has always been a big debate anyway, but I tend to prefer not to write verbatim Java code within XML files. As Cédric said, this very much hints at a design smell even though the JBoss folks have found this practice to be quite useful according to Bill. I actually find Cédric's solution to be more elegant and scalable than Bill's since Cédric does not require to write Java code in his XML file, merely some method names and fully-qualified types.

On space-separated names in attribute values (Cédric)
I personally strongly dislike this practice since doing so removes the whole semantical meaning of what the attribute actually contains. Ideally, each method name should be contained in a separate element as it is currently done with the <method> element in EJB deployment descriptors. Of course, this is very verbose, but hey, this is what we get when using XML, so we just have to deal with it. If we really want to use XML, we have to use it at its full potential and not by taking some shabby shortcuts. In my opinion, people shouldn't explicitely write those XML files themselves, instead vendors should provide tool support for that (e.g., as proposed by Laurent Etiemble), so it doesn't matter if we use one, two or ten XML elements for capturing some method names. Computing power is becoming cheaper everyday, remember? I personally prefer to deal with reasonably verbose XML files than with some hybrid file resulting from crossbreeding Java with XML.

On whether the deployment descriptor is suitable for containing annotation overrides (Bill)
Bill would like to simplify the annotation overriding/insertion process to a maximum. To this end, he proposes to write the Java annotation code directly in the deployment descriptor and to use method signatures instead of verbose XML element graphs for identifying the constructs to be annotated. The intended goal is praiseworthy but we just discussed about the issues surrounding the tight coupling between Java code and XML. Bill also proposes to completely separate business logic from infrastructure code by EJBizing POJOs with XML. This materializes the last two goals of his proposal, namely that "XML should be a viable replacement for any annotation of any J2EE component" and that "annotations should be optional and not required for any J2EE component". Well, I don't know what to say except that this really doesn't go in the same direction the EJB 3.0 expert group is willing to take. What I find most strange in Bill's solution is that the advent of annotations is supposed to allow us to finally get rid of deployment descriptors. And what does he do? He stuffs annotations in the deployment descriptor!! Moreover, why do we find/need vendor-specific annotations in the same deployment descriptor as the rest of the standard stuff? What will happen if we want to deploy the same bean in another container? Rewrite the deployment descriptor and run the risk of maintaining as many deployment descriptors as vendors on the market? No thanks, let's learn on the past and don't make the same mistakes in the future. To Bill's defense, I'm quite sure (and I really hope) that the solution he presented is a very early first pre-draft version and that he will actually take care of all these small issues.

On whether we should be able to insert annotations and not just override them (Cédric)
In the current EJB specification, the Deployer is required to ensure that meaningful values are assigned to all environment entries before deploying the beans. For this very reason, I think it makes sense to allow annotation overriding. The current specification also states that the Deployer might modify/insert new elements when deploying beans (transaction attributes, etc) in case the bean provider and/or the application assembler failed to do so. For this reason, I would tend to be in favor of allowing deployers to insert new annotations when they are about to feed beans into the container, and I thus also agree with Bill's second goal ("Any annotation should be insertable/declarable through XML"). Whether this should occur through XML or not is another debate, though.

To summarize, the community wants to leverage annotations for simplifying Java development and we already see very controversial solutions. Bill's proposal takes the worst of both worlds by putting literal Java annotations within deployment descriptors which were initially intended to be eliminated thank to annotations. I don't quite see the benefit of his approach even though there might be one. I hope he will clarify his thoughts in the near future for the benefit of the community. Cédric requires the creation of a new ad-hoc XML file that would contain the declarations of annotation overrides as needed. Both approaches have their advantages and shortcomings. In the current EJB specification, we use the deployment descriptor for declaring/inserting/modifying infrastuctural parameters. As we will replace these descriptors with annotations, we will need to have at least the same functionalities as we had with descriptors and that's why people need to be able to override annotations. Time will tell whether replacing deployment descriptors (and home and component interfaces) with annotation facilities is a good thing or not. In my next blog, I will provide a comprehensive comparison between what developers have to write using the conventional EJB practices with/without XDoclets and how this will/would change with annotations. Stay tuned...

Whether you like it or not, annotations are making there way into the Java language. The EJB expert group has identified the potential gain annotations could bring to EJBs by devising new ways of developing enterprise beans using one single file that would contain all the necessary information needed by the container to make the bean work properly. The goal of the new spec is to simplify the development of EJBs by eliminating the hassle of explicitely having to create home and component interfaces as well as deployment descriptors. While this somehow makes sense, I have already exposed my views on the subject in a previous blog entry.

Today, Cédric Beust proposes a mechanism for allowing future developers to override annotations at deployment time. In my opinion, the idea is worth spending some time on it. What puzzles me somewhat is that Cédric proposes to specify all the overriding behavior in... an ad-hoc XML file that could be loaded dynamically by some AnnotationOverrider. Sorry but this smells big time!!

I'm aware that overriding annotations would only have to be done in few special cases and that not everybody would have to use that mechanism, but having to specify the overriding mechanism in an XML file would somehow defeat one the primary goals for which annotations have been brought up in the first place, literally "to replace the various ad hoc metadata facilities in use today".

What I see coming is that people will start consuming annotations as they consume normal Java code and their source files will end up being incredibly cluttered with both code and metadata, which I legitimately called the "annotation hell syndrom". This will inevitably lead to unmaintainable source files, exactly what the solution was originally supposed to prevent from happening.

Although not always ideal, the original idea behind deployment descriptors was viable as they made it easier to assemble/deploy/redeploy enterprise applications without having to rebuild the whole code base. In the future, we will have to rebuild/deploy the whole stuff whenever someone changes metadata since annotations will be tightly coupled with the code they describe. I don't reject annotations, I think they can be very powerful, I'm just skeptical about whether we will be able to use them correctly or not.

Again, I think that tool builders have some homework to do in order to provide developers with cutting-edge tools that hide much of the complexity related to the issues I mentioned. If tool builders fail to create new tools that help developers manage this complexity, we will have a hard time developing complex applications in the future.

Yesterday, I read Devx's article on Java Dynamic Proxies and how they can help you achieve AOP. This morning Sam Newman is commenting that Dynamic Proxies and AOP are two completely different things.

I partly agree with Sam's comments. Although, I would like to elaborate a little bit on why Devx's article is not that far off the truth. The author might not have found the proper words for communicating her thoughts, but this is another debate.

In order to understand why Sam's statements are neither completely true nor wrong, it helps to know what the fundamentals of AOP are. Basically, the AOP paradigm mandates the following three main concepts:

• a join point model that provides support for explicitely identifying hooks in the system where aspectual behavior can be added
• a means for modifying the static structure of existing system artifacts
• a mechanism for encapsulating crosscutting concerns within first-class constructs

Any respectable AOP framework should provide concrete means for implementing those concepts. For instance, AspectJ realizes those concepts with, respectively, the pointcut/advice constructs, the introduction mechanism and the aspect construct. AspectWerkz provides a 100% Java AOP solution with normal methods (+ attributes @Before, @Around, @After, @Expression), static inner classes (+ attribute @Introduce) and normal Java field (+ attribute @Implements) wrapped within normal Java classes (+ attribute @Aspect). I won't go into each and every framework available, but this demonstrates that they all have their own way of implementing AOP concepts. JBoss uses dynamic proxies as interceptors for hooking up aspectual behavior to existing code. EJBs use dynamic proxies for hiding the communication layer complexity from the application layer. In clear, dynamic proxies are clearly one solution (among many) for separating (some!) crosscutting concerns from the business code and this is where I agree with Sam in that he says that dynamic proxies are a means to an end.

The fact that AspectJ doesn't use dynamic proxies doesn't mean that dynamic proxies have nothing to do with AOP as implied by Sam. AspectJ is just an AOP implementation that happens to be somehow one of the most famous and most supported implementation out there. Too many people think that the equation "AspectJ = AOP" yields true, which is just plain wrong since they are conceptually at two different levels. It is my opinion indeed that the AOP paradigm somehow "suffers" from AspectJ's view of AOP and that when people talk of aspects they somehow unconsciously think of it in the AspectJ sense, which might not be AspectJ's fault of course but more a problem of how it has been and is being marketed.

Moreover, the fact that dynamic proxies have been around before the AOP paradigm itself doesn't mean that dynamic proxies have nothing to do with AOP either. Similarly, the wheel has not been invented for cars exclusively and the notion of a wheel has nothing to do with the notion of a car. Car constructors have just identified the wheel as an ideal existing solution element for moving cars around. Again, dynamic proxies are one solution that existed at the time AOP people needed to implement certain AOP concepts and that's all!

To sum up, please do not mix up things whose roots and foundations lie at different levels. In clear, compare what is comparable.

I finally got to read something official regarding the standpoint of Microsoft towards AOP via Dion Almaer's blog this morning. Thank you Dion. Gates' stance somehow clears things up and kind of provides answers to my previous questioning and incertitude. Thanks Bill Let's wait and see what unfolds...

As mentioned in a previous blog entry, Microsoft seems to be very discrete about their interest in AOP, if ever such an interest should exist. I was recently browsing on the weblog of Eric Gunnerson, Program Manager on the C# team at Microsoft Corp. and saw that he attended the JavaOne conference (+ here), following the "Know your enemy" principle. Eric writes:

"I attended several sessions on AOP. It’s still a fairly divisive topic – there are definitely powerful capabilities available in AOP, but my opinion is that the long-term maintainability of code with AOP is likely to be poor, especially as more than one aspect is involved. Similar to design-time annotations, code using AOP does more than it says it does."

Prior to the conference, he answered in one of his recent blog entries an apparently often asked question about whether the C# team had any plans for supporting AOP any time soon. The current "official" answer is NO. Eric says that they have not yet identified scenarios that would justify such an addition to the language. On the following day, he blogged again asking people for examples of scenarios where AOP would make sense. Eric got plenty of constructive comments, such as Apolon Ivankovic making up a tentative example of how AOP-fied C# would look like, and Sebastian Lambla, aka 'The Technologist', providing some interesting views on the subject.

This kinda provides an answer to my previous question and somehow shows that Microsoft people are definitely somewhere in the arena watching industry and academic actors evolve on the AOP scene. Yet, one might wonder whether this predator behavior is deliberate or not...

When some big corporation's educational services announces the release of a new certification exam, you can be certain that the Whizlabs team won't be that far away. After many successful simulator releases in 2003 and before (SCBCD, SCJP 1.4, etc), Whizlabs now wants to make you MAD (that is, a Mobile Application Developer ) by complementing their product suite with another exam simulator for Sun's new certification exam targeted at the Micro Edition of the Java 2 Platform (J2ME). Whizlabs' simulators essentially pursue the following goals:

1. to provide a huge question bank in order to best train the exam taker, and
2. to closely mimic real exam conditions.

Basically, the user interface hasn't change much compared to what I have experienced with other simulators from Whizlabs' product line. While some display bugs have been eliminated, a few ones are still on the edge eargerly waiting to be terminated. Furthermore, when looking back at Lasse Koskela's review of their SCJP 1.4 simulator last December, it appears that Whizlabs has done much of its homework:

• I haven't experienced any problems during the installation process, and
• the code is well indented (even though monospace font is still not used for displaying code snippets.)

Moreover, I have to admit that I have specially liked the way Drag-n-Drop questions have been implemented. They are even better than in the real exam since after you have answered a question you can reopen the Drag-n-Drop box without having to answer the question again. This is, in my opinion, one of the big limitations in Sun's certification exam software. Actually, as most of you, every time I take a Sun certification exam, I have to write down my answer to a Drag-n-Drop question before closing the dialog box, which is a little annoying.

Regarding the content itself, you will find a total of 490 questions evenly distributed across 5 mock exams (68 questions each) and 1 quiz (150 questions). You can even create your own mock exams with the built-in test customizer that allows you to select any questions in the bank to help you focus on a specific area of your choice. Besides, all questions come with very exhaustive explanations and links to sections of the relevant specifications. Once you finish an exam you are offered the opportunity to review some answers you were unsure about or to directly go to the exam report and see if you have passed or failed. On the reports you will find a good deal of very comprehensive information. For each question, you will be able to see the objective to which the question relates, the level of difficulty, the type of the question (i.e., multiple choice, DnD, fill-in, etc) and whether you answered it correctly or not. Wait, that's not all!! The help menu will direct you to a complete user guide and some help content on how to use the tool itself. As always, Whizlabs has also bundled a Tips'N'Trick cheat sheet and quick revision notes for you to read just before taking the exam. On the downside, it's just unfortunate that you can't print out these helpful notes from the tool and take them with you to the test center to do some last minute brush up... Maybe, they'll consider adding that to future versions of their tools. Who knows...

A cool new feature has been added to the simulator: If you ever have a doubt about a question or an explanation or if you want to report some problem you experienced, you can do it by clicking on the "Discuss it" button and you will be forwarded to a dedicated SCMAD forum on Whizlabs website. Once you have logged in, you will just have to write your message. Of course, a live Internet connection is required in order to take advantage of this feature.

Finally, I think that this new exam simulator is well worth the money spent ($79.95 for new customers and $63.95 for existing ones) for the reasons enumerated below:

• The simulator is very efficient and is of great support for exam takers
• You get free upgrades for 6 months
• You get free technical support from the authors
• There are very few SCMAD mock exams out there yet (check out this link)
• And... (drum rolls) You'll get your money back if you don't pass the exam anyway

Don't hesitate to download the free trial edition to get a feeling of the exam simulator before buying it. I definitely recommend this outstanding resource to any respectful J2ME developer willing to tackle the SCMAD exam.

Resources
Whizlabs homepage
Whizlabs SCMAD exam simulator
SCMAD Certification Primer

This review has also been published at Javaranch.com.

JavaOne once again brings its load of cool stuff about the numerous Java technologies. Among this year's highlights (EJB 3.0, JDO, AOP, etc), we can find the Looking Glass project which aims at "bringing 3D windowing capabilities to the desktop to offer a far richer user experience for work and play".

On TheServerSide.com, Dion Almaer posted a thread announcing that Looking Glass had been open-sourced for developers to contribute. I have been following the ongoing discussion very closely and I would like to share my opinions on this matter.

Henrique Steckelberg expresses his scepticisms regarding whether it would be a wise idea to redefine the way we interact with computers by making a parallel thought with cars. He asks whether it would be smart to change the "user interface" of a car... While I partly agree with him, I can't help but ask myself whether cars will still have the same user interface 30 years from now... "The 5th Element", anyone? The fact that something is built in some way today doesn't mean that it won't be built another way tomorrow. If things are the way they are today, it is not because it is the best the way to build them, but more because we lack the technologies to build them in a better way.

The same reasoning can be applied to computers. Everybody knows how current operating systems look like: a 2D screen, a virtual 2D desktop, some icons on it, some menus, a keyboard, a mouse, other pointing devices, etc. When windowing systems were invented, there was no 3D technology around and the only physical devices we had to interact with computers were keyboards and mices. Pretty cool for that time. Still, my opinion is that since we are constantly immersed within a 3D world, it should be more intuitive for us to think, act and manipulate abstractions in a 3D world than in 2D world. I say "should" because this is unfortunately not the case. Not yet! We have been forced to evolve within a 2D world when interacting with computers, not because it is better for us that way, but because we had no 3D technology when PARC invented the first windowing system for their Smalltalk environment more than 30 years ago. I could bet that if that had been the case, operating systems would be much different as they are today, maybe a little like what Looking Glass proposes. Of course, I have absolutely no proof of what I advocate for, but in 20 years a lot of things can happen given the exponential nature of the technological evolution curve. Let's see how things will be in 20 years :)

Looking Glass is trying to bridge the gap created by the technology shortcomings we had in the 70s. Looking Glass is just one example of how a 3D desktop can look like. Microsoft is also doing research in this field. Have a look at their project called Task Gallery and you'll see that Looking Glass is not that far off the path. You'll even be able to find similarities between both.

3D has becoming a reality. 3D screen prototypes (Holographic TV, etc) only exist in labs but people like Harold Garner are striving to make this a reality. In my opinion, the biggest challenge is not to develop 3D environments but more to create innovative peripherals that will allow us to evolve within those environments. I fully agree with Cedric Beust and others that evolving within 3D worlds is a hassle for users. But I also agree with Oleg Mikheev that this fact is only due to the limitations of today's peripherals, I'm pretty sure the future can (and will) be different. This all depends on how well 3D desktop creators and peripheral companies can work together. This is no pic-nic, I admit!

Let's move on. Matthew Wilson asks how the wonderful tree abstraction for classifying files could be further improved by 3D environments. Well, Matthew makes a perfectly valid point. There is one small problem, though. I think everyone has already experienced a situation where she needed to classify a file but figured out that more than one directory would be a potential parent for it. That's one of the reasons why shortcuts (or symbolic links if you prefer) have been created. The problem arises when you need to move your files around without updating (all) your shortcuts. Agreed, this is not completely the fault of the tree abstraction itself, but more its bidimensional nature. In the same vein as Bill Coutinho, I think a 3D tree abstraction could much benefit from what topic maps, RDF and other similar technologies have to offer, but I'm digressing, this is another debate.

To sum up, I think that Looking Glass will certainly make its way through and that some other 3D desktop projects will be incepted in the coming years. One of the problems being that such projects will strongly depend on what peripheral companies will put on the market. But again, this is a chicken-and-egg problem, as such companies don't waste resources for inventing things for which there is no demand. Apart form that, I think the success of future 3D windowing systems might come from the fact that we increasingly have more and more information to deal with at the same time as Bruno Girin mentioned. As soon as you need more space on your 2D desktop you buy more screens, and thus, you clutter your physical desktop. So instead of cluttering the physical third dimension, why not try to expand the virtual one? On another subject, my last wish would be that Sun folks change the project name to something more sexy than "Looking Glass". It always helps to have some cool name to mention when evangelizing a technology. Hearing "Looking Glass" doesn't raise any kind of emotions in me!