techno.blog("Dion")

Javap is one of those utils that gets installed with Java, that some never find. Javap is helpful for poking around in bytecode found in the classpath.

One of the ways I use javap is to just find out if a certain class is in my CLASSPATH (as well as learning about the methods etc).

As soon as you are in a real build environment, you need to make sure that a class is in the CLASSPATH that your build is working on.

Since I spend time in Maven-land, I use a tiny little maven plugin which does the work to find out if a class is in the dependency list for a project:

maven -Dclass=java.lang.String javap

The bulk of the work looks kinda like this:

<goal name="javap:classpath:check" description="Check Classpath">
<fail message="Must set the 'class' variable. E.g. maven -Dclass=java.lang.String javap." unless="class"/>

<available property="class.found" classname="${class}" classpathref="maven.dependency.classpath"/>

<j:choose>
<j:when test="${class.found}">
<echo>Class Found: ${class}</echo>
</j:when>

<j:otherwise>
<echo>Class NOT Found: ${class}</echo>
</j:otherwise>
</j:choose>
</goal>

Download Maven Javap Plugin

Ted doesn’t get the Rails buzz after going to Dave’s Rails talk at No Fluff Just Stuff.

Firstly, you can’t say much for Ted wrt taste… I mean he is running that .NET blog software now ;)

Secondly, I think Ted hit the nail on the head and didn’t even realise it:

We found a greater need for configuration, more flexible and powerful execution models, and so on. In essence, as web apps got more complicated, the servlet/JSP space got more complex to match it. “With power, comes complexity; with complexity, comes power.”

I think the Java world took this waaaay to far. Abstractions upon abstractions.

We forgot that web frameworks ARE FOR THE WEB!!!

Before you look around we have JavaServer Faces, which “features” that you don’t just get to write out HTML. Sounds great on paper. I still hear people talking about how they will be able to just flip on a different Renderer and they will have a mobile application. Of course, in reality a mobile application is very different. You care about different things.

I want a web framework that lets me work with web technology (HTML is one of them ;), but gives me a nice clean way to do this.

Rails has a nice balance:

• MVC is there. No model 1 JSP here.
• Although MVC is here, you don’t have to learn struts html tags :)
• All Ruby. Learn it, move on. No EL/JSTL/JSF-EL/OGNL/XML
• Smart defaults, with the simple ability to plugin whenever you want (thanks Ruby)
• Helpful wrappers on top of behaviour such as Ajax if you want it
• Well thought out helpful code, such as flash

WebWork 2 does a good job of this on the Java side IMO. It gives you things that you need… but doesn’t make you have to learn a whole new world. Want components? Simple. Create some templates and you are done.

After spending time debugging a JSF application where JavaScript wasn’t output if your </f:view> was after the body tag…. it makes you really want to be Railing.

However, Rails is just a web framework. It has its issues like everything else, and isn’t a silver bullet. Often after learning about something fairly simple to get into like Rails you will be “huh that is it?”. In my opinion this is a very GOOD thing. Although, I do miss my IDE goodies :)

In my experience, I like to have simple tools which just work, but if the hardest part of your application is the web framework, you are lucky!

Good ole Brian has written about having cross platform messaging via XML packets, or lower level.

Messaging often seems to be under used. It is often a great way to handle interop (hence Brian’s idea), and a fantastic way to handle scaling out your architecture.

The pull model means that you can ramp up worker processes when it makes sense.

For example, if you ran an amazon.com the use case that HAS to work is purchasing books. Book reviews however, aren’t as important. So, to get around having DB bottlenecks, you could have the book review process put messages on a message queue. When traffic is low, you can startup some workers to take care of the reviews. If you don’t have the horsepower you can turn them off.

In traditional RPC the clients are pushing info at you, and you HAVE to handle it.

With Brians nice abstraction, I could even have my Rails apps play nice, and have them throw messages onto the queue that some backend system can fulfil on.

So now Rails can power my COBOL legacy backend :)

There have been some interesting items that have been on the great newstands recently:

Sun Bonuses

How about if you got huge bonuses even if you company was tanking? This is what our trusted friends in the Sun management team are getting.

Sun’s board and top management approved McNealy’s $1.1 million bonus last week, after the company reported an 85 percent decline in fourth-quarter net income and said it would slash 1,000 jobs–about 3 percent of its work force.

The board approved a $280,000 bonus for Sun President Jonathan Schwartz and rewards of more than $150,000 for the heads of finance, human resources and technology

Apple

Who can take a commodity device, innovate a little, and resell it for a larger margin than anyone else? Only Apple.

Although, maybe this is changing a little. Instead of all of the “we love you apple” talk, we are getting:

One fan threatened to remove his Apple tattoo should the company include the security chip in its new Macintosh products.

There are MANY things wrong with that statement :)

Googzilla

Mozilla.com hit the ‘net this week. Brendan Eich put it out there, and many got right on it.

Conclusion? “Come on. this is just so Google can buy it right?”

Charles Miller is talking about the IntelliJ 5.0 new ‘inspector’ feature.

I once mentioned the “Those who coded also coded” feature.

Now Hector is watching our code, wouldn’t it be nice if I could tell him to start talking to others of His Type:

• Talk to your brother over there, and allow us to pair code remotely
• Learn about me. Watch, learn, and remind me
• Talk to a set of brothers and discuss how we all work, and teach us
• … and much more!

SpikeSource announced more news around a stack.

This is sorely needed in the opensource world, and in no other software arena more than Java.

In general, Java folk are ‘engineers’. We like to try the latest and greatest. One project may be Tapestry/Pico/Kodo JDO/Ant and the next WebWork/Spring/Hibernate/Maven. We jump and leap between similar, and very disimilar worlds.

This can seem cool, and flexibility and choice is a pro for Java. But, imagine if you are running a huge company, and your large IT team is running around in this manner.

Now the Java platform becomes a burden as you can’t jump between projects easily, education becomes a nightmare, as well as reuse.

The goal at large IT shops is to be able to churn out applications in short order, that fit into the corporate enterprise view (and tie into the systems such as authentication, authorization, etc).

The Stack

This is where the need for a common stack comes in. As a CIO of BloodyHuge Inc. I want to enable some flexibility, but within the guidelines of a stack.

Wouldn’t it be nice to have a development team start a project and:

• Know the technology inside and out (past projects, and good training)
• Know the lay of the land for the project (shared dir structure, build goals, etc)
• Have helpful code to gen some work (a la Rails)

We need common stacks to do this.

When I saw the SpikeSource announcement and the large amount of technologies in their ’stack’, I thought it was missing something. As a company I don’t just want to know that technology a thru z is ‘certified’ from a company, or that they offer support.

They want help. They want you to work with their engineers to choose a common stack that has everything setup from the beginning.

They also want it to be locked in stone for a couple of years, with a known release cycle of updates to the Stack.

When I look at SourceLabs and their AMP Stack, I think they may have gotten it.

Update: SourceLabs does have a Java Stack:

• Spring Framework: version 1.2.3
• Apache Axis: version 1.2.1
• Struts: version 1.2.7
• Hibernate: version 3.0.5

Java + Common Stack = Productivity

J2EE != Stack

I personally don’t think that J2EE is the stack. Right now, if you look at an average Java project you will see myriads of dependencies that have nothing to do with J2EE. Although the Java platform is growing, and you could envison a stack that consists of JSF + EJB 3 + java.util.logger + … even this isn’t everything you need for a project.

J2EE is great from the standpoint of API education IMO. When you use different implementations you will often need to tweak things… maybe at a config level, or what have you.

BigDecimal is a necessary evil, isn’t it. Without it, you end up over-running primitive bounds and suddenly your results are weird “what is with the negative numbers?”.

I was talking with someone whose “users” are uber-intense actuaries.

They need to be able to write quick reports, and change functionality on the fly.

Rather than using full on Java, they interfaced via a scripting language, to give them concise scripts versus the verbosity that we know and love from Java :)

JavaScript was one choice, but they quickly ran into problems with double/float/int/BigDecimal, and they had to manually do a lot of work with BigDeminal objects and methods.

Then along came Groovy, which automatically groks the fact that it should take care of autogrowing the world.

E.g.

def x = 10;

println x.class;

(1.0..100.0).step(20) { y ->
println x;

x = x * y;
}

println x.class;

Output

class java.lang.Integer
10
10.0
210.00
8610.000
525210.0000
class java.math.BigDecimal

Note the auto change, and how operators such as * / – + all JUST WORK.

As soon as I saw Facelets I was a happy man.

I have always hated:

<h:form>
<h:dataTable value="#{widgetService.widgetDataModel}" var="widget">
<h:column>
<h:commandLink action="#{widgetService.delete}" immediate="true">
<h:outputText value="Delete" />
</h:commandLink>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Name" />
</f:facet>
<h:outputText value="#{widget.name}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Description" />
</f:facet>
<h:outputText value="#{widget.description}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Cost" />
</f:facet>
<h:outputText value="#{widget.cost}"/>
</h:column>
</h:dataTable>
</h:form>

And, moving back to just normal HTML with the odd jsfid attribute, class attribute, etc… felt at home.

If I was writing my own JSF web app, I would jump to use this view instead of the mess.

However, if you were a huge enterprise, and you were sold on “tooling”, then will this play in that world?

NOTE: Taming JSF 1.1 is an interesting article on JSF 1.1.

A project that I am joining is using MyFaces implementation of JSF, and Sitemesh for decoration (I am a big fan of Sitemesh).

There is a known problem, where you can not put JSF code (you know, and all that rewriting of html ;)) in the decorator.

However, we were running into a problem where even if the decorated page had JSF tags in it the app would freak out and you would get no HTML response.

The JSF code was running, as the log file was showing us that.

We dropped in the JSR RI and it all worked fine, so I thought it may be a MyFaces bug. However, MyFaces works in AppFuse and the like.

This is where a debugger kicked in, where TDD wouldn’t really help as much.

After walking the stack I saw that the MyFaces extensions filter was freaking it all out. When I took that out of the filter chain all worked well.

The problem wasn’t actually the extensions filter itself though, the problem was the order of the filters defined via filter-mapping’s in the web.xml.

Since Sitemesh is doing magic on the entire chain you should put the filter-mapping at the beginning, as then the container will run it first… and it will then chain.doFilter()…. which will do its thing and when it unravels, Sitemesh will be the last to finish up.

Gotta love debugging fluff like this!

Kirill Grouchnikov’s discusses thoughts on native XML support in Dolphin. There are definitely some interesting items, but I really hope that Sun takes a LONG look at what comes from C# 3.0 (send someone to PDC guys!), and look at the current E4X. It was BEA after all that came up with E4X!

Even look at Groovy’s XML builders and parsing w/ GPath.

I just want to be able to work with XML in a trivial way, instead of with the ugly mess of DOM/SAX/X APIs.

I like having a smart for() loop for XML, that is good….. but some of the “extends” stuff just looks more complicated than it needs to be.