1 2 3 4 Previous Next


51 posts

For the impatient readers I just wanted to announce the release of the Guilder POC which can be found on its wiki: https://madplanet.com/trac/guilder which intends to be a replacement for Maven 2 taking the cool features of Maven 1 and 2 and also incorporating some of the cool Groovy stuff to give building projects its Groove back. For all others here is the a little bit longer story.

In December 2004 I first complained about Maven 2 and I never really started to embrace Maven 2 and still think that Maven 1 is the better solution. But now Maven 1 is dead and Maven 2 took over. Eventually I had to use it in my line of work and discovered even more problems. Because I don't think that Jelly is a good scripting language and never started to be used outside of Maven 1 in a bigger way I was looking for another scripting language that I could use as its replacement. Eventually someone pointed me to Groovy and the Maven 2 Groovy plugin. Even though I liked the idea of Groovy the Maven 2 Groovy plugin did not work for me. I did not want to have a plugin that execute Groovy code but that could be written in Groovy. I also did not succeed in mixing Ant statements with script code as I could do in Jelly which took most of the appeal of Groovy away and so a lot of time passed by.

Well, somehow I stumbled over Gant which is Ant in Groovy and I saw in an example what I was looking for. Using closures and a Builder class Groovy was able to provide code that would exactly do that. Here is a simple example:

ant.junit( printsummary: true, haltonfailure: true ) {
    if( classpathName != null ) {
        classpath( refid: classpathName )

As you can see there is Ant's optional jUnit task intermingled with the check if the classpathName is not null and then it will be set a class path ref for the jUnit task. Beside the fact that I can mix and match Ant with Script Code this code also looks nicer because I don't have to deal with the closing tags and with other XML oddities. So nearly two months ago I started to think about a project that uses Groovy able to replace Maven 2 with scripted plugins. Now you might think that why replacing Maven 2 if I just could add the ability to create and deploy Groovy based plugins. The answer is that there is more that I don't like in Maven 2 than just the compiled Plugins and I hope that eventually all of these shortcomings are handled when this project is released. Here is a list of such features:

  • Scripted Plugins based on Groovy (maybe with JIT compilation)
  • Plugin Context that exposes the user interface but also the interactions with other Plugins
  • POM is a Groovy Script as well (no more XML)
  • POM Is completely flexible and its structure is defined by the used Plugins rather than the Project
  • Transitive Dependency Management using Ivy
  • Local POM and local Plugins (see maven.xml)
  • Goals can be overwritten or another goal can be executed before or after another goal
  • The project builds itself
  • ...

Then it took me around 4 weeks to finally get a POC release worked out and finally last Tuesday I was able to announce the release of it on the LA-JUG meeting. After that I heard from many other build tools that are growing like wheat: Apache's Buildr, Gant (heard from it before), Gradle and Graven. After a short scan I don't think that Buildr is a good idea because the instructions are written in Ruby but that's maybe just me. Gant is good but its Ant in a Groovy coat and Graven is the same for Maven 2. Gradle seems to be the closest to what I want to do but I think that there are still major differences between the two when it comes to the idea of plugins and probably other areas.

If everything works out as expected I should be able to release the Alpha version in a month or two which should have a solid core and a few full blown plugins.

Have fun - Andy

After several futile attempts to get my deployment units to log to Glassfish I finally figured out to use Log4J in Glassfish which is not really well documented there. So that is what I had to do:

  1. Place log4j.jar and log4j.properties file somewhere (I put it into <Glassfish Home>/lib/log)
  2. Add the fully qualified path to the log4j.jar into the classpath of Glassfish together with the directory that contains the log4j.properties file. You can do that in the web UI: Application Server/JVM Settings/Paths and the entries are separated by a return.
  3. Restart the server

Now you will find the log file relative to the <Glassfish Domain Directory>/config directory. Now I can read the log4j output like usual even though not in the same file as the Glassfish log statements.

Now some feedback to the responses I got:

  1. I could use SLF4J but this does not help for the classes provided by ServiceMix and that are the more important logging statements
  2. Well, Log4J was here first and so many projects and products were using Log4J way before JDK 1.4. And because logging is such a wide spread component so it the pain the incompatibility is causing.
  3. If Sun had provided a superior implementation that Log4J I could bite the bullet but they did not and so the whole idea of the JDK logging is ridiculous. And therefore I also don't want a JSR because that is making it even more painful.

Moral of the story is that if Sun could have swallowed their pride and either kept Log4J out of the JDK or just incorporated Log4J as is like they did with Corba we would not have this discussion. Now we have several frameworks on top of them that are trying to fix that and each of them fail one way or the other, what a mess. Thank you - Sun.

Based on the success of Log4J Sun for sure had to go ahead and add its own version of it as JDK logging making our life miserable. I was complaining a lot about that at the LA-JUG but today it reached a point where I really had enough to start ranting here.

Currently I am working with Glassfish and beside some other sticky points with it I ran into an issue with the logging or better the absence of logging. What I want to do is to deploy ServiceMix based JBI components as well as our own components to deploy on OpenESB that runs on Glassfish. Something is not working as expected and so I started to look into the log files but could not find any log entries from our applications. Finally I figured out that my component is using Log4J instead of the JDK logging that Glassfish is using. This is because the component contains Log4J archive because one of the other components needs it. On the other hand Log4J is not creating the log file and so the log entries vanishes. Now I cannot remove Log4J because some of the components used needs it but I cannot make the commons logging to use the JDK logging in my component. Maybe I am just stupid enough not able to fix that but using a logging framework should not be rocket science. Right now I started to use System.out.println() just to see what is going on, ridiculous!

Now how to could this be fixed? Except the Glassfish community is striving to shut out any component that is using Log4J one should expect that Glassfish could provide a Log4J wrapper that takes the Log4J statements and redirects it to their JDK logging. As the JBI components show the issues from class loading making it impossible for Apache's Commons Logging to select the correct logging framework and even when only CL is used it may not work as expected.

After I could build the bundle and the repository I am now able to do what I wanted to do a year ago. Bug 6313849 is an enhancement request to add a disconnect() method to the URLConnection class so that one can close any URLConnection without having to know which protocol is used and without any fancy upcasts. This is a generalization of my previous contribution to the JDK and so I wanted to tackle it a long time ago but never found time to go through the hassle of building the entire JDK.

So far I went through all the different sub classes of URLConnection and implemented the disconnect() method. Then I needed to create a test with jtreg which is not that trivial. The first problem is to decide where to place it. I could add it to the URLConnection or to the sub classes. I would thing it would make more sense to place it with the sub classes but I am not quite sure. Then I don't know if the test should be named after the bug number or after the newly added method disconnect.

If that is successful then I can send a patch to Sun so that they can evaluate and test it. So far so good but the entire experience with building the JDK and then go through the contribution process as of now is not very satisfying. First I had to build the entire JDK including the JVM etc even though I was only working on the Java source files. After the changes I had to execute a rebuilt and even though I tried to do that only inside the J2SE folder it deleted the entire build directory forcing a total rebuilt including the JVM etc. This is not very user friendly and will discourage some developers to start working on the JDK. A solution to this problem is to create a separate built system only for the Java source using most likely Ant so that I can rebuilt on the part I need speeding up a build cycle quite a lot. Together with a binary build snapshot of OpenJDK we can free the developers from building the whole enchillada if they are only interested in the Java code.

Have fun - Andy


Open-Sourcing JavaOne Blog

Posted by schaefa May 11, 2007

JavaOne is nearly over and it was a good as well as a bad convention. One of the things that stroke me was the fact of registering for a session and then standing in line for it. Considering the fact that back in 2000 there were 25k attendants and no registration / lines and it worked out mostly fine I have a hard time to understand this approach. I remember that some complains back in 2000 were that some people could not enter that a popular session but instead of creating an overflow room where they could have a big screen so we could watch the presentation remotely they just failed back to access control. This is like as if a servlet developer would have a problem with multithreading and as solution would make it single threaded. It does the trick but the fix is maybe worse than the problem.

On the other hand the attendants get a paper sheet to evaluate the presentation where one had to ender not only the evaluation but also the ID number. But on the convention we have a Java card (I assume) which already has the ID number and so why can't I evaluate it online on the Sun Ray stations or even do it over the phone especially when one of this year's theme was JavaME.

As an open-source developer I like organized anarchy and therefore have a problem with the overly organized JavaOne. In the early conventions I could roam around when a presentation did not turn out as expected. But when I have to stand in line sometimes way after the session starts then I not only miss parts of the session I also miss even more of a fail-over session.

This also prevented me from adding fail-over session into my schedule because the scheduler does only allow one session at the time because it uses it to control the number of the attendants. This makes it really hard to manage them because I always have to go over all the session rather than only focus on the session I am interested. I am only interested in OpenJDK, Java EE and maybe a little bit Swing which means I am not interested in JavaMe and the Web stuff. Still I was forced to use the rather slow JavaOne website and go through all the session per time slot or per day.

Have fun - Andy

Last night I went to the Java 3D / OpenGL Bindings BOF and in all the locomotion I forgot to pick up my fairly new MacBook Pro after asking a question. After the next session I suddenly realized it and raced to that room and my laptop was still there even though it was moved to the next row, ufff.

A thank you to all the people who saw the laptop but did not to take advantage of it.

I love you all - Andy


OpenJDK: Here I come Blog

Posted by schaefa May 10, 2007

Ditching the Keynote session at JavaOne I am sitting in the Alumni room and trying to get my head around the OpenJDK. Having a MacBook Pro I cannot download the JDK and build it on my Mac natively and so I needed to fire up my VMware installation of OpenSuSE and use Linux to build it on top of the Mac. So I went to the OpenJDK website, downloaded the source and the binary plugins and extracted them. Then I went ahead and tried to setup the environment as requested by j2se/make/jdk_generic_profile.sh script file like ALT_BOOTDIR, ALT_CLOSED_JDK_IMPORT_PATH, LANG and emptied JAVA_HOME. There I realized that I do not have Java 6 installed so I downloaded and installed it. Finally I was ready to fire up the build:

cd control/make
gmake sanity

and sure enough it failed right away complaining missing Alsa headers. After going through some hops I finally could install Alsa, Cups and Motif headers. For Motif I had to revert to lesstif-devel which I have to force to install because of the dependencies of lesstif. Nevertheless I got that going and after setting ALT_MOTIF_DIR to the directory (/usr/X11R6 on my box) containing the includes I was ready to go, at least I thought so. Unfortunately the sanity checks are looking for this file include/Xm/AccColorT.h which is not in lesstif but when I just created that file with vi the make system happily start to build, yeeha.

As a side note I wanted to fool the build by just creating the AccColorT.h file because I saw that on some mailing list that the JDK build does not need Motif but that is wrong, at least as of now. Some generated classes (I found a class called sizer.c) uses it in its imports.

Finally, after nearly an hour the built went through and a short java -version confirmed that I have built JDK 1.7.

Cool - Andy


EJB3 and Glassfish Blog

Posted by schaefa May 8, 2007

I just had a nice discussion with John Clingan, product manager on Glassfish, about EJB3 and Glassfish in particular. One of the thing that strikes me with EJB3 is that Sun seems not to be able to let go of old stuff. Right now an EJB3 application server needs to support EJB2 and EJB3 and must make sure that they do not conflict. This is going to convolute the code and drags down the performance. If I would have been in charge I would have made the support of EJB2 optional and required that an JavaEE application is either EJB2 or 3 so that the application server can deploy it on different containers. I would it even have made it possible that an application server can only support EJB3 and so a deployment of an EJB2 application would fail.

Well, I wasn't in charge and so we have to live with it. I am just wondering what will happen when EJB4 is released or do you remember EJB1 and the deployment descriptor classes? So deprecation seems to be a good thing but it should not only be applied to the first release. Especially for an application server there is no real need to require that an application needs to support both. EJB interactions enables us to build application using both new and old specifications without intermingling them.

I need to have a look into Glassfish especially V3 to see if and how their modules work out even though I will remain skeptical but it always good to try out new things.

Have fun - Andy


JavaOne 6 Years Later Blog

Posted by schaefa May 7, 2007

It is six years since my last trip to San Francisco to attend JavaOne and boy has my agenda changed since them. Back then I was working on JBoss and there was a huge fight between Sun and the open-source community on a lot of issues surrounding Java. Now Sun is going to finally open-source Java which is a great success for the open-source idea but I couldn't care less.

The power of Java does not come from the language or even the JDK even though there is a lot in there lately and in my opinion too much. The power comes from the open-source projects around Java that improves and increases the usefulness of Java and I am not talking about the applications based on Java. There is networking stuff like JGroups and Azureus (bit-torrent), high availability like HA-JDBC and Terracotta, build systems like Ant and Maven, Log4j (logging), Rome (RSS feeds handling), concurrency, web frameworks and much much more. It is really hard to find a niche were one could start a novel open-source project because most likely someone else already had that idea and started a project like that.

What Java provides to me is the foundation that makes it easy to harness the power and versatility of all the open-source projects out there. Quite often a project has to ditch an open-source project only for the reason that it is too big for what the project needs it for but still then the code of that open-source project can be the inspiration of the stripped down version they are finally using.

That said I indent to participate on the Open Java project if something is bugging me and to participate in open-source project again. Even though I don't care much about open-sourcing Java I care about Java and I love to participate where it makes a difference for a few people. I need to make a living and that will not be through open-source, so far, but I would not be who I am now without open-source and my previous commitment for it. I learned so much about Java and how to manage and design projects that it outweighs the time I spent on it.

Enjoy - Andy


JDK Community: Update Blog

Posted by schaefa Apr 5, 2006

Greg Hamilton blogged about AOP: Madness and Sanity talking about where and where not to use AOP and I nearly threw up, figuratively speaking, of course. Primary AOP is a concept that wants to relive the developer from some of the constraints of traditional OOP. I say traditionally here because J2EE is some sort of a AOP light framework already using some of the AOP concepts even though it is not really AOP by any stretch of imagination. In addition he said that the AOP allows the add code in a cross-cutting concerns manner but I think that is not the most important feature of AOP even though it is the best selling point because it can be illustrated quite easily. For me the most important feature of AOP is what I call "feature merge" or "loose integration" meaning that I can take two or more components and massage them in a way where they can interact together without actually changing their code base. I think that is actually what Greg's thinks is the bad part of AOP and he said that only Container based AOP is good because it is well defined even though I know too many J2EE developers who do not even understand the basic concept of J2EE transactions good enough to work as a J2EE developer. But Container base AOP is somewhat weak, very limited in its scope (not everything is an EJB in Java) and very rigid. On the other hand I am quite surprised that after the past where Sun said that JBoss will not pass the certification because it allows the user to change the way J2EE framework works by changing the interceptors I now see that interceptors are part of EJB3 specification. So I guess that JBoss has prevailed with its vision of a dynamic J2EE.

If I am going to use AOP then I need a very compelling reason and J2EE is not going to cut it. Therefore I crafted the title to indicate that AOP is not here to be squeezed into a container but to free us from the constraints of OOP and therefore we have to free AOP from any container. If you want to be on the safe side and do not want to explore the final frontiers of software development then AOP is not for you. AOP is difficult, hard to debug and sometimes risky to use but you can gain a lot from it: no pain, no gain. AOP is not here (at least currently) for the weak but for the brave who dares to push the limits to make things easier. I can promise you that you will be frustrated quite a lot and you will fail several times until something is working as expected. But anyone how made the transition from procedural programming to OOP or hierarchical to relational DBs can hopefully use his/her experience to understand the difficulties in the transition from OOP to AOP.

Oh yeah, annotation has to end up here because it is so great, isn't it !?! Annotation in EJB3 makes the whole thing only complexer because I now need a tool to know what is a remote interface, an ejb and what the actual JNDI name is because it is buried insight the bytecode rather than to have it explicitly insight an XML file. Annotations are just a way to tag elements in a class, nothing more and nothing less and so do not have anything to do with AOP. Most AOP systems like AspectJ or JBoss AOP provide support for annotations to declare aspects, pointcuts etc but especially for AOP I prefer to keep the definition outside of the source code because I want to be able to change it without rebuilding the project.

Any paradigm shift is painful because we have to give up our comfort zone in order to conquer new ground but it is not done by restriction. Christopher Columbus would not have found America if he did believe into world's view of that time and so sanity can be the madness of human evolution. Don't get me wrong if you are happy with you have and you want to code Java for the rest of your life then be my guest but do not expect that the world just stops spinning because of you.


Yesterday Ray Gan blogged about the JDK Community listing some of the facts about the Peabody project. If you never heard about that project then you are not alone and I only now about it because Joshua Marinacci gave a presentation about it at the LA-JUG last year. But even without knowing about the Peabody project is became a JDK contributor last year in November and started to code a fix for bug #6212146 which I has sent to Sun for a review by the end of November. I got an initial confirmation that the bug fix was received but that was all I heard from Sun for a long time. Then January 2006 Ray blogged about the state of JDK Community and I responded complaining about that I got no feedback from Sun about my patch. A little bit later I finally got an email from Michael McMahon (1/31) that they started to look into the patch. I also spoke with Matt Ingenthron from Sun about it and he tried to find out what is going on and to bring some more transparency into the JDB Community. Needless to say that I did not get any feedback since then

As a good citizen I took the time yesterday to fill out the survey and to pour in some of my thoughts and complaints. Now I take the opportunity of this blog to share my thoughts on the JDK Community to a broader audience. As an active open-source developer I know both sides of the aisle, the one that runs a project and the one that provides patches. But in order to keep a community alive and active the project team must react to input from the community and give feedback without being pushed all the time. Especially in this case where Sun is a huge company and Java is a big project getting a community project up an running is difficult. Nevertheless as a contributor I think I have the right that Sun not only receives the work from the contributors but also gives something in return and the very basic would be feedback on the progress of a patch. Unfortunately a regular contributor cannot get the CTS in order to make sure that one's but fixes does not break Java and so I cannot test it thoroughly. This means a contributor has to wait until Sun provides feedback to improve the patch. As a contributor I do not want that my patch is swallowed by a black hole and one day it makes it into the JDK or not.

I suggested a few improvements and most prominently I would love to have a contract person within Sun with whom I can work on the patch to make it into the JDK. He/she does not have to be the developer that test or improve the patch but he/she must be able to answer questions and to provide feedback. I do not need contests, awards or public recognition but I would love to have my name as author in the Java code when the patch makes it into the JDK. In addition I would love to have forum(s) for contributors where they can discuss items with the Sun's Java developers and also a way to track which contributor is working on which bug so that I can avoid working on a bug that someone else is already working on. Maybe it would be a good idea to invite some contributors into an expert group to improve the JDK Community process.

Currently I am not working on any patches for the JDK because I want to ensure that my time spent on this is spent worthwhile and so I want to see if it makes it into the JDK or not and in case it fails I want to know why. That said I still hope that Sun can improve the JDK Community because I would love to work on the JDK in the future. So far I am disappointed about the process and also think that this is why there are not as many contributions as one would expect (see the JDK Community List).


Filter Blog

By date: