STOP thinking programmer

There are no less than 10 different programming language and no less than 50 web development frameworks listed at Java Source.net. Do we need another programming language or web framework? Does that seem a little ridiculous to you? No to me. There are always room for improvement in development. If a programmer think that it is ridiculous to have so many programming language or web development frameworks, the programmer is a STOP thinking programmer. How can a STOP thinking programmer possibly be good for the Java Community?

Chris tam
Hong Kong

Do Programmers have Make-Work, Anti-Foreign and Pessimistic Bias?

According to economists Bryan Caplan, all voters have 3 Bias. Do our programmers also have these 3 bias? They include Make-Work bias that means creating more programmer job always goods. My note: Do we really want to create so many programmer jobs that the world worst programmer can still find a programmer job. Actually there are always programming job which needs new skill and technical knowledge. They are not for a single hammer programmer.

Anti-Foreign bias means that oversea programmers is often lower skill and unable to write good quality program. Also Anti-Foreign bias can also means that VB programmers argue that Java is too complex and too difficult and too ineffective for development. Or the C++ programmer argue that Java is only a downgrade of C++. Or the Java programmer argue that Ruby on Rail is not suitable for enterprise application. My note is: Most are myths but some are true. [My own Anti-Foreign bias is against Java Annotation, but not Bob Lee's google giuce (some features are really better than my lovely Spring) or Graeme Rocher grails (I learn too much groovy that I can't miss how they are used in grails). The current Java Annotation implementation is too bad. In my current programs, I have already mixed too many unrelated Annotations in a single file that it look more like a messy sh-t.]

Pessimistic Bias means that programmers are always afraid that the IT world is ruled by Microsoft and all programmers become microserf. (My note: Microsoft will never rule the IT world becase it does not have the gun to collective microserf tax.) The java programmers are afraid that there are too many framework(strut, spring, webwork, etc... (believe me, the list has more than 1000 item) and the java language will not be ONLY holy programming chosen by GOD of programmer (Not Gosling, he is FATHER of JAVA) and java will be contaminated by Ruby or other scripting language. My Note is: Do a lion afraid that he/she will be eaten by you? No. Only those who do not run will be eaten by Lion of the Future.

In Bryan Caplan's book, "Myth of Rational Voter", if you have all these biases, you are a normal voter. You are qualified to elect US president. The above information is not a joke but a serious question. You can add more your favorite bias to them.

chris tam
Hong Kong

Correct Incentive Mix For Programmer

According to the book "Discover your Inner Economist" that all people, including programmers, are responsive to both incentive. As the author writes, "incentives matter through the medium of how a person perceives what is at stake in the choice. It is not just getting the mix of incentives right. You also have to know something of the values or cultures of the people...". The main point for a good incentive mix for programmer is that we must know the values and cultures of the programmer. I think the correct incentive mix should contains:

1. A reasonable salary and/or bonus. There are too many employers that think the sentence "Good job. Well done" is equals to salary.
   
2. Meeting is always required by managers that want to show their contribution and involvement in the project. Also meeting is the only way for the managers to understand what have happened in the project. But none of them are incentive to programmer. The best way to provide incentive to programmer is to limit the number and time of all meeting.
3. All human are social animal, including all programmer. No matter how poor a programmer communication skill is, he still need other programmers. An environment that help the programmers socialize easily is a really great incentive.
   
4. All programmer need to have a sense of control on the programmer. A "sense of control" is always within the programmer inner economists. Don't let the "DEVELOPMENT METHODOLOGY" banner overrides all the programmer sense of control.

In summary the correct incentive mix should include reasonable money return, limit number and time meeting, social programmer environment and programmers have a sense of control of their program. Is there any other comments or suggestions?

chris tam
Hong kong

How to make Guice and EJB and SEAM bloat and ugly

Although the following code is only an imaginary example code of abusing Java Annotation. But it may help Java programmer to prepare for the Java Annotation bloating. The Java Annotation bloating may hurt Guice, EJB, SEAM and etc... Those Java programmers who claims that Spring XML bloats may be backfired when they switch to Java Annotation blindly.
...

@Inject
@Transactional
@Stateless
@Column(name="foo",type="VARCHAR"...
@Criteria(type="manager"...
@DynamicInclude("Bonus")
@MyJTextField(size="12",...
@Validate(require=true...
@MyFormatter(format="...
....
public void setFoo(MyObject foo) {
...

What is the problem of the above code? All the Java Annotations are NOT modularized and the Java Annotations BLOAT. I think Java programmer must think carefully about this. Otherwise Guice will bloat, EJB will bloat and JBoss SEAM will bloat.

chris tam
hong kong

Strange behavior when wiring Groovy beans in Spring without Java Interface

There is always some surprises when using Groovy in Java programs. For example, you can wire any 2 Groovy beans in Spring even though these 2 Groovy beans do not implement any Java interface. For example, GroovyBean1 is defined as follow:

package test ;
public class GroovyBean1 {
def groovyBean2 ;
}

And GroovyBean2 is defined as follow:

package test ;
public class GroovyBean2 {
}

In the spring xml config file, you can wire them as:
...
<lang:groovy id="groovyBean1" source="classpath:test/GroovyBean1.groovy">
<lang:property name="groovyBean2" ref="groovyBean2"/>
</lang:groovy>
<lang:groovy id="groovyBean2" source="classpath:test/GroovyBean2.groovy"/>
...

If you load the above spring xml config file with ClassPathXmlApplicationContext, you will find that "GroovyBean2" is successfully injected into "GroovyBean1". But if you change GroovyBean1 source code as follow:

package test ;
public class GroovyBean1 {
GroovyBean2 groovyBean2 ; // <-- change untype variable to "GROOVY" type variable
}

ClassPathXmlApplicationContext will throw an Exception when it tries to inject "GroovyBean2" into "GroovyBean1". Why does Spring IOC not work with "pure" groovy objects that does not implements any Java interface? The problem is due to Groovy class loader. The "GroovyBean2" definition in GroovyBean1 and the "GroovyBean2" definition in Spring xml file belong to different class loader so the Spring IOC throws Exception. Is it possible to solve this problem by using a single GroovyClassLoader to load both GroovyBean1 and GroovyBean2 objects. The answer is simply "NO"!!! Because GroovyClassLoader always create a new InnerLoader when compile a groovy script file. If anyone has a solution, please leave a comment.

chris tam
Hong Kong

Inconvenient Truth of Java Annotation

The Inconvenient Truth of Java annotation is that it promotes bad programming practices and create unmanageable Java programs.

The first problem of Java annotation is that it must be embedded into the Java source codes. Mixing source code and meta information is not a good programming practice.

The second problem is that it indirectly forces programmer to put totally unrelated Java annotations into the same Java source file. The programmer may need to put the JPA annotation, Validation annotation , GUI annotation, etc into a Java POJO class. It is a really messy bad practice.

The third problem is that Java annotations are unmanageable and untraceable if there are large number of annotations being embedded into many different source files. It is a really difficult task to find where an annotation is placed or trace how the annotations work together.

The fourth problem is that other scripting languages that are implemented in Java, like JRuby, Jhython, etc,,, cannot leverage the benefits of Java annotation feature.

I think the best solution to the above problems is to put the annotations into a separate annotation file. What do you think?