Johannes Brodwall

In this example, it's about 30 lines of boilerplate code. I find that creating a library creates more hassle than it's worth.

It sounds like you too have experience creating your own stuff, which I think is great. Personally, I find that annotations seldom improve my code and I most definitely find that commons-lang doesn't improve my code.

A question: Something I find hard to get right with annotations is automatic reloading. If you change the contents of the config file runtime, will the change be reflected without a restart?

In this example, it's about 30 lines of boilerplate code. I find that creating a library creates more hassle than it's worth.

It sounds like you too have experience creating your own stuff, which I think is great. Personally, I find that annotations seldom improve my code and I most definitely find that commons-lang doesn't improve my code.

A question: Something I find hard to get right with annotations is automatic reloading. If you change the contents of the config file runtime, will the change be reflected without a restart?

In this example, it's about 30 lines of boilerplate code. I find that creating a library creates more hassle than it's worth.

It sounds like you too have experience creating your own stuff, which I think is great. Personally, I find that annotations seldom improve my code and I most definitely find that commons-lang doesn't improve my code.

A question: Something I find hard to get right with annotations is automatic reloading. If you change the contents of the config file runtime, will the change be reflected without a restart?

Hi Shivam

The article has nothing to do with your question. But I will give you three answers anyway:

1. The article is about using Selenium, Webdriver API and PhantomJS to test web applications written with NodeJS. The performance of the language is irrelevant in this setting.

2. I imagine you mean to ask whether NodeJS is faster than PHP. I don't know. NodeJS is created with the aim to be scalable for certain class of applications. Here is a benchmark showing NodeJS being faster: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php. But benchmarks won't tell you what the effect will be for you.

3. But most importantly, your performance problem is not your programming language. 99% of applications in the real world could be made fast enough in any programming language if they were programmed well. A poorly written program in would still give performance problem in the fastest language. Your question indicates to me that you belong to this 99%.

If you are experiencing performance problems, the right recipe is not to switch languages. If you're not, whether you decide on PHP or NodeJS will not be what creates performance problems for you.

Hi Shivam

The article has nothing to do with your question. But I will give you three answers anyway:

1. The article is about using Selenium, Webdriver API and PhantomJS to test web applications written with NodeJS. The performance of the language is irrelevant in this setting.

2. I imagine you mean to ask whether NodeJS is faster than PHP. I don't know. NodeJS is created with the aim to be scalable for certain class of applications. Here is a benchmark showing NodeJS being faster: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php. But benchmarks won't tell you what the effect will be for you.

3. But most importantly, your performance problem is not your programming language. 99% of applications in the real world could be made fast enough in any programming language if they were programmed well. A poorly written program in would still give performance problem in the fastest language. Your question indicates to me that you belong to this 99%.

If you are experiencing performance problems, the right recipe is not to switch languages. If you're not, whether you decide on PHP or NodeJS will not be what creates performance problems for you.

Hi Shivam

The article has nothing to do with your question. But I will give you three answers anyway:

1. The article is about using Selenium, Webdriver API and PhantomJS to test web applications written with NodeJS. The performance of the language is irrelevant in this setting.

2. I imagine you mean to ask whether NodeJS is faster than PHP. I don't know. NodeJS is created with the aim to be scalable for certain class of applications. Here is a benchmark showing NodeJS being faster: http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php. But benchmarks won't tell you what the effect will be for you.

3. But most importantly, your performance problem is not your programming language. 99% of applications in the real world could be made fast enough in any programming language if they were programmed well. A poorly written program in would still give performance problem in the fastest language. Your question indicates to me that you belong to this 99%.

If you are experiencing performance problems, the right recipe is not to switch languages. If you're not, whether you decide on PHP or NodeJS will not be what creates performance problems for you.

Thank you for the kind comment, Lund.

The important part about technologies is that architects often dictate technologies without having compared the technologies with alternatives through actual use. Or indeed even used the technology at all. It sounds like you've made a thoughtful consideration about JAX-WS and reached a different conclusion than me. As you point out, the goal in my article is to focus on the "thoughtful" part.

Thank you for the kind comment, Lund.

The important part about technologies is that architects often dictate technologies without having compared the technologies with alternatives through actual use. Or indeed even used the technology at all. It sounds like you've made a thoughtful consideration about JAX-WS and reached a different conclusion than me. As you point out, the goal in my article is to focus on the "thoughtful" part.

Thank you for the kind comment, Lund.

The important part about technologies is that architects often dictate technologies without having compared the technologies with alternatives through actual use. Or indeed even used the technology at all. It sounds like you've made a thoughtful consideration about JAX-WS and reached a different conclusion than me. As you point out, the goal in my article is to focus on the "thoughtful" part.

Java EE 6 fixed many problems with J2EE to be sure. But by the time it came out, I had learned to get by without it (and to love getting by without it).

If we ever happened to work together, though, I'd love to have you change my mind. ;-)

Java EE 6 fixed many problems with J2EE to be sure. But by the time it came out, I had learned to get by without it (and to love getting by without it).

If we ever happened to work together, though, I'd love to have you change my mind. ;-)

Thank you for the nice comments and your insights, Jakub.

To be sure - my point was for the architect to avoid pushing technological choices and especially heavy technology onto developers. I have a personal bias towards a very simple technology stack (in Java), but that's beside the point.

Thank you for the nice comments and your insights, Jakub.

To be sure - my point was for the architect to avoid pushing technological choices and especially heavy technology onto developers. I have a personal bias towards a very simple technology stack (in Java), but that's beside the point.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which removed the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

The applications tended to blossom in complexity as either the culture, the tool, the documentation or something else made developers build unnecessary layer upon unnecessary layer.

Later, I tried to build applications without a Dependency Injection framework, but taking with me the lessons about when to use "new", when to have a setter or a constructor argument and which types were good to use as dependencies and which created coupling to infrastructure.

So I found that some of the instincts that the DI container had given me made me improve the design, but at the same time, I found that when I removed the container, the solution became smaller (which is good!), easier to navigate and understand and easier to test.

This leaves me with a dilemma. I found that the cost of using the container is very high - it creates a force towards increasing complexity and size and reduced coherence. But at the same time, it taught me some good design skills as well.

In the end, creating a coherent, small system is to me of much higher value than to create one that is decoupled just of the case of decoupling. Coherence and decoupling are opposing forces and I side with coherence.

At the same time, I found that the culture around dependency injection has a very strong preference for reuse. But reuse does introduce coupling. If module A reuses module B, module A and B are coupled. A change in B might affect A for better (a bug fix) or worse (an introduced bug). If the savings from the reuse are high, this is a trade-off worth making. If the savings are low - it is not.

So reuse and decoupling are opposing forces. I find myself siding with decoupling.

When there is a conflict, I value Coherence over decoupling and decoupling over reuse. The culture where Spring is in use seems to have opposite values.

I'll language wars to zealots. :-)

I'll language wars to zealots. :-)

I'll language wars to zealots. :-)

It sounds like your experience is different than mine, Nicolas. Are you saying that to you, the main time consumption when you come into a new system that you maintain is whether they used the "correct" framework and whether they put the curlies on the correct line, rather than understanding the business logic or the bulk of the system?

It sounds like your experience is different than mine, Nicolas. Are you saying that to you, the main time consumption when you come into a new system that you maintain is whether they used the "correct" framework and whether they put the curlies on the correct line, rather than understanding the business logic or the bulk of the system?

It sounds like your experience is different than mine, Nicolas. Are you saying that to you, the main time consumption when you come into a new system that you maintain is whether they used the "correct" framework and whether they put the curlies on the correct line, rather than understanding the business logic or the bulk of the system?

Oh, I've built good web applications on J2SE + Jetty. I wouldn't object majorly to throwing in a bit of Spring-MVC (as long as I can keep away from the XML madness) and Hibernate. But in general, I've found that most of the J2EE stack costs so much more in debugging effort than it ever saves in development effort...

In my last application, I could run the whole system within a JUnit (integration) test, I could perform most changes while running the debugger in Eclipse (or IDEA), I could restart the application on 5 seconds and I could deploy and restart a new version in about 30.

These things are hard to do with an app server, but trivial without it. E.g. JBoss is a faustian bargain.

Oh, I've built good web applications on J2SE + Jetty. I wouldn't object majorly to throwing in a bit of Spring-MVC (as long as I can keep away from the XML madness) and Hibernate. But in general, I've found that most of the J2EE stack costs so much more in debugging effort than it ever saves in development effort...

In my last application, I could run the whole system within a JUnit (integration) test, I could perform most changes while running the debugger in Eclipse (or IDEA), I could restart the application on 5 seconds and I could deploy and restart a new version in about 30.

These things are hard to do with an app server, but trivial without it. E.g. JBoss is a faustian bargain.

Thank you for the positive feedback., Johan

When it comes to performance, I've considered implementing a event-based subtree parser, but I haven't found a syntax I'm happy with yet. The code base includes tests with up to one million elements and a document of more than 1 MB with no problems.

I'd like to take up the challenge of building a partial parser: Do you have a suggestion for what the syntax could look like?

Mappers like JAXB does indeed produce XML, but they force you to generate a seperate set of classes and write code to map your internal objects to these generated object. In other words: It's a trap!

I would challenge you take a look at generating XML with a library like my own or JOOX just for comparison.

Thank you for the positive feedback., Johan

When it comes to performance, I've considered implementing a event-based subtree parser, but I haven't found a syntax I'm happy with yet. The code base includes tests with up to one million elements and a document of more than 1 MB with no problems.

I'd like to take up the challenge of building a partial parser: Do you have a suggestion for what the syntax could look like?

Mappers like JAXB does indeed produce XML, but they force you to generate a seperate set of classes and write code to map your internal objects to these generated object. In other words: It's a trap!

I would challenge you take a look at generating XML with a library like my own or JOOX just for comparison.

Thank you for the positive feedback., Johan

When it comes to performance, I've considered implementing a event-based subtree parser, but I haven't found a syntax I'm happy with yet. The code base includes tests with up to one million elements and a document of more than 1 MB with no problems.

I'd like to take up the challenge of building a partial parser: Do you have a suggestion for what the syntax could look like?

Mappers like JAXB does indeed produce XML, but they force you to generate a seperate set of classes and write code to map your internal objects to these generated object. In other words: It's a trap!

I would challenge you take a look at generating XML with a library like my own or JOOX just for comparison.

Thank you for your comment, Mitja.

I totally agree with your remarks. I left out the caching to avoid introducing more concepts in this article, but when I've experimented with it, I have it in place.

I agree that view processing really should happen on the client, so my idea here is at least a few years late. I am probably fighting yesterday's battle, but I couldn't sleep without sharing the idea. :-)

Thank you for your comment, Mitja.

I totally agree with your remarks. I left out the caching to avoid introducing more concepts in this article, but when I've experimented with it, I have it in place.

I agree that view processing really should happen on the client, so my idea here is at least a few years late. I am probably fighting yesterday's battle, but I couldn't sleep without sharing the idea. :-)

Thank you for your comment, Mitja.

I totally agree with your remarks. I left out the caching to avoid introducing more concepts in this article, but when I've experimented with it, I have it in place.

I agree that view processing really should happen on the client, so my idea here is at least a few years late. I am probably fighting yesterday's battle, but I couldn't sleep without sharing the idea. :-)

I like this approach. Much better than dragging in apache commons-lang with all the jetsam and flotsam that is attached to it. It's a good thing to stop reusing square wheels.

However, you probably want to simplify the expressions a bit:

/** Is the argument null or empty? */ public static boolean isEmpty(Collection collection) { return collection == null || collection.isEmpty(); }

Simpler and more concise. And no braindead JavaDoc. "@returns false | true" is pretty dumb for a boolean. "@param string" isn't too helpful either. :-)

My current code has an extensive unit test suite that run very close to the code. This gives speed and error locality, like the original poster describes. We have occasionally, but not very often experienced that the tests may retard our ability to refactor interfaces.

Some good experiences:

• It's seldom much work if tests that are short, fast and expressive fail because of a refactoring. (Brittleness is okay if the test is easy to understand and quick to run)
• It is okay to delete tests that are no longer relevant after the interface change.
• Code that is referred to by XML or other config files is an order of magnitude more expensive to modify.
• Creating some stable points in your application (e.g. a shared/generic DAO interface or a common Controller interface) can give you a point of testing that is isolated from a lot of refactorings, while the tests still run fast and pinpoint the failure more precisely than integration tests.

With this in mind, we find that with even the most major API changes, less than 1/3 of our time is spent fixing brittle tests. About the same amount is spent fixing bugs in the new API design that the tests pointed out.

YMMV

I've seen the same problems with horizontal reuse as Developer Dude mentions. I think it's caused by the problem that you can basically not achieve the following at the same time:

• Reuse
• Quality: The code is fit for purpose, and as Kirk mentions: usable. In order to be good, code has to evolve.
• Stability: There's not a lot of disturbing changes coming from others. Ultimately, this will lead to branching and possibly, completely forking of the code.

In order to have good code, it has to evolve, but changes will cause problems for other users of the code and other people's changes will cause problems for you. Ultimately, we may decide to split the code again and stop reusing.

I wrote a bit more about this on my blog a few months back.

As a counter point to the "doom and gloom" about reuse, I'd like to point out that the standard Java library that we reuse every day is much, much bigger than what we'd expect from a language ten years ago. So we are reusing much more. This also means that the "marked" for internal reusable code is smaller. The easy cases have been covered already.