Michael Nascimento Santos's Blog

Community Archives

Final JavaOne report

Ok, so after a long trip home, I finally managed to write the final installment about JavaOne.

In the morning, I attended Gavin King and Bob Lee's talk about Web Beans. The coolest thing about Web Beans is actually its dependency-injection support and the rich lifecycle model they are proposing. It is actually a merge between Seam and Guice strategies. It would be applicable to any kind of application, not only web-based, so my question was if they intended to split the spec so these features could be used, well, anywhere. They like the idea, but it is too soon to say. Let's hope they eventually do it. Watch out, Spring!

Then I attended the Effective Java Reloaded session. I haven't attended the 2006 session, but a few folks said it was too similar to last year's talk. I've already applied - and advocated - many best practices suggested during the talk, specially making everything final. By the way, Gavin, Bob and Joshua are great speakers and members of this group were in short supply this year. Sigh.

In the afternoon, I've (accidentally) spent some time with some NetBeans guys. First Roman Strobl:

I've told him a little bit more about my NetBeans pledge (expect a follow-up post about it). Then I came across Geertjan again, that showed me his musical notepad (you can find it at nbjfuguesupport). Guilherme Silveira was passing by and decided to make a video about it. He posted the first part in YouTube and hopefully he will upload the second part soon.

After that, I've attended the last few minutes of the session named "Stress Your Web App Before It Stresses You: Tools and Techniques for Extreme Web Testing". It was quite packed and it seems people liked it a lot. So, no need to be worried, Felipe!

Basically I spent most of the time in the afternoon and early in the evening. Then, I was at the Java Champions BOF. Java Champions are recognized by Sun as leaders inside the community. Some of them are Kathy Sierra, Bruce Eckel, Joshua Bloch, Neal Gafter, Jason Hunter, Calvin Austin and even myself. It was good to meet some of them and also to meet the program coordinator, Aaron Houston, a very nice guy.

Finally, it was show time: our BOF about JSR-310, Date and Time . As noted by Timothy O'Brien, the number of people who attended was impressive. Her is a partial picture:

We showed a few slides and some code Stephen started working on recently; we expect to commit this API to SVN soon. The audience made interesting comments and questions during the talk and after it - we had to stay there for almost an hour after our talk to address all questions. Some spec leads for JSRs that will make it to Java SE 7 were there and showed they intend to use our work and to support it. So, JavaOne selection team, keep it in mind for next year: date and time is a hot topic.

Once I had completed my main mission, I had a meal with some other Java Champions/JUG Leaders in a nearby restaurant. It was quite nice to meet these folks, shall I say.

From Thursday, I would like to highlight the excellent JFugue talk delivered mainly by David Koelle and with special guest star Geertjan Wielenga. David is a terrific speaker, his work is amazingly cool, his demos rocked and he managed to be funny. Geertjan also deserves congratulations for focusing on the main topic, JFugue, instead of just pushing NetBeans. Of course he mentioned his application was NB-based, but he actually focused on demonstrating how JFugue was simple to use, which just makes more people interested in his application and, well, NetBeans. So, another note to J1 selection team: we want more music-related talks, preferably with David!

Fabiane Nardon and Daniel Lopez's BOF, Designing Self-Evolving and Self-Configuring Java Platform, Enterprise Edition (Java EE) Applications, was also quite interesting and attended by several Java Champions. Nice job! The BoF I've attended after it was one of the coolest sessions in JavaOne: The "java.lang.OutOfMemoryError: PermGen Space" Error Message Demystified, presented by Frank Kieviet and Edward Chou. I couldn't believe they could actually spend 50 minutes talking about this topic with valuable information, but they actually did it. Having done a lot of profiling and OOME chasing before, I must say I could not explain the issue better. You must be on the Rock Star Speakers list for this year.

Fabiane and Edgar's session on Friday was very successful as well and Linda deMichiel and Kenneth, from JPA 2.0 and EJB 3.1, came to them after the session to look for input for their specs. Joshua's Puzzler session was really cool as well.

So, it was nice to meet everyone I didn't know in person before and to talk to all of you I've already known. See you in JavaOne 2008 (if any of my submissions is approved)!

Tuesday BOFs

So, let's proceed with my JavaOne report. I've attended the Meet the Swing, AWT and i18n Teams BOF, mainly because Sun's representative in our JSR would be there. We - Stephen was with me - met him and another Sun guy who works in the util & i18n team. They are nice chaps and I regret not taking a picture with them. Maybe I will fix that later this week :-)

Then I went to Neal's talk on closures. Basically what he said is what he had already made public on the internet, so there was nothing new. One thing I asked him about is if he considered restricting the usage of closures, so people don't use closures for cases it doesn't make sense, perhaps member variables. Neal said he thinks if people are using it for something that way, they probably know what they are doing; I guess he never worked as a consultant in his life :-) Just kidding; in the end, I actually agree with Neal, but I am sure people will shoot themselves on the foot.

Finally, I moved to the final talk in the evening, about Java Programming Language Features in JDK Release 7, with Alex Buckley and Peter von der Ahé. It was really cool to hear from the source what is the process they use for considering language changes and to hear about some of them, including operator overloading. While I am somewhat concerned about it - and so are they, it seems -, I think it would make the Date & Time API much clearer and easier to use.

I've also asked Alex about method/field literals and he said I should probably create a Kitchen Sink Language project implementing them, along with a spec, so they can evaluate it. Maybe I will find the time, maybe not... Let's see :-)

So, wait for my Wednesday report :-)

Tuesday afternoon

So, after hearing from Danny Coward that our JSR is being considered for inclusion in Java SE 7, I came across Neal Gafter:

Neal has contributed many things to the Java community while he worked for Sun and now he is one of the guys behind of the three closure proposals and has provided some input to our JSR - believe me, a few people need support for things you probably haven't ever heard about, like leap seconds, or that you don't fully comprehend, like femtoseconds. So far, our focus is just to get things right and working and Neal agrees with this approach.

After that, I went to the java.net booth and talked to some of the java.net crew, including Marla, Sarah, Daniel Steinberg and Chris Adamson. Here is a pic with Daniel and Sarah:

I've also met Geert Brewin, the guy behind RIFE and continuations:

We talked for some time and hopefully I will be able to help him getting a JSR about continuations started.

Then I attended Bob Brewin's general session. There were a couple of cool things he showed, including the super extra cool NASA World Wind, which has a Java API that can be integrated in your application and works pretty much like Google Earth. He also demonstrated Iris, which is photo editing software for the web, implemented as an applet.

Then I went to the talk about JSR-296, the Swing Application Framework. I am part of the expert group, so I was actually more interested in the tooling provided by NetBeans. I liked it quite a lot; Joshua did a great work, for sure. Hopefully I will be able to adapt some of his work to provide better support for genesis.

The last talk I attended in the afternoon was the EJB 3.1 talk. Here is a list of things (that I can remember) they're considering:

• Eliminating the need for business interfaces
• Allowing EJBs to be packaged along with web components (in a war)
• Creating an asynchronous model, including bean-managed synchronization (using synchronized)
• Adding singletons
• Improving the timer service, so a timer can be created when an EJB is deployed
• Supporting stateful webservices

For the timer service, they are considering some sort of a cron-like service. I've talked to Kenneth after the talk since I think they might find the new Date and Time API useful for these improvements, so let's see what happens.

Well, that's it for now. I know I'm significantly behind, but hey, I have to actually attend the talks and get some sleep ;-) And don't miss our BOF tonight (Wednesday), at 9:55PM!

Everyone is a Brazilian

During keynote this morning, John Gage has said his classic opening sentence again: this week, everyone is a Brazilian. Hey, I am one, so if you come across me during the event, I can probably teach you something ;-)

So, to the real meat (I am a vegetarian, by the way, but you get it): Sun has announced that open-sourcing Java has finally been completed. You can go to OpenJDK and download the full source code for the JDK.

Rich Green also told us they will make Java much faster and that there will be a Java SE distribution for consumers which is modular and starts much faster.

Another cool thing is JavaFX. It is a set of technologies used to build rich client applications. Think of it mainly as the Java alternative for Flash. Part of JavaFX is JavaFX Script, a new script language targeted at making the development of this kind of applications easier.

There is also something called JavaFX Mobile. It will allow every Java SE API to be available on phones, as well as supporting Java ME applications. Basically, Sun wants to provide software for the next generation mobiles.Other things happened during this session, but there is no time to tell everything :-)

After the session, I went to the Java SE: Present and Future talk. Danny Coward talked about the JSRs that are being considered for Java SE 7 and I was pretty happy when our JSR was mentioned as one of them.

There is a lot more going on, so stay tuned...

Monday afternoon at JavaOne

After being disappointed at the Matisse session, I decided to go seeing what folks were doing at Redmonk. Well, the unconference was interesting and there were discusssions about scripting languages, invokedynamic and several, several other matters. I reviewed Stephen Colebourne's airplane hack - that he had improved at that time - and made a suggestion to get fewer classes that abstract the period concept. Have I mentioned we will be presenting a BOF, A New Date and Time API for Java Platform, Standard Edition (Java SE), next Wednesday, 9:55 PM, and that you should add it to your schedule? :-)

At the closing session, James Gosling showed a lot of cool applications built using NetBeans and Bruno Souza called the NetBeans Dream Team to stage, which includes two Brazilians: Vinicius Senger, from GlobalCode and Edgar Silva from JBoss. Here is a picture:

Finally, there was a party and besides meeting a nice Brazilian who works as a VP of software development for JP Morgan, we (Yara, Vinicius and I) have talked to Michael Keith, co-spec lead for EJB 3.0 and what to expect from the future:

So that was it. Hopefully I'll blog about today's morning in a few minutes :-)

JavaOne 2007 is about to start

JavaOne is about to start and I've already met some old friends again...

'nough said :-). I've met James Gosling during registration on Sunday. Ok, it is not like he actually remembers who I am without some explanation, but anyway... :-)

I have had a great time since I've arrived here on Saturday. In the afternoon, I had a long chat with Stephen Colebourne, who co-leads JSR-310 with me. We'd never met in person before, so it was nice to find out he is quite a cool guy. We've chatted a little about closures, generics quirks and some fresh code Stephen wrote in the plane that we should show up during our BOF, A New Date and Time API for Java Platform, Standard Edition (Java SE), that will take place next Wednesday, 9:55 PM, so make sure you add it to your schedule.

I've also had a great time yesterday with Vinicius & Yara Senger from Globalcode and Felipe Leme, aka felipeal, who is a long-time friend. We've just chatted about many stuff, including some of the most deceiving people we've came across in all these years in consulting. Maybe we should write a public blacklist somewhere :-D

Anyway, it's time to take a shower, put some clean clothes and go to CommunityOne, most of the time, to NetBeans day. I hope I can finally meet the Matisse/beansbinding guys and say a few things about its binding support before I submit a blog entry about it. It's been almost a year I've tried to reach them without success; hopefully, today it will be different.

I have to say a big thank you to my pals at Summa Technologies do Brasil, the company I work for and that is sponsoring my trip, making it all possible. See you @ JavaOne!

It's high time: a Date and Time API for the Java SE Platform

A few times in the past I've considered writing a blog entry summing up all the problems with Date, Calendar, TimeZone, DST rules and other JDK related classes. If you think these APIs are simple, functional and do not cause any harm, believe me, you really haven't done anything trivial with dates. Besides the classic "days are 1-based, month are 0-based" issues and the lack of many major concepts, such as date without time, any date/time calculation fails miserably when it includes a DST start or end date. There are simply too many issues with the current API to list here.

However, the point of this entry is not to bash the current Java SE API, but rather to talk about JSR-310: Date and Time API. As stated in the JSR, it "will provide a new and improved date and time API for Java. The main goal is to build upon the lessons learned from the first two APIs (Date and Calendar) in Java SE, providing a more advanced and comprehensive model for date and time manipulation."

Our main inspiration will be Joda-Time, a great open-source library originally created by Stephen Colebourne (who will be co-leading the JSR), that you should definitely use today to deal with date and time. We won't simply rename Joda-Time and bless it with the JCP approval stamp. We actually want to learn from it, use Java SE 5 features to design an easier-to-use API, remove all deprecated, complex and not mature enough features and also consider addressing a few issues currently not solved by it.

If you want to help us, join the jsr-310 java.net project and subscribe to the mailing lists. If you think you are an expert on the matter, consider joining the expert group. We intend to run this JSR as transparently as possible though, so your voice will be heard even if you just join the java.net project.

First Java SE 6 bug!

package test;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class FunctionsClass {
   public static boolean xpto(Object arg1, Object arg2) {
      return equals(arg1, arg2);
   }
   
   public static boolean equals(Object arg1, Object arg2) {
      return arg1 == null ? arg2 == null : arg1.equals(arg2);
   }
   
   public static Object echo(Object o) {
      return o;
   }

   public static void main(String[] args) throws Exception {
      ScriptEngine engine = new ScriptEngineManager().getEngineByName("JavaScript");
      engine.put("f", new FunctionsClass());
      System.out.println(engine.eval("f.echo(f)"));
      System.out.println(engine.eval("f.xpto('a', 'a')"));
      System.out.println(engine.eval("f.equals('a', 'a')"));
   }
}

test.FunctionsClass@14a9972
true
true

test.FunctionsClass@14a9972
true
Exception in thread "main" javax.script.ScriptException: sun.org.mozilla.javascript.internal.EvaluatorException: Can't find method java.lang.Object.equals(string,string). (#1) in  at line number 1
       at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:110)
       at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:124)
       at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
       at test.FunctionsClass.main(FunctionsClass.java:24)

The language barrier

Have you imagined how hard it would be to learn and to program in Java if all language keywords, all docs, all things related to Java were written in Klingon? Well, for those who cannot read in English, this is called daily life (those who understand Klingon are not my target audience here).

Most of the talented, gifted young programmers I have known had no clue about English when I first met them. Once you started working with them, you would realize they had't made much progress yet not due to some technical limitation, but rather due to the language barrier. Java keywords made no sense to them, so things that should be natural were hard to learn. Class and method names didn't convey any idea about what they did; they were just hard to memorize. When it came to Javadocs, well, they were just useless. They had to rely on other people's experience and bad translation software to learn about bleeding-edge technology and frameworks. Basically, there were only two possible "happy" outcomes for their situation: either they met a smart senior developer who was able to read in English and that became their mentor or they ended up learning the language, what took several months at best and was not a viable option to all, since some of them did not have the same talent for learning "real" languages or simply couldn't afford a English course (which was needed for some of them).

All this wasted potential has just one cause: the language barrier. It is not really fair to expect people to learn another language in order to become good developers. Learning English and a programming language require very different skill sets and not everyone has both of them. However, this is actually what we expect from these young talented folks. And unfortunately, given our current reality, it is reasonable. After all, how are they supposed to evolve (and to survive) unless they can learn on their own? Hopefully, it seems this situation may change in the near future.

Although we shouldn't expect for a translated version of the Java programming language (nor we would want it, actually), more resources should be available to non-English speakers and, as far as I can tell by observing a few initiatives in the Brazilian community, both the community and Sun care about this issue and are trying to address it.

Recently Sun has provided support (including tools and legal arrangements) to allow volunteers to translate Javadocs to their native language. The Brazilian Portuguese Javadoc translation project, jdk5-api-pt-br.dev.java.net, has already made its first release available . Of course there is still a lot of work to be done in order to have a fully translated copy available and that the need to sign an agreement certainly keep some people away from the effort, but it is a start. I am not involved in this project, but I would like to congratulate everyone who has dedicated some of their time to such a noble goal.

When it comes to articles and tutorials, it is great to see not only an option, but sometimes diversity. In some countries, for instance, there is already more than one magazine about the Java platform, as is the case for Brazil. Great open-source projects, once (and still, sometimes) accused of not having formal documentation, now have translation teams working on their docs. Translated Books become available faster, although quality can be low at times. However, as competent developers who are good at English are now being hired as revisors, the final result tends to improve.

Online book translations definitely take longer, but usually lead to better results. I've founded a translation effort for Bruce Eckel's famous book, Thinking in Java, several years ago (with his permission, of course), and although I am not able to contribute to it anymore, many volunteers keep working on the project, Pensando em Java.

So, what is the point of this post? Actually, there are a few:

• If you are foreigner, change your attitude! Many folks have criticised translation efforts (especially the Javadoc one) because they think it will lead to dumber programmers. The fact is bad programmers will always exist, but good ones now take a lot longer to explore their potential due to the language barrier. As a good developer who wants to work on a great team, you should encourage these initiatives, not the opposite.
• If you have the time, skills and desire, join the translation efforts. You will certainly learn a lot, get to know talented folks and help those who speak your language.
• Recognize the value of original content written in your language, such as magazines and blogs. And, if you can, create original material as well.
• Finally, if you are a developer/commiter/project owner, don't be hard on those asking questions in your lists/forums in a foreign language or even in bad English (worse than mine :-P). Rather try to find users capable of answering their questions on their native language or make specific questions that help you understand what the person wants to know.

When you support those working on making Java easy to learn, no matter what language they speak, you are just strengthening the community. And a strong community will certainly last longer, as well as your current job :-)

PS: for those who speak Portuguese, I've created a new blog at http://blog.michaelnascimento.com.br/.

Para aqueles que falam português, eu criei um novo blog em http://blog.michaelnascimento.com.br/.

JavaBlogs.com.br is back

JavaBlogs.com.br - or Jablo, as some people call it - is a valuable resource to Java developers that can read Portuguese. Although their names are similar, it has little to do with javablogs.com, a service mantained by Atlassian that aggregates several other blogs. Jablo is actually a Roller instance customized for the pt-BR locale - at least, as customized as possible given it is maintained by volunteers.

There were several problems with the site due to bugs in Roller; it would crash and become unavailable for several days, at times. To make matters worse, the company who used to host Jablo for free was about to start charging the site for its services and nobody was willing to afford these costs (traffic was pretty high when it was running fine and the price charged was based on it...).

I got to know all this during an informal chat session with the official Jablo maintainer, Franklin Samir, from PortalJava. It immediately occured to me that Rick Ross, from JavaLobby, could help us. So, to make it short, now JavaBlogs.com.br is hosted on JavaLobby, using their customized, fine-tuned and much more stable Roller installation.

The funny thing is most people are not even aware the site is working, since it went through a long period of inactivity and all of its URLs have changed. This means that, if you were subscribed to any feed from the site, you have to update its address. Basically, the URLs changed from www.javablogs.com.br/blogs/page/user to www.javablogs.com.br/page/user and RSS feeds should now be accessed using a www.javablogs.com.br/rss/user pattern. If you can read Portuguese, visit the site and take advantage of the knowledge shared by the Brazilian community. If you can write in Portuguese, create your own blog there!

Rick is right: join the JCP!

In this week newsletter, Rick Ross talks about the importance of joining the JCP. I couldn't agree more with what he says. Here is an extract:

Sun deserves great credit for its efforts to bring meaningful community into the guidance and evolution of a major technology platform. The Java Community Process (JCP) is one of the most innovative and adaptive tools I have ever seen a corporation devise to allow general public participation in the management of a core technology in which it is deeply invested. The JCP isn't perfect and has numerous critics, as any review of Java websites and blogs will quickly prove, but I still feel it has a great deal of merit and potential.

Some people complain a lot about the JCP, but they don't seem to understand that, if there's something they don't like about it, the best way to change it is to join it! Why should them? Well, Rick proceeds:

• Individual JCP membership is FREE
• Individual JCP members are entitled to vote
• Individual JCP members can run for election
• Individual JCP members can view and comment on JSRs
• JCP members are not obligated to attend any meetings

And what does it take? Rick also touches that:

Joining as an individual member is slightly tedious, but it shouldn't take you very long. All you have to do is download, print, sign & fax the Java Specification Participation agreement (JSPA) as well as Exhibit B of the Individual Expert Participation Agreement (IEPA.)

What seems to have motivated Rick to write this post was the fact that only a few hundred votes were cast in the last JCP elections and that we are, according to sun, 3 million Java developers. So, join the JCP for free right now and help to shape the future of Java technology. Thanks for reminding us, Rick.

More about Practical AOP and Transparent Remoting

I am glad my original post about Practical AOP and Transparent Remoting has received polite and smart comments against it. This is definitely a nice way to get the discussion about AOP going! Here are my answers to these comments.

First of all, cajo said that "this is a perfect example of why I fall into what you call your third AOP viewpoint. As you said, magic happens; but it is also totally invisible from the actual source code. I can't imagine how one would debug a complex application." I am sure this is a reason why many developers are concerned about AOP adoption. But let's address this question to see if this point should prevent us from using AOP.

First, how do you debug such application? If you simply use your IDE "Step Into" debugging functionality and you happen to have genesis sources available, your debugger will stop at the advice's first line. And then, everything will be simple to understand. But maybe the real question is: how would I guess I should step into at that line? To answer this question, we just need to think about how we decide to use step into when debugging our OO applications.

If you have a snippet like:

public void aMethod(SomeClass o) {
   o.someMethod();
}

You already cannot assume you should look for someMethod() implementation in SomeClass in this simple example. Why? Because you might be dealing with a subclass or maybe a proxy. And if SomeClass is an interface and the instance you received is a dynamic proxy, it becomes even harder to debug. So, if there's any chance you're dealing with a polymorphic call today, you already have to guess whether the code being executed belongs to SomeClass or is defined on another class. "Hey, but I don't have to guess; I can use Step Into today", someone might say. And that's just what I said a few lines above. You should use Step Into in these cases to be sure what code is actually being executed. The only new thing with AOP is that it may happen with any method, but it is not different from today.

Besides that, either your aspects should affect well-defined points in your code or you should use a tool. AspectWerkz provides an Eclipse plugin that helps you to see which methods are affected by advices, for example.

Then, cajo proceeds:

Consider operator overloading: Many argued against its inclusion in Java, because it could make the source look less obvious. To me, this source looks far less obvious.

Well, except for String concatenation tricks - which shouldn't exist for consistency, anyway -, I agree about operator overloading because it already has just one meaning. But as I showed above, a method call is already "trickier".

Another interesting response came from jhook. He begins:

I can't necessarily argue with what Michael is trying to accomplish, just in how it's being accomplished. The problem with many of these AOP implementations is that you are modifying the behavior of an object for everyone. The behavior of RemoteClass is intrinsic, adding a client's ability to remote 'helloWorld' is extrinsic to RemoteClass and IMHO shouldn't be applied for all clients of RemoteClass (at compile time).

Some of that's true, indeed. For this specific case, my intent was that every RemoteClass client had to access it through the aspect. But it only affects clients that have access to the weaved version of the class. So, in the server side, we keep a "regular" version of it and no remoting is necessary. This is one approach to actually do what jhook suggested: use the class version you want.

Another approach is to change your pointcut to intercept calls to the method and not changing its execution as the default aop.xml that comes with genesis empty-project does. That's the beauty of AOP: this behaviour is actually extrinsic to the class, since your configuration will determine whether method execution, call or none will be affected by which advices you choose.

The last comment I would like to reply to have been made by ablperez. It says:

A cleaner example of AOP's power would have been taking a POJO and making it transactional. Objects that are remotable should clearly relflect that. This example commits the fallacy "The network is reliable" from the eight distributed computing fallacies. A well defined remotable object should declare to throw a remote exception. IMHO remoting is not something you want to hide.

Well, that's debatable. How would you handle the RemoteException? Rethrow it in every method that calls this class? Write tons of try/catch blocks spread throughout your codebase? A cleaner approach would be to handle it once, in one single place. Since Thinlet - and therefore genesis - already defines a single point for handling exceptions, you can do it once in a base class. However, if you do think it's nice to be more explicit, just add a throws java.rmi.RemoteException to the method's signature and handle it as you wish. The exception will be thrown as you would expect.

It's important to mention that genesis default project structure is targeted to intranet environments, where bandwidth shouldn't be a problem most of the time. Besides that, a timeout aspect is applied to every remote call to make sure it either completes timely or a timeout exception is thrown. So it actually expects delays to happen. The default aspect doesn't do any fancy stuff, such as displaying a wait dialog or something like that. This should be customized on a project basis.

I hope we can keep this healthy discussion going, since I think it just helps the community as a whole. By the way, a new genesis release, 0.2-beta2, is now available. Its documentation is available if you are interested. I'll be saying more about AOP soon. Stay tuned ;-)

EJB 3.0 Early Draft Spec is now available for download

The Expert Group for JSR-220 has just published an Early Draft of the new EJB 3.0 spec. It is available for download at the JCP site.

If you want to know more about JSR related news and to participate in their active development whether you are a JCP member or not, check out the recently launched JSR community.

Welcome to the JSR community

Welcome to our newest community, the JSR community. The java.net JSR community has been created to support the goals of JCP version 2.6 to make the process more transparent. File sharing, news groups, mailing lists and other services are among the services offered to help to achieve these objectives.

Each JSR willing to join this community will start a new sub-project here. There, you will be able to subscribe to public mailing lists that will allow you to know and comment about what topics are currently being discussed by the Expert Group, get updated information about the spec status and know when drafts are available. Besides that, if the reference implementation and/or the TCK are open-source software, you will be able to access them here.

Expert Group Members will be able to take advantage of many valuable resources, such as version control and private mailing lists for internal discussion. By using java.net resources, they'll get feedback earlier and the end results will be better.

This community will also provide you news about the JCP, JSRs and related subjects, as well as support discussions about JSRs and the process in general. We hope you can be an active participant of our community and help the whole Java community as a result. Join us and help to shape the future of Java!

PS: many thanks to the whole java.net crew that has made it possible, specially to Sarah Breen, who has been like an angel to all community leaders.

My talk at FISL and a new blog in Portuguese

FISL is the most important event about free software in Brazil. People from different countries come to attend sessions about free software such as Linux, PHP and others. As Java is starting to get more attention from the open source and free software community, there will be some talks about it in the main track. Besides that, SouJava, the largest JUG in Brazil, which I am proud to help to coordinate, will be featuring a special pre-event called Javali.

I will presenting one of the sessions, called "Simplicidade, Escalabilidade, Testabilidade e Produtividade com J2EE, AOP e Rich Clients", or, for the non-Portuguese speakers, something like: "Simplicity, Scalability, Testability and Productivity with J2EE, AOP and Rich Clients". In this talk I'll show part of the work we've been doing at Summa Technologies to be able to develop robust software with a flexible architecture and still keep our code so simple people who know just plain Java are able to understand it. I'll also talk about how you can get a fast, responsive UI with Thinlet and develop in a way you can rearrange the topology of your application without touching a single line of your business code.

Besides that, I'd like to announce I now have a personal blog in Portuguese, known as Blog do Mister M. It's far more informal than this one and will include pictures of my trips and will be updated much more frequently. Please, read it if you can understand my native language.

Very important things will happen here, at java.net, in a few weeks, so stay tuned in order not to miss it. See you.

BREAKING NEWS: Got Tiger?

I was going to blog about Date and Calendar (and how terrible they are), but these must wait now.

Straight to the point: if you want to get J2SDK 1.5.0 alpha, just go to:

http://www.javalobby.org/members/j2se15.jsp

This is a cooperation between JavaLobby - hey, just became a member 3 weeks ago, after years of Java, can you believe it? - and Sun. This is really a private release, so, you are not allowed to share your opinions about it with anyone except Sun. No, no feedback on this blog or any comments about J2SDK 1.5 alpha are allowed at all. You must be a member of JavaLobby to download it.

Are you still reading this??? Go there and download it now!

Why is everyone talking about grid computing? And what are you doing about it?

"Grid computing" - though it was quite an unknown concept till a few years ago, now everyone is talking about it. Some are saying it is everything we were missing, the next big thing. Others, as some java.net bloggers, are simply skeptical and uncertain about its practical use. But the fact is many huge companies, such as Oracle and IBM, are investing a lot of money on that - and that's a good reason to take a closer look at it.

To begin with, what is grid computing? Grid computing is about spliting your work in small pieces - or jobs, as you prefer - and assigning those pieces to different computer on the network. After they have been processed, you get them together and your main task is done. But what is the big advantage of applying grid computing?

Have you ever thought about reducing the time your Ant builds take to run? What if you could use other developers' machines to run it in parallel while they are having coffee or are out in a meeting? Wouldn't that be great? And what if you could perform parts of a specific transaction in some machines available in a cluster instead of loading one box for a minute when the user could get the response in a few seconds? Those are the kind of things that may be accomplished with grid computing in an easier way.

So, what is the Java standard for grid computing? None. Soon, there will be one and then we will have to accept it, whether we agree with the way it will be or not. If you are among the ones who hate EJBs - I don't, just gave my own suggestions previously here -, or that think that JSPs are a big mistake, stop complaining! Get involved. Talk to the ones who are defining the standard. Go to grid forums, talk to the guys at Sun One Grid Engine, move! Download one of the many implementations available, such as Globus or Sun One Grid Engine, use them, share your thoughts about it! Tell the community what you like and what you don't and why.

Grid computing will be very useful to many people in the future, but if it is not useful for you tomorrow, well, maybe that's why you didn't try to shape its future when you had the chance...

Are you using JSTL as you should?

"Java is indeed very powerful, flexible and scalable, but it is pretty hard to do simple things with it!" " is far more practical to this job than Java" "We should only use Java to more complex tasks" "There is no point in using Java if your product is going to be small" Have you ever heard any of these sentences before? You probably have. And I have to agree some things are just too hard to do using plain J2EE out-of-the-box web components - I mean, using JSP/Servlets only.

When it comes to most web applications requirements, it is been just unnecessarily too difficult to implement simple stuff. But this dark era has come to an end with JSTL.

JSTL is a set of tag libraries, some validators and a cool feature that also is going to be part of JSP 2.0, the Expression Language - EL - which will improve your productivity considerably. Accessing complex bean structures, handling logical expressions, looping through arrays, collections etc., processing XML, executing SQL instructions in transactions and more - all those things are made easy by JSTL. Although some features are debatable - tags that allow you to execute SQL code inside your JSPs, for example - they can be used for some useful purposes - prototyping, for example.

For example, a few weeks ago, someone asked me how hard it would be to connect to a URL, forward a few parameters, read back the result stream and display the data returned to the user. My first thought was to say it would take a few lines of code and a couple of minutes to write and test, but then I remembered the tag from JSTL. Well, it took seconds to write and test! That is a productivity boost! Writing reliable, tested Java code in seconds - that is something your IT manager would like to hear :-)

So, if you don't know JSTL, go to URL above or visit http://java.sun.com/products/jsp/jstl/ if you want to know more about it. Believe me, you should :-).

Another paradigm change is taking place right now...

A few weeks ago, Tesla, the company I work for, sent all its employees to a non-techie workshop. One of the videos that was presented there contained the following sentence: "When paradigms change, everyone gets back to zero". That sentence got stuck into my mind because it reminded me of the OOP-to-AOP transition we are experiencing right now.

The first article I read about AOP and Java was published in 2001. It talked a little about AspectJ, the only (known) implementation at that time. Lots of things have changed since them, but AOP is still being defined. I didn't care much about AspectJ because, sincerely, I didn't like its approach: YALSTR (c) (yet-another-language-syntax-to-remember). And though I kept on reading everything I could about AOP and its intriguing terminology (aspects, pointcuts, joinpoints, introductions, concerns etc.), I really didn't take it seriously. To me, it was just another hype, as webservices are today - unless you are integrating J2EE and .NET, you are probably using the wrong technology to do the job :-) (yes, I am expecting to start a flame with this sentence).

However, through the past 2 years, AOP has being effectively applied. JBoss has been using it for its EJB implementation - and everybody copied them after (don't try to pretend you didn't, application server vendors!). And their implementation is reasonable: no cumbersome syntax nor strange concepts. Pretty simple, useful, straightforward - characteristics difficult to combine. Then some people I know started to use it extensively - especially my friend Carlos Villela. Though I think sometimes my friends are overusing it in their projects, most of the time they're doing things that would be too hard or complex to achieve using a different approach. Carlos introduced me to AspectWerkz, which is a very good implementation of AOP concepts, with a nice and clean approach.

This entry's point is: AOP is a reality. It is useful, but we have to carefully consider when to apply it and when to rely on our old OOP. There are no right ways to use AOP - yet :-). So, before you become a dinosaur and can only find jobs in companies that "still" use the "plain old Java" you are used to, get familiar with AOP. We all got back to zero. Do you wanna lose your senior status? I am using AspectWerkz right now :-P

EJB 3.0 is not ready yet! That's your chance!

If you could change EJBs, what would you do? If you had full power to add features or redesign the old ones, what would be different today? Well, in fact, you have the power to do it, but you need to be fast! JSR-220 is in its early stages and during JavaOne Linda DeMichiel, the spec lead, made it clear she wants to get input from the community.

I attended her session about EJB 2.1 just because I wanted to ask a few questions - which I did -, but close to end of her presentation, I was nicely surprised to see a few slides about what EJB 3.0 may look like. And it looks prettier than today! Her idea is to simplify EJB development by using metadata to automatically generate deployment descriptors and providing superclasses that developers can extend in order to override only the methods they actually want to change. That was great!

Also, she presented a BOF called EJB 3.0 Specification Features Input. I made a lot of comments about it, but here are some suggestions and points I criticized:

• Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.
• Instance-based security: I've never been able to make any meaningful use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.
• Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.
• Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.
• Threading facilities: If know something about the EJB 2.1 draft spec, you may argue that we already have these as Timers. Really? Don't think so. Take a look at the latest proposed final draft for the JCA new spec. That's support for multithreading! We should have some kind of thread pool provided by the container or a Work-like interface. Linda didn't quite like this suggestion, though. What do you think?
• Meaningful names for commit options: Do you know what commit option A means? Those who have some experience with EJB unfortunately do. Why couldn't it be named container-exclusive-database-access or something like it? According to Linda, the commit options were supposed to be just an example, but nearly every application server uses the terms commit option A, B or C as if the difference between them was so clear as between Entity Beans and Session Beans.

The others made some very relevant comments about basic table mapping support and other issues, but all the above were suggested by me. So, if EJB 3.0 happens to have these things, blame me! :-) But that's not the main point in this entry; the point is: make your suggestions and make them now! Take a look at the URL above and send an email to the expert group with your own suggestions. You can still shape EJB's future if you do it now.

A few words about Brazil, Java technology and myself

If you have been to the last edition of JavaOne, then you probably have seen me :-) I was one of the crazy, shameless Brazilian guys who attended the conference this year. No, I wasn't the "Brazilian superman", as one guy who works for Sun named Bruno Souza, our Javaman. :-) But, getting back to the point, there is a lot more about Java development and Brazil than you might know.

To begin with, as Manoel Lemos and Beatriz Leao mentioned at their session, we speak Portuguese - yes, we don't speak Spanish and we are more than 50% of Latin America, what means most latins speak Portuguese! We are the 12th largest world economy and our capital city is Brasilia, not Rio de Janeiro, Sao Paulo nor Buenos Aires (that last one would make some of us really angry :-P) And some national wide projects are entirely or mostly Java technology based. Oh, probably the most surprising fact: our JUGs are the largest of the world! The #1 is SouJava, which I am glad to be part of and help to coordinate.

As this is my blog let's talk a little bit about me: currently, I am working on a application that is going to be used by one of the main industry players here and it's going to control nearly everything they do. My Ant builds are taking ages - ok, 5-7 minutes, but that's ages from a Java developer perspective :-P - and I think our code base is still going to get 5 times bigger! That is what motivated my java.net main project, called AntG. Its main purpose is to make Ant builds run faster by using threads and taking advantage of grid computing. If you are interested, check it out! Give your suggestions and join the project. We are still limiting its scope and deciding how to begin to implement it, so all of you are welcome. Right now, we are discussing everything in Portuguese, since we are all Brazilians, but if you join, identify as a non-Portuguese speaker and we'll do our best to write in a language you understand - as long as it is English or Spanish. :-)

I intend to publish some useful and practical tips here and also to talk about my other projects, so keep checking my blog out.

Regards,
Michael "MisterM" Santos

This work is licensed under a Creative Commons License.