Wednesday, October 27, 2010

How to fix missing source for latest Java for Mac OS X 6 22

This will make clicking through to the JDK source work in Eclipse again after updating to the latest Java for Mac OS X.
  1. Go to http://connect.apple.com and download Java for Mac OS X 10.6 Update 3 Developer Package
  2. Install it.
  3. Open a Terminal.app window
  4. sudo -s
  5. cd /System/Library/Frameworks/JavaVM.framework/Home
  6. ln -s /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/src.jar .
  7. ln -s /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/docs.jar .

Monday, October 18, 2010

New 'Java Application Server'

After a few days trying out various technologies to see what I liked and what would work, I finally got what I consider a cool new basis for a Java application server built.
  • Based on top of Tomcat 6
  • Deployed as a single simple expanded war file with minimal xml configuration
  • Integrates:
    • Spring 3.0 - all annotation based
      • Method/Database level Transactions (@Transactional)
      • JPA Entity Persistence (Hibernate based) (@Entity)
      • EntityManager / Container managed Datasource via JNDI (@PersistenceContext)
      • Lifecycle (@PostConstruct/@PreDestroy)
      • Injection (@Inject/@Provides/@Bean)
      • JMX beans (@ManagedResource)
    • Guice -  still not sure about this route, may just go with Spring for it
      • Guice-Servlet
    • Hessian for remote method calls
The key feature of all of this is that it cold starts up (with a connection to the database) on my laptop in under 4 seconds. Comparably, JBoss 6m5 default config without even connecting to a database or deploying any war files starts up in 22 seconds.

Next up, I'm probably going to integrate RESTeasy for JAX-RS support. I don't quite need to serve up html pages, but I could always just use jsp's or HTMLeasy.

The idea is that this will make a really good platform for developing enterprise Java applications without having to be tied to the slowness of JBoss startup times (and the way that a new release always breaks something), commercial products like tcServer or the dreadful thought of using Oracle's Glassfish. Sorry, not a Larry fan. I also tried Resin 4.x, but after getting no response regarding the JMX support on the mailing list and the general bugginess of it, I gave up. I'm also not sure that their CDI implementation is all that solid because of the way they extend your bean classes at startup.

Monday, October 11, 2010

Apache Board Should Consider Dumping Java Development

I have been contributing to open source since 1993. I have been a server side Java developer since 1997. I was one of the primary people who started doing Java development within the Apache Software Foundation. I became one of the first members of the ASF based on contributions in Java. I was a party to the discussions which convinced Sun to open source Tomcat and Ant. I helped create the Jakarta project. I started or contributed to dozens of projects over many years. My code is used on servers all around the world. I continue to work with Java on a daily basis and have created many other open source projects on my own. I am a huge fan of Java for enterprise software, because I've personally seen it work exceptionally well.

Based on what I read today about IBM giving up the legal fight over the issues which have surrounded the JCP since day one, I feel that now is the time for the ASF to stand up and stop supporting Java development. The process that now surrounds Java does not reflect the open nature of the ASF.

In the past, the thought has been that as long as we are part of the (JCP) process, we can continue to exert our pressure on corporate forces to engage them and encourage them to embrace openness in what they do. Working from the inside gave us an advantage. In a lot of ways we were really successful and that help Java grow immensely as a language. I feel that door has now been closed and we've been left outside, only to get Sun burned.

This isn't about forcing projects to leave because of choice of language or being angry or being the loud voice in the room. It is simply about standing up for what you believe in and knowing when to throw in the towel. The ASF tried for many years to take a hard stance about what they believed in and failed. It is time to realize that and give up. It is hypocritical for the ASF to support a language and set of corporations which doesn't want or need its involvement anymore.

That said, I truly believe Java is not dead. Not for a long shot. Especially since there really isn't anything better to replace it for large scale enterprise applications. With IBM backing Oracle and Java7 and the legal roadblocks now removed, I think there is actually a bright future for it to grow. OpenJDK is technically open. Maybe not in the way the ASF would like, but the truth is that there is still billions of dollars being invested in this technology. I actually look forward to seeing what is in store next.

I know that some people within the ASF will worry that the foundation will become irrelevant without Java. It makes my heart flutter a tiny bit to think that I had a hand in creating something so huge. However, the irrelevance happened long ago for ASF's Java projects. The process for developing code within the ASF has become so inundated with bureaucracy that the fun has long since dried up. It is far easier to create your own project, get free hosting and check in whatever you want than it is to work within the ASF's walled off garden. As far as I can tell, the only projects that really thrive are those with corporate backing. At which point, the ASF is relegated to being a method to garner notoriety and free development resources.

Other communities have developed far better tools for supporting collaborative software than what the ASF can ever hope to provide. I suggest that current ASF Java projects be moved onto github or googlecode project hosting. These services provide a better environment in the long run anyway. Links should be made to the new project pages and the ASF should focus on development elsewhere.

In the end, I really feel that the ASF should put its weight behind languages that aspire to reflect the sense of openness that the ASF embodies. We tried for many years with Java, but the reality is that with IBM gone, there is nobody left to back us. The fight is over, move on.