Just a short note to tell you an interesting event on Java is taking place in Rome next Saturday (Jan, 30th). If you’re around, you might want to attend that: http://roma.javaday.it/javaday2010/

Most of the talks are going to be in Italian, but at least three of them will be in English. The talks are going to be quite technical and should also cover interesting topics like scalability, concurrency, management and tuning.

Something like 2 months ago I wrote a post on how different classloaders can potentially cause you problems if you’re not that careful on where your libs are loaded from. Well, I’ve just had to face another issue of that type, with a library of mine loaded from the bootstrap classloader and referencing a class from servlet API that I don’t want to be loaded by that classloader too. The easy solution of course would have been to pull my lib out of the endorsed dir (the one the bootstrap classloader loads libs from), but how could I be sure that I did not break anything in my app? Besides running tests, I finally decided to give JBoss Tattletale a try… I saw all the hype around it when it was released some month ago, but I did not have the chance to use it for a practical issue before.

Well, in less than five minutes I checked out he project, built it and ran it against my endorsed lib dir. I got a report and some graphs basically showing no libraries in that dir (hence loaded by the bootstrap classloader) where directly depending on my library, thus it’s safe to pull it out of the endorsed dir. The easy solution was indeed OK and thanks to this tool I have a theoretical proof of that

Take a look at JBoss Tattletale, it’s really a cool tool. Perhaps you can start from its author’s blog: http://blog.hibernate.org/11166.lace

This post is to let you know a really interesting event that’s taking place soon in Genoa (Italy): the Java Application Server Day 2009.

As you can read on www.serverday.org, the event will be open to the entire Italian Java Community; international experts, developers and students will discuss the state of the art
and the future of Java Application Servers, with a focus on the innovations of
the recently released JBoss 5.0, Spring dm Server, GlassFish 3.0 & Oracle/WebLogic.

I’ve been asked to be there on behalf of JBoss / Red Hat, so I’ll present the recent changes in JBoss AS 5.

Hope you can join the event on May, 21st. Stay tuned for further updates.

Today I was importing a .NET generated wsdl and getting this error using JBossWS wsconsume.sh tool (yes I’m not using Wise for this particular case!! But the problem would be the same in Wise since it use wsconsume under the hood) :

[WARNING] src-resolve.4.2: Error resolving component 'sch:schema'. It was detected that 'sch:schema' is in namespace 'http://www.w3.org/2001/XMLSchema', but components from this namespace are not referenceable from schema document 'file:/home/oracle/Desktop/security.asmx#types?schema1'. If this is the incorrect namespace, perhaps the prefix of 'sch:schema' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'file:/home/oracle/Desktop/security.asmx#types?schema1'.
  line 85 of file:/home/oracle/Desktop/security.asmx#types?schema1
[ERROR] undefined element declaration 'sch:schema'
  line 85 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 178 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 217 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 231 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 245 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 259 of file:/home/oracle/Desktop/security.asmx
[ERROR] undefined element declaration 'sch:schema'
  line 273 of file:/home/oracle/Desktop/security.asmx
 
Failed to invoke WsImport
java.lang.NullPointerException
        at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:237)
        at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:518)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:232)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
        at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:134)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2244)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:187)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:133)
        at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:182)
        at org.jboss.ws.tools.jaxws.impl.SunRIConsumerImpl.consume(SunRIConsumerImpl.java:217)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.importServices(WSConsume.java:223)
        at org.jboss.wsf.spi.tools.cmd.WSConsume.main(WSConsume.java:81)

After some search Alessio pointed me to this excellent post where the problem is well explained and solution provided. The “problem” is not specific to JBossWS and solution explained there is fine for JBossWS too.

Hoping this cross post could help someone looking for the error in relation to JBossWS in google

“The Foo class does not declare a static final serialVersionUID field of type long“

Why bothering adding that field? What value should it be given? Should it be ever updated? If yes, when?

Junior java developer often underestimate this warning…I know because it happened to me too in the past

Well, before finding out (perhaps in QA phase) that the great new version of your software can not communicate with previous ones… spend some minutes reading the following pages:

• http://java.sun.com/developer/technicalArticles/Programming/serialization/ (especially “Version control” section at the end)
• http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.html (especially Chapter 5)

Finally… always declare the serialVersionUID when required… it can save you from issues in the future

Well, my last posts had a lot of visit, and some feedbacks too. Some of them have been attached directly to the post, some comes into The Server Side post. If you haven’t already done read both set of comments, there are some good point to start thought and discussion.
As you can read someone expressed some concerns about the idea (mainly about coupling and cluttering of code). I’d like we have opened a discussion and I’d like to continue trying to provide tools reducing pain worrying someone if it’s possible.
I haven’t gotten only concerns, but compliments too and much more important some request to contribute, and accepted some. Please welcome with me our three new contributors (have a look to google code page for more details).
Well, comments on blog doesn’t scale very well, so I have written this post mainly to announce we have opened a dedicated groups on google to continue our discussion and brain storming about this idea. If you would like to contribute with idea, concerns, discussion or much better some code please join us:

Subscribe to testedby-dev

Email:

Visit this group

I hope some (or ideally all) the nice brains have commented here, on TSS, or email me would join us and provide their point of view contributing to provide to the community the opportunity to have a different approach to tests. Maybe it will not be perfect or better than current one, but choice between multiple alternatives means freedom.
Thanks for the interest.

What does “a new approach to unit tests” mean? Isn’t JUnit or TestNG enough and fine? JUnit (from here on I’ll nominate it only for briefness, but TestNG is the same for my discussion) puts test classes on focus and starts from them all tests. This means in fact that classes under test are considered only in test classes code, the only way a programmer can keep an eye on classes under test is using some kind of naming convention.

With older versions of JUnit you were forced to design your test classes extending a framework’s class and calling methods starting with “test”. So the convention has been to name test classes and test methods with words which could “connect” them with class and method under test. I think you would agree with me TestNG and Junit 4 give us a lot of freedom removing these requirements. Anyway the problem of logical connecting class and methods under test to our tests still remain and most test classes still respect that old convention.

But there are a lot of better ways to name classes and methods! Let me introduce you to Behaviour Driven Development (BDD). Please note BDD is not going to be the main focus of this article, anyway it makes a perfect wedding with my idea. So, let’s go into BDD in as fewer words as possible.

BDD is not only a new way to write tests but also a new form of design by contract

Let me start my introduction quoting the behaviour-driven.org:

BehaviourDrivenDevelopment grew out of a thought experiment based on NeuroLinguisticProgramming techniques. The idea is that the words you use influence the way you think about something

The whole idea is to ask programmers to concentrate on words used to describe a test class or method, because selected words will influence their point of view on the problem. In practice test we will write with a BDD approach will be much more concentrate on the behaviour of class/method under test then on the method itself. Of course this will change the way we test our code a lot, i.e. we will test a method multiple time to verify each behaviour is valid for it.

OK, what if I don’t believe on Neuro Linguistic Programming? Well, from a pure developer point of view, we are defining with our behaviour tests contracts of the class and methods. And moreover the tests results will be absolutely clear (i.e. “shouldAcceptNullValue fails” is a very clear statement also without complex reporting). Let me just provide a simple example to get you an idea:

@Test( expected = IllegalArgumentException.class )
    public void shouldNotPermitMethodNull() throws Exception {
    [..]
    }
    @Test( expected = IllegalArgumentException.class )
    public void shouldNotPermitEndPointNull() throws Exception {
    }
    @Test
    public void shouldInitWebParams() throws Exception {
    }
    @Test
    public void getHoldersResultShouldReturnHolderForRightParameters() throws Exception {
    }
    @Test
    public void getHoldersResultShouldIgnoreUnknowntParameters() throws Exception {
    }
    @Test
    public void getHoldersResultShouldIgnoreINParameters() throws Exception {
    }
    @Test
    public void shouldRuninvokeForOneWayMethod() throws Exception {
    }
    @Test
    public void shouldRuninvokeForMethods() throws Exception {
    }
    @Test
    public void shouldRuninvokeForMethodsApplyingMapping() throws Exception {
    }

Do you need a brief introduction about how BDD can be successfully applied to Java (original idea comes from Ruby’s RSpec)? Have a look at this excellent post.

So is BDD enough?

IMHO the answer is no. BDD is great and you should try it, but if you try to put it really in practice you will soon completely loose relations between classes under test and test classes. In BDD not only method names loose testXXX convention, but also test class names may loose their conventional name. Moreover you can have more than one test method insisting on the same method and/or class. For example the previous example isn’t perfect, maybe a specific test class to test getHolder method behaviour would be finer.

Do you need help? Here is my new project TestedBy

What about an annotation to mark classes and methods under test with a reference to test classes and methods? Not bad, isn’t it?

My thoughts started more or less from here, but there is much more than an annotation. I’ve loved so much this idea that I decided to start a new open source project providing testing tools that put class under test at the centre.
Continue this read and I’ll demonstrate you how this annotation and related tools may totally change your approach to tests.

In a nutshell TestedBy aims at changing the point of view regarding test classes and classes under test. What we would obtain is to put classes under test (the most important classes of projects) at the centre and link test classes and methods from them. A code snippet may help much more than any explanations:

public class TestedBySample {
 
    /**
     * @param args
     */
    public static void main( String[] args ) {
        TestedBySample sample = new TestedBySample();
        System.out.print(sample.add(1, 2));
 
    }
 
    @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork" )
    public int add( int i,
                    int j ) {
        return i + j;
    }
    @TestedByList( {@TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork" ),
        @TestedBy( testClass = "it.javalinux.testedby.TestedBySampleTest", testMethod = "addShouldWork2" )} )
    public int add2( int i,
                     int j ) {
        return i + j;
    }
 
}

Oki, it’s nice, but can it really change your approach to unit tests? I think so.
How? At least in two different manner.

1. Design by interface and contracts

A famous adagio in software design says “Design by interface”. And it’s a sweet song for my ears. But of course you should “Test interface” too.

More formally “Design by interface” means defining interfaces of your API and then asking all implementors (maybe and a lot of times are different people or even companies) to implement these interfaces. Anyway all you can enforce is what a strongly typed language as Java can ensure: an interface implementation must respect its interface signature both in types and parameters. What you cannot enforce are behaviours. And of course it’s a big limitation in API design as this could drive to implementation with totally unpredictable behaviours.

Here comes to my mind Eiffell language and its design by contract (DbC) approach where contracts guide redefinitions of features in inheritance. There are a lot of tools providing DbC in Java, but my thought is that we already have a consolidated way to test contracts on methods and also finer behavior even of smaller piece of code: Unit tests.

With TestedBy, tests declared on an interface (or a superclass) can be run upon all implementers to verify they’re respecting the behaviour and contract defined in the super type. IOW the API designer not only provides the interfaces, but also a set of test classes verifying expected behaviour. Then every implementer would supply its own implementation and run the tests provided by the API designer against its concrete classes to verify they are respecting not only type safety but also beahviour/contract safety for which the API was designed. TesteBy here invokes a test defined for an interface passing to test class a concrete instance of class implementing the interface under test.

Here is an example on how this is achieved with TestedBy: we have added @TestedBy annotation on APIInterface and then provided a @BeforeTestedBy annotation to set the interface instance on which tests run. TestedBy will run shouldAddTwoAndThree both for APIImplOne and APIImplTwo, succeding on the first one and failing on the second

public interface APIInterface {
   @TestedBy( testClass = "it.javalinux.testedby.APITest", testMethod = "shouldAddTwoAndThree" )
   public int add(int a, int b);
}
 
public class APIImplOne {
   public int add(int a, int b) {
	return a + b;
}
 
public class APIImplTwo {
   public int add(int a, int b) {
	return a - b;
}
 
public class APITest {
 
  private APIInterface instance;
 
  @BeforeTestedBy
  public beforeTestedBy(APIInterface instance) {
	this.instance = instance;
  } 	  
 
  public void shouldAddTwoAndThree() {
	assertThat(instance.add(3,2), is(5));
  }
 
}

Of course I have kept the example simple, but TestedBy has some more annotations, for instance factory of classes under test can be specified when simple reflective invocation of no argument constructor isn’t enough.

2. Run test on current working class

You write a test to verify your code correctness. Moreover you are using unit test to ensure your changes isn’t breaking working code and mainly works of other people. How are you doing this? You make your changes and then you run all your tests against code you are modifying. Then at the end you run all tests to be sure you haven’t broke anything else.

What about having your IDE do the first step for you then? As it compile your modified classes it could (and IMHO it should) run tests against these classes. TestedBy makes this possible since you or your IDE could ever run tests against changed (aka compiled) classes. Here an eclipse plugin can do the magic of running tests insisting on you modified classes and verifing you aren’t breaking your test suite, not only your compilation, during code development. And this should not be too heavy, since the plugin could use TestedBy’s annotations to run only few tests insisting on your modified classes (or even methods).

Moreover running tests on a particular class under test you’ll get a clear report saying something like

"ClassUnderTest.methodUnderTest shouldThrowExceptionWithNullParameter doen't pass"

or even better

"Failure: methodUnderTest in ClassUnderTest doesn't throw exception with null parameter, but it should!"

Moreover you can of course totally break (if you like or need) conventions on class/method names and find, run and navigate your tests staring from your project classes.

Of course massive launches running all tests insisting on all classes will still be possible and your tests will be also runnable by JUnit since a TestedBy test is a JunitTest.

Some features

Well, let me detail some features I have in mind for TestedBy

1. The first one maybe the most trivial, but one of the most useful: within your ide you can navigate sources starting from the class/method under test. This feature comes out of the box with Eclipse 4.4, since it makes full qualified class names navigable also if they are inside a string. Of course it’s just a starting point, and a specific Eclipse plugin may be developed to navigate the code, construct the tree of test classes from a class under test, execute tests insisting on the open/changed class (see point 3 too) and so on. I’m not an Eclipse guru, so any contributions on this area are more than welcome.
2. You will find this annotation in you javadoc. Think how much advantage you can get if you are using a BDD approach, defining test methods like shouldNotAcceptNull() or shouldThrowsExceptionIfEmpty and so on. With a BDD approach you can in fact define and verify contracts and with TestedBy annotation in JavaDoc document it to your API users
3. You can run test starting from class under test and not test class. I have already said a lot about this in the previous chapter.
4. A design by interface and contracts. I have already introduced this idea in a dedicated paragraph.
5. Test class generation. A tool (ant, maven, or eclipse too) can use our TestedBy annotation to generate test classes. Read also point 6.
6. Ant and/or maven task/plugin to run tests starting from class under test. This tools will manage also round tripping (it’s important to ensure test classes and annotations don’t go quickly out of sync):
   • Reverse engeneering: starting from existing tests will add TestedBy annotations to class under test
   • Running tests from TestedBy annotations will verify they run all tests and that no annotation point to not existing test.
   • Generate (empty) test classes and methods starting from annotations.

Ok, that is not all, but I think it can give you the whole idea. I’m working on some other ideas behind this one, but I need to define them a little better before presenting them to the community.

Conclusions

So can this approach interest you? Let me known what you think about and share with your friends this post…more feedback I get, better refinement I can do.

Now the question is…which is the status of the project?
Well have a look to project homepage on javalinuxlabs. On googlecode you’ll find also some classes under svn. It’s not a really first implementation of the project…it’s more or less a proof of concept. But we are working hard to kick it out of the door soon.

Subscribe this feeds. I’ll make announcement here very very soon, and moreover other posts regarding evolutions of this idea.

Would you like to contribute? Have a look to this page to better understand in which area we need help.

I have read last week end the second edition of one of the most famous Java books.

I loved the first edition, and I love even more this second shot. It have the same good layout of first edition, organizing arguments in chapters and items, with clear explaination of goals and pitfalls,  very informative and stimulating. What is changed in this second editon? Not much and all at the same time, since Bloch have added items dedicated to Java 5 and 6 new features, and he reviewed about all contents updating it, giving even more ideas.

Yep, IDEAS. It’s the great plus of this (and few others books), it give you ideas and stimulate your own thought and investigation instead of just explain author’s point of view.

IMHO the first edition have been one of most important books in java initial success in fall 2001. I’m not sure this second edition would become so much important for this new Java developer generation as it was for my generation, but in my humble opinion they should read it. And not only them, but also for older boys like me.

In 2001 Java was different, java community was different, and I was different too. I was a young developer who had just moved to java (my first serious enterprise project had started in late 2000), java is a fair new language, with an enthusiast community. Today Java is much more consolidated, even if it’s starting to demonstrate some oldness symptom. Today Java community is much bigger, have provided great libraries and have guided some of best evolution of the language, maybe  a little less enthusiast. The new edition of Effective Java reflect all this points, and it’s important to keep it’s value: helping reader to think and get ideas.

And how am I changed since 2001? Well I’m now a software architect (the right kind of architect ) coaching about 20 developers and managing bigger developments and environments. I’m not changed too much: I still be enthusiast, I still be a developer and a technology passionate. What is changed is my point of view. As architect and (agile) coach I read this book thinking how great or bad code can influence my system, eventually enforcing or breaking my design. Reading this book I thought about how design is important at any level, but probably what really make a system successful is design at lower level, in other words fine design made by any single developer. It’s probably the main reason for which architect have to write code and coach have to consider its team as a chain: strong as its weakest link.

Groovy, Ruby and friends success would benefit a lot from a book like this one written for them. I don’t know nothing around similar, someone have suggestions about?

My favourite 3 items in new edition are (not easy to select just 3, but I’ll try):

1. Item 2: “Consider a builder when faced with many constructor parameters”. why? Because in a lot of case it’s better to have readable code than performance or compact code. Frankly Java doesn’t help too much…so patterns and best practices are important.
2. Both Item 15: “minimize mutability” and Item 40: “Design method signatures carefully”. No comments needed right?
3. Item 26: “Favour generic types”. Generic types are very expressive, compact and flexible. Not so easy for all people, but too powerful…insist with developers to design generics type!

Well a special mention to chapter 10 “Concurrency” to few developer use concurrency effective…it’s the god and bad of J2EE…but real developers should design at least a serious concurrent application to perfect their skills.

Your preferred items?

One of the use case for witch a SOA (ESB) solutions is recommended is when you have to manage a complex “technology heterogeneous” environment.

Well, I’m thinking about a good design for some new important feature to be added to our complex environment. Our environment is indeed complex, with wide impact, with heterogeneous needing, but it is quite homogeneous in technology. OK, it isn’t a monolithic system, it is build by a lot of part, but a lot of this part are java(2ee)/oracle based.

But the question is:do I like to keep my system so homogeneous? IOW if I invest a lot of money adding these new features to my system, which involve to use/review most of developed software, is it really the right choice to keep it all based on java?

I’m a java guru and fun using it as my main development language in last 10 years, but my answer is

NO

Why NO? Because if I take a look behind in the past I can see a lot of system architects answering “yes!” at same question 20 years ago substituting “Java” with “COBOL”. And a shudder come on my back…would I really sentence my system to be so strictly coupled with a single technology and loose flexibility and cool feature of newer technology? I’m not sure Java will become the next COBOL going to be static and legacy, but for sure, if I would answer yes I would be disown my ideas of “open system”.

There are so good languages and technologies kicking around, which probably solve better some kind of problem. Groovy, Scala and Ruby are the most famous, but we have also Erlang, Factor (with good ideas and a friend of mine behind), and even more legacy language like perl could have its place in some specific use cases. In general if something could be more productive or more flexible than java for some specific problem, I’d like to keep doors open. Randall did an interesting post saying java developers should learn other languages, I make a step over saying java developers should USE other languages

I’ve been always open to new technology and solution, would I miss my freedom of choice in favour of my beloved language? No, my freedom is much more important than java

Designing my new system I would use best technology and language for each part of the system. It’s always a good decision, the good news is integration of these parts could be seamless and painless, we haveSOA/ESB solution.

My conclusion is that isn’t necessary to have heterogeneous system to go for SOA, probably is the contrary: nowadays we need heterogeneous system to be time to market, to have easier maintenance, and so we need SOA to build and manage it.

SOA and heterogeneous technology environment seems to be the  eggs and chicken problem

Thoughts?

Just received a link to this on one of my subscribed mailing lists… http://blog.softwhere.org/archives/196

For those who are interested in open source milestones…