Nicolas Fränkel

Sorry, but I don't understand. how it's related, because before you can navigate via HATEOAS links, you need to access the root entity anyway. And you need a version

Thanks for reading it

Thanks for your kind words!

Do you dismiss them because they're potentially flexible?

I mostly favor boring and maintainable code over show-off code that nobody can maintain.

But as I said, difficult to have a proper discussion in 600 chars

The only point on which I agree with you ;-)

I feel like you didn't read the post...

Gradle claims that lack of flexibility is an issue; hence, it wants to fix it. I stand by the opposite: lack of flexibility for my build tool is a feature, not a bug. Gradle makes it easy to hack the build. Hence, anybody who thinks their project is a special snowflake and deserves customization will happily do so. Reality check: it's rarely the case; when it is, it's for frameworks, not regular projects. Gradle proponents say that it still offers standards while allowing easy configuration. The heart of the matter is that it's not a standard if it can be changed at anybody's whim.

Unless it's on purpose (and I doubt it in the context), you wrote "disturbed" traces instead of "distributed" traces

Happy to help!

You should probably give the same permissions to the same people who already are able to run kubectl exec, shouldn't you?

These points are IMHO unrelated but completely valid

Hello!

Well, thanks a lot for this blast from the past!

I love GraalVM and I'm a proponent but I still think it's overkill for my use-case.

I work on software projects since a long time. When I started, we always designed complex architectures just in case something changed: we paid upfront costs, continued to pay throughout the development, and most of the time, the change that we planned for never happened. Change is a constant, but among the infinity of changes, I can bet that your design is not fit for the ones that will happen.

Now, my approach is YAGNI. When you need to change, change it.

YAGNI. New requirements may never come. They may not evolve. etc.

Good points but you could have gone much further and made it truly fluent by being compile-time valid using types instead of runtime valid using exceptions.

I explained it in this post.

On the down side, you might get a huge number of types depending on your valid object tree.

Too bad. Because Apache Pulsar is specifically designed so that you can change your compute nodes without rebalancing, making your problem disappear.

Use Pulsar? ;-)

Beware of what you find on the WWW ;-)

Here's a post on AWS Lambda with GraalVM https://blog.formkiq.com/tutorials/aws-lambda-graalvm/index.html. I didn't try it.

There's no "issue" with Spring. Whatever the framework, you can always run your JVM with a dedicated Java agent that records all interactions and generates the config file for you.

I'm not into serverless but I already read articles on how to GraalVM-ify your Java app and use it as an Amazon Lambda function.

I'm a Java developer and I hate Go (mainly because of the return Err pattern).

Anyway, I do love your the process you followed: get the sources, re-execute the tests and try to fix the issues. This is exactly what I find lacking in most comparisons I find regardless of the subject - a scientific approach.

I also am quite "specific" on semantics. In this case, I agree that a native binary starts faster than a VM but not that Go starts faster than Java. Did you know you can code in Java (or any JVM language for that matter) and compile the JAR to a native binary? If you're interested, have a look at GraalVM and its native image capabilities.

Again, great process!

I think you left out the most important point between nullable type and Optional.

You can write that in Java:

Optional<Foo> optional = null;

And now everything is broken again.

> Development is fast if you know all the traps of JSF.

Like for JavaScript. It's a crap language, but development is fast if you know all the (many) traps ;-)

I just recently used Vaadin CDI integration v3 in a teaching context and had no issue.

(Note that the Spring Boot integration is really good since the beginning)

When JSF was first released, I tried it. I remember the 7 or 8 phases lifecycle. The possibility of shortcut through the lifecycle. The fact that JSF was advertised as component-based but there was still a page-to-page navigation. End of the story.

Then I found Vaadin: a true component-oriented framework with event-based programming features. IMHO, that's what JSF should have been. Like some of the Java EE specifications, JSF was designed by very smart people who never had to work in a real-world project. As such, it's too complex with not enough benefits.

Besides, it's not because your app only loads 4 classes that only those 4 are used. For example, String is defined as:

public final class String implements java.io.Serializable, Comparable<String>, CharSequence

Hence, it will load itself and 3 additional classes.

> "So the problem with the default JRE is that it executes the all predefined .class files whether you want to or not."

I never understood how it works, the JRE changed recently or this is completely wrong. If a class is not required, then it's just not loaded into memory and that's all. The only downside of a monolithic rt.jar is that it takes space - and that's a no-go on embedded device.

> Scientific studies that OOP results in better readability?
I'm afraid you didn't read my post, or at least the conclusion, because that's exactly the question I ask.

That doesn't allow you to call OOP whatever code you happen to write in Java.

Quite the opposite, actually. It's just that I don't agree with most developers who think whey use OOP just because they code in Java, and they have getters and setters, etc. I'm (unfortunately?) quite used to the layered architecture and the anemic domain model, as I was taught them first.

Thanks Alexey,

Actually, I know the guy personnally, and though we don't always agree, I think he's quite good at pure OOP design - to the point where he pursues OOP for the sake of it.

Then, let me refer you this post.

I completely agree with you!

Yet, one cannot deny that Spring (and Java EE) code generally doesn't co-locate state and behavior. I just wanted to prove it's possible.

Thanks for your comment.

If you compare the number of steps, sure, your solution is better. But if you check the image size, then you have one single image file weighting 304 MB, while I have 2 weighting respectively 28 MB for Git and 116 MB for Maven.

So it all boils down to your objectives: reducing the number of steps, or having lightweight images.

Pretty smart hack, but still a hack :-)

It's not about new, it's about that one little feature that changes a lot. For me, that feature is extension functions. I don't care that it's present in language X or Y, it just allows me to write much cleaner and readable code than static methods in *Utils classes.

I don't see in this post what problem I pointed out in Scala. I describe a generic problem, and check how Kotlin and Scala handle it.

I love a good debate, so instead of refering to generalities or using fallacies, please point out detailed arguments. Otherwise, I'm afraid your comment(s) has(have) not added value to the community.

It doesn't compile.

It's always funny to see such "argument" (cf. Ad hominem logical fallacy).

I beg to disagree. The exception-throwing code has been written, and is available. It's not because you don't use it that a developer won't.

It just feels like trying to put a square peg in a round hole: Java is not made for that.

IMHO, overriding a method to throw an exception at least defeats the principle of least surprise, and at worst is a design flaw. You didn't remove exception, you just pushed them udner the rug.

Code coverage is a useless metric that project managers like because 1) it's a metric 2) they can understand what it means.

Unfortunately, some things definitely have more dimensions that can be put in an Excel Sheet, such as assertless tests, or boundaries testing, etc.

Please kill code coverage so we can focus on the real subject - tests quality.

1. I never wrote that. I just stated, it's not proper OOP

2. As soon as you write a getter, you'll soon have getA().getB().getC() in your codebase. Discipline is as good as the laziest team member.

3. Good we agree

I've seen several attempts to do without getters and the hoops you have to jump through are hideous, very much anti-KISS

I've seen that as well, with the same problems.

It seems we more or less agree. My point was that encapsulation or future validation are no reason to write accessors.

That's why you have decorators, and all those nice design patterns.

You're already stating an implementation detail... Let's design the system first, then we can talk about encapsulation.

In your example, then the Car should know how to register itself into the cache manager. Again, you don't need to access its state.

I like stupid examples :-)

But in OOP, you should never query about the state of an object. If you need the license plate for car control, then you ask the Car to check its own license plate, you don't access the data.

Car.checkValidLicensePlate()

Could you elaborate on that? Because I don't see any relationship between accessors and interfaces right now...

If you write getters and setters:

1. You are not doing proper OOP

2. You do not understand true encapsulation

3. If you do that for a possible future validation, YAGNI

The only reason for writing accessors is because most (all?) java libraries assume the JavaBean model.

I heard that a lot. Care to elaborate about a getter being "only" an implementation detail? And no, there will never be any formatting or whatever involved.

Why would I use it? To highlight the Pavlov reflex most people have to generate a getter. Because in that case, it's not necessary.

Now, I fully agree with your point. Principle of least surprise, etc.

My point was: stop calling encapsulation $$anonymous$$ property and its associated getter.

Why would you want your fields to be private if they cannot be changed (like String)?

Ok, your example convinced me. Thanks for the clarification (and your patience ;-))

For encapsulation, I've written my arguments there: https://blog.frankel.ch/encapsulation-dont-think-means-think-means/, so I won't repeat myself. I'd be happy to talk further about it if you're interested.

As for the final on class, I still don't get it. If you can override methods, those overriden methods still cannot change final parent fields. So, EvilSpaceship is still immutable. Only if it adds additional fields that are not final, then it might mutable.

Great article, providing advantages of immutability I didn't formerly think about.

Just nitpicking, but if the type of a field is immutable (like String in your spaceship example), it's not necessary to have it private: public is enough. I admit this is rather strange, but it works.

Also, the class can be not final if all its fields are final. This shouldn't be a requirement IMHO.

Generally speaking, Spring Boot applications do not need child contexts.

Dependency Injection in general - and Spring in particular, allows to mock/fake dependencies and be able to test the class "in insolation". I fail to understand why injecting the logger would be better than creating it in that regard. Plus you need to write as much (if not more) code to inject the logger nonetheless; hence you've got boilerplate code also.

I can understand declaring the logger is a tedious task. In that case, I'd just create the relevant aspect and use AOP to achieve that. Or Lombok as Jonatan proposes. In both cases, that might be a hammer to squat a fly, though

Or, you know, just use this thing called a build tool and configure plugins to have be done for you

You can do even better. With Spring new versions, you can remove the @Autowired annotation entirely on the constructor.

Happy to have been of service ;-)

That started well enough until "Use Dependency Injection With Autowired Services", I stopped reading after the code snippet featuring field injection.

Long talk short, even Spring engineers advocate against field injection: I let you read the full article, no need to rant against that practice here again.

It's not about annotations, it's about style: explicit injection vs autowiring. If you're using explicit, there's nearly a 1-1 mapping between Guice and Spring.

This comparison is only focused on Spring self-annotated classes without taking into account JavaConfiguration. This post - sadly like many others, pretend to compare Spring that was 10 years ago.

Quite interesting. But you don't solve the initial problem: the junior developer might forget to use your API and catch silently - or do any of the things you don't want.

In that case, you should use AOP: it's clean and there's no place for error. And in that case, you'd customize the handling of the exception in the aspect itself, thus making your API not so useful.

By the way, regarding your design, using static methods make clients of your API completely unit-untestable. You might want to change that.

Reply or no reply, it doesn't change a thing. Java EE is the realm of application server vendors and customers who need to have someone to blame. But how many companies are running Tomcat? How many do have issues? Most don't really need the whole Java EE stack. Basically, only a few API are needed: Servlet, JMS, JPA (& JDBC), CDI, JAX-RS and perhaps a few I've forgotten. The rest? Useless... or worse. Batch is a pale copy of Spring and shouldn't have been part of EE. This was a shrewd move on the part of the vendors, so they can sell their high-priced ***ware. And now a MVC? Come on! I've always worked in the Java world with different application servers but this Java EE trend is becoming a tragedy.

JavaEE is dead, nobody cares about it so why would you guard a dead abandoned body?

I think your reasoning (without proof) makes for a great opportunity to learn... I wish you an interesting life ;-)

"@Autowired annotation makes our lives easier"

Not at all! It's just an evil snake waiting to bite you at the worst possible moment. It works until it doesn't anymore. It makes your app's structure completely unreadable. It also couples your classes and reduce re-use.

Could we please all switch to Java Config? Pretty please?

Thanks, it's now readable but there are still formatting issues (blank lines, indentation, HTML entities) that make it harder to read.

Code formatting is a mess... How can people "like" this?

I've checked the JavaDocs many times, nothing says calling Connection.close() will close underlying objects. And the Tomcat interceptor is a good hint that it's not a driver's defect but the standard way.

I've checked the JavaDocs many times, nothing says calling Connection.close() will close underlying objects. And the Tomcat interceptor is a good hint that it's not a driver's defect but the standard way.

I've checked the JavaDocs many times, nothing says calling Connection.close() will close underlying objects. And the Tomcat interceptor is a good hint that it's not a driver's defect but the standard way.

I've checked the JavaDocs many times, nothing says calling Connection.close() will close underlying objects. And the Tomcat interceptor is a good hint that it's not a driver's defect but the standard way.

Wake up Fabien, it doesn't work...

Wake up Fabien, it doesn't work...

Wake up Fabien, it doesn't work...

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

You're welcome, but you only owe to you that you followed the path I only showed :-)

But encapsulation decreases testability.

But encapsulation decreases testability.

Congrats, James, this is fame!

Thanks for this good piece of humor! I know that architect-bashing is popular nowadays, but this "article" is at the top of my list...

At least you have the decency to be truthful:

Granted, I don’t often work with maintenance

So perhaps requirements apply to people that don't apply to you? If you're concerned with developing an application, please consider that others may have other concerns (maintainance, using existing skillset, integrating within the existing information system, and so on)

Oh yes, one last thing, I assume you are a developer who display the same humility that you expect from others, since you are the proven expert of which technologies are worth and which are not.

May you live in interesting times!

Site must be down :-(

Site must be down :-(

Site must be down :-(

Site must be down :-(

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

Hello Robert,

This is adequate, until you have parameters dependent on one another, like in the house example.

I agree that the "Architect" title is sometimes used to charge customers more. However, the problem lies as much on the customer side, as on the salesperson side.

What you're referring to is to have a professional pressure group define the do's and dont's of a particular job. I don't know how it is in the US, but in France such groups include the "Ordre des Medecins" for doctors, "Ordre des Avocats" for lawyers, and so on. In general, those are ancient professions that a. earned the privilege of ruling themselves b. spend much time defending all their advantages instead of the well-being of the society in general. In particular, our lawyers lobbied so you cannot get divorce without a lawyer (one for each side, of course). So, I wouldn't go that way...

Besides, there's no "Architect" per se: I'm generally using the Software Architect title because it makes managers more comfortable. In front of developers, I'll probably say I'm a (Senior) Developer. But I seldom tell people I'm an Enterprise Architect though I've successfully passed the TOGAF certification.

I let some wise words conclude my point:

The purpose of a fishtrap is to catch fish, and when the fish are caught, the trap is forgotten.
The purpose of a rabbit snare is to catch rabbits. When the rabbits are caught, the snare is forgotten.
The purpose of words is to convey ideas. When the ideas are grasped, the words are forgotten.

Perhaps because profiles do not seem to meet my requirements regarding proxies and servers ?

Btw, my first name is spelled Nicolas, without an 'h'

Perhaps because profiles do not seem to meet my requirements regarding proxies and servers ?

Btw, my first name is spelled Nicolas, without an 'h'

Perhaps because profiles do not seem to meet my requirements regarding proxies and servers ?

Btw, my first name is spelled Nicolas, without an 'h'

Builders are very good from a "user" point of view. But if you are the API developer, things tend to get complicated.

Builders are to create objects: but then, the build() method that returns the final object should only be called in a stable state. Moreover, method chaining isn't always idempotent, meaning method calls may have to be ordered. Therefore, as your article describes, you need intermediate classes, and may be in numbers. At this point, I can only give your praises: it tries once with only a couple of limited cases, and that was complex.

Scala is much more adapted to those complex cases, with dynamic types (A with B).

Try using another in-memory DB, like H2. I think H2 is the newer version of HSQLDB

Try using another in-memory DB, like H2. I think H2 is the newer version of HSQLDB

Try using another in-memory DB, like H2. I think H2 is the newer version of HSQLDB

Try using another in-memory DB, like H2. I think H2 is the newer version of HSQLDB

The days of using MySQL, DB2, PostgreSQL etc for development are over. I don’t know why any programmer would develop with them.

Alternatively, Programming-by-contract could solve this problem: if you could annotate your code with post-conditions, callers would clearly see the intent.

For example:

@NotNull

public Fruit findFruit(...) {

...

}

Beware irony when it is not readily apparent; when I read the title, I began cursing the author...

The main argument against using both in the same project is Fabrizio's: assert arguments are opposite in JUnit & TestNG (actual vs expected). Just migrate and be done with it.

Hi Sarah,

I'm also a TestNG proponent and I agree with most of your article. Where I heartily disagree is to use both. What's the point? TestNG can do everything JUnit does!

Remember the KISS principle...

Following my article, Oliver Gierke created this Jira. It seems the two of you disagree...

Following my article, Oliver Gierke created this Jira. It seems the two of you disagree...

Well, it's how it's described in the documentation. You're welcome to unit-test their assertions, I would really be interested in the results.

Well, it's how it's described in the documentation. You're welcome to unit-test their assertions, I would really be interested in the results.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

Silliness depends on your point of view. I have a use-case when default beans have to have a scope narrower than singleton.

You do owe me some royalities here: http://java.dzone.com/articles/method-injection-spring

:-)

Hi Seb,

I tend to frown on AOP, but that depends on my team skill. Anyway, this a great idea. Thanks!

Hi Seb,

I tend to frown on AOP, but that depends on my team skill. Anyway, this a great idea. Thanks!

Hi,

You forgot Cloud Foundry brought by VMWare.

@Witold and Stuart,

I understand the situation is quite strange and I'm afraid I wasn't clear enough, so here's another try. Implementing Web Services in my organization is quite a nightmare:

• I will need to create another EAR just for WS, in order for it to be deployed on a specific mutualized WS server
• Each WS call will be authentified on the proxy, thus incurring a huge performance decrease. Besides, it happens sometimes the authentication mechanism on the proxy doesn't work.

As for a pure EJB solution, I prefer someone else to handle all problems that occur on any technology first use.

Hope my stance is clearer now.

Hello Erik,

Thanks for your excellent feedback! I updated the code with all your comments (only the TextField has to keep the attribute since the first parameter is the label, not the value).

I encourage you to contact the Scaladin developer on the add-on page to suggest builders for components. If not enough experience in Scala to know if there are reasons no to do it.

I was expecting much from your title, sadly, your content only gives weight to people telling the code should be self-sufficient.

1. Any good IDE worth is salt renders this point moot. Really, are we back to vi?
2. See point 1
3. OK
4. No please! Don't do that... ever! Just use a SCM and be done with this practice from before
5. Cannot understand the sentence
6. Requirement ID would be OK. Once the bug is closed, however, I could care less there was one in the first place, so this only clutters the code and make it less readable

IMHO, annotations are markers; they shouldn't provide any behavior intrisiquely: on the contrary, annotations should be hints for code to manage the annotated class in a different way.

In this light, while annotations stay the same, different codes would manage the annotated class differently.

"Help" should be more precise in your article's title: IMHO, the shared library strategy shouldn't be approached only from a memory point-of-view. Shared libraries also let us enforce enterprise (or projects) policies like set version(s) for libraries. It also put the responsibility from the developer to the server admin for providing the right libraries in the right version.

In the last case, I was once confronted with a library that had been modified by a previous developer so that the JAR contained many more classes and was only vaguely related to its name :-/

While I agree moving libraries from each deployed package to the server reduces agility, technologies such as OSGI can help us reduce the consequences while still bringing the aforementioned benefit.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

I also prefer XML to annotations because of coupling :-) only not for transactions.

Spring's XML way of dealing with transaction is way too decoupled for junior (or even senior in some cases) developers. Pattern matching is a little bit dangerous for something as critical as transations, don't you think?

But the heart of the matter is the last point you raise: transactional behavoir shouldn't be part of the design contract for you; for me it should.

This is my package-info.java:

@XmlJavaTypeAdapter(JaxbAdapter.class) package a.third.party.package; import javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter; import ch.frankel.blog.jaxb.JaxbAdapter; 

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

@Fabien

If you're even more radical (like myself), have a look at Vaadin. It generates HTML/JS/CSS for you and in the context of a simple CRUD application, you have containers that can directly connect to the database.

Hi Thomas,

Sorry to disappoint but there isn't such a chapter now. Perhaps for the second edition?

Cheers!

Hi Thomas,

Sorry to disappoint but there isn't such a chapter now. Perhaps for the second edition?

Cheers!

Hi Thomas,

Sorry to disappoint but there isn't such a chapter now. Perhaps for the second edition?

Cheers!

Hi Dave,

It's Indigo without SR1 and I didn't search for a bug... Too accustomed to be on my own I guess :-)

Hi Dave,

It's Indigo without SR1 and I didn't search for a bug... Too accustomed to be on my own I guess :-)

Hi Dave,

It's Indigo without SR1 and I didn't search for a bug... Too accustomed to be on my own I guess :-)

Hi Dave,

It's Indigo without SR1 and I didn't search for a bug... Too accustomed to be on my own I guess :-)

Strange: despite all your years, you never realized Eclipse/Tomcat integration (or even better, Eclipse/Glassfish) let you not deploy your application in the painful process you describe. Too bad...

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

The APR is a native library that you may install during Tomcat installation. It does tie your Tomcat to your OS but "provide superior scalability and performance". This is a good thing to do for your production environment. In other environments, I don't see the point.

You can see more info on the Tomcat website.

Hi,

I think the root of the problem lies in that you're using the Apache Portable Runtime, and I'm not. I think you should look into this direction.

Hi,

I think the root of the problem lies in that you're using the Apache Portable Runtime, and I'm not. I think you should look into this direction.

Hello,

You matrix is interesting; yet, there's a point you fail to mention. By default, all classes on the classpath are available for injection in CDI whereas only those referenced are in Spring.

Since this is a big source of potential problems, I think you should mention it.

Very nice article.

Just an additional info: if your webapp uses HTTPS, you'll need ZAP to generate a dummy certificate (Options -> Dynamic SSL Certificates, Generate button) or import the real one before going further otherwise it won't work. Then accept the browser's security warning if there's one.

John,

Concerning the link, you can check the Red Hat knowledge base, provided you have a Red Hat account with paid support associated.

Second, I completely agree with the provided scope. The problem lies in that as of now, Red Hat doesn't guarantee the binary compatibility of an Open Source library versus a signed one. That means my code may compile just fine with the OS one, and then explode during runtime due to such a incompatibility!

John, I'm sorry if I mislead you into thinking that open source projects must create their own repos. My point is exactly the contrary: use repo1!

As for your question, yes, the binaries from EAP are not the same from the community edition: they are signed and Red Hat cannot guarantee they are compatible with their open source equivalent!

John, I'm sorry if I mislead you into thinking that open source projects must create their own repos. My point is exactly the contrary: use repo1!

As for your question, yes, the binaries from EAP are not the same from the community edition: they are signed and Red Hat cannot guarantee they are compatible with their open source equivalent!

John, I'm sorry if I mislead you into thinking that open source projects must create their own repos. My point is exactly the contrary: use repo1!

As for your question, yes, the binaries from EAP are not the same from the community edition: they are signed and Red Hat cannot guarantee they are compatible with their open source equivalent!

John, I'm sorry if I mislead you into thinking that open source projects must create their own repos. My point is exactly the contrary: use repo1!

As for your question, yes, the binaries from EAP are not the same from the community edition: they are signed and Red Hat cannot guarantee they are compatible with their open source equivalent!

package com.sivalabs.springmvc.config;

import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
import org.springframework.core.io.ClassPathResource;

/**
 * @author SivaLabs
 *
 */
@Import({RepositoryConfig.class})
@Configuration
public class AppConfig
{
 //<context:property-placeholder location="classpath:application.properties"></context:property-placeholder>
 @Bean
 public PropertyPlaceholderConfigurer getPropertyPlaceholderConfigurer()
 {
 PropertyPlaceholderConfigurer ppc = new PropertyPlaceholderConfigurer();
 ppc.setLocation(new ClassPathResource("application.properties"));
 ppc.setIgnoreUnresolvablePlaceholders(true);
 return ppc;
 }
}

Here @Import({RepositoryConfig.class}) is the same as the xml version: <import resource="applicationContext-dao.xml"></import>

I am amazed to see how far this XML-bashing trend go: should we be so happy to have replaced a single line XML with 1 line of compiled Java annotation? What's the damn point?

XML is not bad when you have the right tool. Just use Spring IDE and be done with it!

PS: sorry, your post could be interesting but I couldn't muster the courage to get past this part...

This makes sense so I guess it has the least chance to finally be chosen... -- grumble --

This makes sense so I guess it has the least chance to finally be chosen... -- grumble --

This makes sense so I guess it has the least chance to finally be chosen... -- grumble --

This makes sense so I guess it has the least chance to finally be chosen... -- grumble --

Hi Andrew,

Thanks for this interesting article. I'd like to raise two points, though:

• IMHO, off-the-shelf Mock frameworks are a good thing when applied to "standard" API. I don't want to code for the umpfteenth time the behaviour I want from a mock HttpServletRequest. In this case, I'm much more productive running to Spring's mocks API or MockRunner
• Also, the title of your last paragraph may be misleading "Integration tests: when it's impossible to isolate dependencies". Integration tests are much more than unit tests that cannot run in isolation due to bad (or legacy) code design. So, I must disagree with your definition :-)

"As Java becomes less and less of a client-side language, we expect to see educational institutions switch to other languages for primary education, ones with stronger client-side representation such as JavaScript and HTML 5. Over time, developers will begin to view Java as a server-side language for enterprises — like COBOL."

Please, can someone who is more technically oriented than me tell me how can Java be less of a client-side language and be viewed as a server-side language for enterprises?

I'm really amazed to read such things...

Why use static methods at all? If you use Spring, beans are singleton by default. The only pertinent use case is mocking a static method from a third-party library, which is not apparent from your example.

What's the point in designing static methods? They make your code far more complext to test, and you have to use powerful tools in order to still test them. I wish good luck to the poor developer who has to do the maintenance of your projects, once you're gone...

Why use static methods at all? If you use Spring, beans are singleton by default. The only pertinent use case is mocking a static method from a third-party library, which is not apparent from your example.

What's the point in designing static methods? They make your code far more complext to test, and you have to use powerful tools in order to still test them. I wish good luck to the poor developer who has to do the maintenance of your projects, once you're gone...

Thanks.

I did not look in detail what the ICEPushServlet did. Yet, that you instantiate a new servlet in your filter seems very fishy to me. Just my 2 cents...

Thanks.

I did not look in detail what the ICEPushServlet did. Yet, that you instantiate a new servlet in your filter seems very fishy to me. Just my 2 cents...

Thanks.

I did not look in detail what the ICEPushServlet did. Yet, that you instantiate a new servlet in your filter seems very fishy to me. Just my 2 cents...

Thanks.

I did not look in detail what the ICEPushServlet did. Yet, that you instantiate a new servlet in your filter seems very fishy to me. Just my 2 cents...

That may be caused by the fact that in order to avoid NullPointerException, you write :

CONSTANT.equals(myvar)

myvar.equals(CONSTANT)

When a junior developer sees this for the first time, he usually questions it. When he gets the answer, there's a chance he will do it again everytime, even for no reason.

Simple and to the point. You read my mind (or my article): it's not only true for XML vs Jason but you can generalize for TechX vs TechY.

When you hold a hammer, everything looks like a nail!

Hi,

You can also consider another option and use @Transactional in conjunction with <tx:annotation-driven />. It will let you choose which method you would want to make transactional and not make them so by default (which is what you did with the * pattern). As of now, it is my prefered method for managing trasactions (at the cost of coupling my code to Spring).

Dear Cosmin,

The point of this article is that though much of Java has compile time checking, this particular issue has not. I just make readers aware that Scala handles the problem, not more, not less.

Dear Cosmin,

The point of this article is that though much of Java has compile time checking, this particular issue has not. I just make readers aware that Scala handles the problem, not more, not less.

Dear Cosmin,

The point of this article is that though much of Java has compile time checking, this particular issue has not. I just make readers aware that Scala handles the problem, not more, not less.

Never happened to me... yet. But if it's your concern, JET lets you optionaly specify a trial period.

Never happened to me... yet. But if it's your concern, JET lets you optionaly specify a trial period.

Thanks for you advice... it is probably true. I am going to change it tonight.

--edit--

I tried and found the hard way it's a bad idea (undo didn't work :-)). Weld cannot proxy classes which have final methods. Guess what? Swing is full of them... Back to singletons.

Thanks for you advice... it is probably true. I am going to change it tonight.

--edit--

I tried and found the hard way it's a bad idea (undo didn't work :-)). Weld cannot proxy classes which have final methods. Guess what? Swing is full of them... Back to singletons.

Thanks for you advice... it is probably true. I am going to change it tonight.

--edit--

I tried and found the hard way it's a bad idea (undo didn't work :-)). Weld cannot proxy classes which have final methods. Guess what? Swing is full of them... Back to singletons.

Hi,

Interesting article but it seems to me that you miss some important point:

• you constantly refer to website. The first thing to ask yourself is what you develop is mainly site or mainly application. In the case of an application, customization of URL or CMS integration are no factor
• what about page flow vs components? In components frameworks, what it the relevance of templates?
• etc.

IMHO, forgetting the previous points, whether intentionally or not, has potential to lead to incorrect choices.

Cheers!

+1.

Some technologies are not human-friendly. It should be the goal of these technologies to get support from popular IDEs.

Another good example is Maven POM which can get pretty complex but is easily readable with m2eclipse Eclipse plugin or NetBeans.

+1.

Some technologies are not human-friendly. It should be the goal of these technologies to get support from popular IDEs.

Another good example is Maven POM which can get pretty complex but is easily readable with m2eclipse Eclipse plugin or NetBeans.

Seems PowerMock is also on the trend: it offers additional features and supports Mockito and EasyMock.

It works without agent but requires that you use its API that in turn calls the chosen framework.

Well, Spring, although it supports AspectJ, does not use it itself. AOP is a way of seeing the world that the above frameworks do not need (and thus do not use).

I must admit it's only supposition on my part so the debate could go forever but IMHO, I don't think it's a licensing problem.Thanks for your input though.

Well, Spring, although it supports AspectJ, does not use it itself. AOP is a way of seeing the world that the above frameworks do not need (and thus do not use).

I must admit it's only supposition on my part so the debate could go forever but IMHO, I don't think it's a licensing problem.Thanks for your input though.

Well, Spring, although it supports AspectJ, does not use it itself. AOP is a way of seeing the world that the above frameworks do not need (and thus do not use).

I must admit it's only supposition on my part so the debate could go forever but IMHO, I don't think it's a licensing problem.Thanks for your input though.

Well, Spring, although it supports AspectJ, does not use it itself. AOP is a way of seeing the world that the above frameworks do not need (and thus do not use).

I must admit it's only supposition on my part so the debate could go forever but IMHO, I don't think it's a licensing problem.Thanks for your input though.

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I do agree with you too: AOP (aspect oriented programming) gives a nice abstraction over plain proxy "plumbing". Yet, you can ask yourself why Hibernate, Spring, LambdaJ and all do not use this abstraction layer...

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I will look into it ASAP; if that's true, that's a very good comment!

After verification, kudo to tyou! Updated article to take this into account.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

I don't know nothing about Ebean and I won't argue about the product but the log produced (the theme of this article) is not copy/pastable into a SQL Query product (Toad or what have you):

trans[1004], 08:51:39.587, delete from e_basicver where id=? and last_update=?
trans[1004], 08:51:39.587, Binding Delete [e_basicver] where[id=1, lastUpdate=2010-03-01 08:51:39.515, ] 

P6Spy logging fits the previous requirement, EBean logging does not.

Moreover, you could get 100% coverage without true testing at all. Just write the tests and do not use assertions: work done. The same could be done with JavaDocs, and so on.

That's why you cant' rely on metrics alone.

Hi Andy,

Granted they are more. Yet, from my experience, I've only seen Hibernate (mostly) and TopLink (rarely). Sometimes, they are accessed through JPA...

It would be interesting to have statistics about each use but it isn't far fetched to approximate to these two major actors.

Thanks for your interest.

Hi Andy,

Granted they are more. Yet, from my experience, I've only seen Hibernate (mostly) and TopLink (rarely). Sometimes, they are accessed through JPA...

It would be interesting to have statistics about each use but it isn't far fetched to approximate to these two major actors.

Thanks for your interest.

He he, notice that in my previous comment, I didn't say anything about autowiring?

Older people (like me...) remember that autowring can be used with XML. Well, guess what, I think it's a big error too. And the error gets bigger with bigger projects: haven't experienced it yet like Jonathan and Peter but it smells wrong... It happens when you rely too much on magic behind the scene. Add one more class and kaboom goes your DI! Good luck to you if you are adding features on an already developed application.

I can't agree with you. Java and JEE, though flawed, have come to be one of the most successfull stack on the server-side. Before JPA, I used Hibernate. I still use it when JPA doesn't fit my needs. Yet, I try to always use standards, when they do not impair development time (like JDO and EJB 2 IMHO).

What if the Spring developers decided to remove @Autowired in the next version of Spring? I wouldn't be able to upgrade Spring's version. Experience have taught me that it never happened in the Java/JEE APIs and I try to build my applications to last. My current customer wants its applications to last 10 years at least: so standards never hurts (less the ones that do... see example above)

@Mitchell

This post and my comment triggered an heated argument among my co-workers and me. Good job and thank you... but I still disagree with the content :-P

Hi Mitchell,

I'm always happy to read your informative Daily Dose posts. That's why it sadens me to vigorously object to your article's conclusion.

Why do you use DI in the first place? If the answer is 'To decouple your code', then why use a proprietary Spring annotation that will bind you to Spring in the long run?

XML configuration may be (is) a bore, but with the right tool, namely Spring IDE, it is the best solution in terms of decoupling.

Using standard (javax.inject.*) is an option, @Autowired is not.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Like I said before, the benefit is instantly to know the test which failed and thus make the diagnostics easier.

If your tests are dependent on a context that is updated throughout the test run, I would advise you to still separate your big test method into many neat little method and make them dependent: TestNG has this feature (don't know about JUnit though). This clearly gets away from pure unit testing.

Hi Thomas,

I don't know about MagicTest but I fail to see why handling more than one exception per method is desirable. Since the subject is unit testing, I think separating the cases make for a better failed build diagnostics, so I would advise you to use JUnit/TestNG approach.

There are two answers: from a development point of view, this shouldn't be my problem and I have only to use the API. Now, from a production pov, it depends on many factors: what is stored, read frequency, write frequency, and so on... This shouldn't be a black or white answer.

For now, my requirements are simple: intranet, not many concurrent users (50 at most), non critical, and since I make the code reviews, I make sure there's not too much stored in session. So, simple Tomcat clustering would be enough. Terracotta free version would let me be server-agnostic. Too bad I have no admin role for my client...

There are two answers: from a development point of view, this shouldn't be my problem and I have only to use the API. Now, from a production pov, it depends on many factors: what is stored, read frequency, write frequency, and so on... This shouldn't be a black or white answer.

For now, my requirements are simple: intranet, not many concurrent users (50 at most), non critical, and since I make the code reviews, I make sure there's not too much stored in session. So, simple Tomcat clustering would be enough. Terracotta free version would let me be server-agnostic. Too bad I have no admin role for my client...

There are two answers: from a development point of view, this shouldn't be my problem and I have only to use the API. Now, from a production pov, it depends on many factors: what is stored, read frequency, write frequency, and so on... This shouldn't be a black or white answer.

For now, my requirements are simple: intranet, not many concurrent users (50 at most), non critical, and since I make the code reviews, I make sure there's not too much stored in session. So, simple Tomcat clustering would be enough. Terracotta free version would let me be server-agnostic. Too bad I have no admin role for my client...

Why? Because I didn't see anywhere what should be the behaviour of an application server which is tasked to fetched the resource referenced by multipart/context. Should it first checked for a webapp which context root is "multipart", then look for a servlet mapping of "context" or search first for a webapp which context root is "multipart/context"? Not specified anywhere I looked, hence not deterministic, thus a potential bug (or exploitation of one).

Ok, I agree that "deeply" is a figure of style...

Why? Because I didn't see anywhere what should be the behaviour of an application server which is tasked to fetched the resource referenced by multipart/context. Should it first checked for a webapp which context root is "multipart", then look for a servlet mapping of "context" or search first for a webapp which context root is "multipart/context"? Not specified anywhere I looked, hence not deterministic, thus a potential bug (or exploitation of one).

Ok, I agree that "deeply" is a figure of style...

Why? Because I didn't see anywhere what should be the behaviour of an application server which is tasked to fetched the resource referenced by multipart/context. Should it first checked for a webapp which context root is "multipart", then look for a servlet mapping of "context" or search first for a webapp which context root is "multipart/context"? Not specified anywhere I looked, hence not deterministic, thus a potential bug (or exploitation of one).

Ok, I agree that "deeply" is a figure of style...

Why? Because I didn't see anywhere what should be the behaviour of an application server which is tasked to fetched the resource referenced by multipart/context. Should it first checked for a webapp which context root is "multipart", then look for a servlet mapping of "context" or search first for a webapp which context root is "multipart/context"? Not specified anywhere I looked, hence not deterministic, thus a potential bug (or exploitation of one).

Ok, I agree that "deeply" is a figure of style...

Seems we had different experiences ;-) The term productivity just seems so strange for me in this context...

Seems we had different experiences ;-) The term productivity just seems so strange for me in this context...

Seems we had different experiences ;-) The term productivity just seems so strange for me in this context...

What I regard as fundamental is to know one's limitations regarding one's knowledge of a topic. That's why I try never to post an article nor a comment too hastily. I would be grateful if you did the same: please look at my second word of advice...

What I regard as fundamental is to know one's limitations regarding one's knowledge of a topic. That's why I try never to post an article nor a comment too hastily. I would be grateful if you did the same: please look at my second word of advice...

What I regard as fundamental is to know one's limitations regarding one's knowledge of a topic. That's why I try never to post an article nor a comment too hastily. I would be grateful if you did the same: please look at my second word of advice...

What I regard as fundamental is to know one's limitations regarding one's knowledge of a topic. That's why I try never to post an article nor a comment too hastily. I would be grateful if you did the same: please look at my second word of advice...

Agreed, the price is a real argument against it (though I'm not aware of such a high price). We are now used to free IDEs but I have known the time when you had to pay for these and it was about the same price.

Anyway, apart from purely technical criteria, you have to consider ROI. How much time will you need to do your charts in JavaFX? How much with FlexBuilder? How much are you paid? Then you'll see how much FlexBuilder is really worth in your case.

Hi Peter,

First, I'm not a Flex specialist. I'm just toying with the technology now so I speak under the control of real Flex programers:

• I can't enumerate the features you have to pay for because I have found only AdvandedDataGrid yet. All features I consider mandatory are free: communication through HTTP, conversion from the Java world to Flex and reversed, etc. Moreover, the paying features are included in FlexBuilder (250$) meaning buying FlexBuilder let you have the license to use these super components freely
• For Flex, you need XML and ActionScript which is a specialized JavaScript, that's all and that's what's great! You can spice it with CSS but that's not a requirement.

I feared nobody would be interetested in such a post, so I thank you first for your interest.

Yours is a very pertinent comment! I left the p namespace out because I'm one of the very first to tell it makes the beans definition file less readable and in what i coded, I have the same result... save the reference and the enumeration. But the point was to let people learn about Spring authoring, not really create a useful namespace.

I feared nobody would be interetested in such a post, so I thank you first for your interest.

Yours is a very pertinent comment! I left the p namespace out because I'm one of the very first to tell it makes the beans definition file less readable and in what i coded, I have the same result... save the reference and the enumeration. But the point was to let people learn about Spring authoring, not really create a useful namespace.

I feared nobody would be interetested in such a post, so I thank you first for your interest.

Yours is a very pertinent comment! I left the p namespace out because I'm one of the very first to tell it makes the beans definition file less readable and in what i coded, I have the same result... save the reference and the enumeration. But the point was to let people learn about Spring authoring, not really create a useful namespace.

@zqudlyba

However, I do think this project should be monitored closely since it could bring some productivity gains soon.

Excellent article considering I asked myself the question not so long ago whether it would be better not to use Transfer Object in small / independent applications.

Transfer Objects are inherited from EJB2 design patterns where you could not transfer entities from the back end to the front-end since you were tied to the EJB container. Nowadays, this behaviour is still used without any thoughts about it.

The only reason to keep this behaviour is to hide your business entitis from other applications. To hide BO from the front end if it's the same application is a waste of time IMHO (at development time and at runtime).

Some tenants of TO care to elaborate the need to use them?

For example, pieni, since you closed your JPA context when you went from the data access tier to the business tier, your BO are not tied to the DB anymore and you can do whatever you want with them: if you do not explicitly reattach them, there's not side effect on the DB.

Completely agree with you. I'm always scared to read articles that just want another language feature, and scoff at backward compatibility like it's an evil thing.

People, wake up! Customers don't care about closures or whatever but care they will have to redevelop their +200 applications in order to integrate a new version of the language. Are we really living in the same world?

Completely agree with you. I'm always scared to read articles that just want another language feature, and scoff at backward compatibility like it's an evil thing.

People, wake up! Customers don't care about closures or whatever but care they will have to redevelop their +200 applications in order to integrate a new version of the language. Are we really living in the same world?

Completely agree with you. I'm always scared to read articles that just want another language feature, and scoff at backward compatibility like it's an evil thing.

People, wake up! Customers don't care about closures or whatever but care they will have to redevelop their +200 applications in order to integrate a new version of the language. Are we really living in the same world?

Completely agree with you. I'm always scared to read articles that just want another language feature, and scoff at backward compatibility like it's an evil thing.

People, wake up! Customers don't care about closures or whatever but care they will have to redevelop their +200 applications in order to integrate a new version of the language. Are we really living in the same world?

Jacek,

Executing code client-side or server-side is a major architectural decision that you don't have the luxury to make! For most clients I have worked for, these choices were made before I came. It has nothing to do with this article whatsoever.

Besides, you'll get the same problem in developing from scratch for whatever framework you're using (Swing, .Net, what have you) if you don't have the component you want when needed, which is a common occurence. Making reusable components libraries for your organization is a big step in speeding up development.

I must concede though that JSF architecture favors ease of use over ease of development so new components are a bit complex to develop.

Jacek,

Executing code client-side or server-side is a major architectural decision that you don't have the luxury to make! For most clients I have worked for, these choices were made before I came. It has nothing to do with this article whatsoever.

Besides, you'll get the same problem in developing from scratch for whatever framework you're using (Swing, .Net, what have you) if you don't have the component you want when needed, which is a common occurence. Making reusable components libraries for your organization is a big step in speeding up development.

I must concede though that JSF architecture favors ease of use over ease of development so new components are a bit complex to develop.

Jacek,

Executing code client-side or server-side is a major architectural decision that you don't have the luxury to make! For most clients I have worked for, these choices were made before I came. It has nothing to do with this article whatsoever.

Besides, you'll get the same problem in developing from scratch for whatever framework you're using (Swing, .Net, what have you) if you don't have the component you want when needed, which is a common occurence. Making reusable components libraries for your organization is a big step in speeding up development.

I must concede though that JSF architecture favors ease of use over ease of development so new components are a bit complex to develop.

Thanks for your contribution, I will try to enlighten the points you raised the most / are the most pertinent regarding to what I wanted to tell:

• First thing first: that was not a personal project but my company's

• 1Gb sucks. Oh yes it does! But the point was to prototype an environment, not run on such a machine in a long run.
• JIRA is not free, so we won't use it. Alas, I must say that the cost was a factor. I had no budget: no penny, no pound, no nothing. Only sweat and toil ;-). Products could be closed source but free (Oracle Lite would have fit... if not for PHP).
• I looked at RedMine briefly, liked what I saw but had not time to test. I will put it under my 'To evaluate' bookmarks.
• Virtualization is a very good idea and thought about it. Unfortunately, my conclusion was that was not compatible with my crappy configuration.
• As for online SCM, it could be compatible with a personal or OpenSource development but not for a private or closed one. For me, it's a no go there. Just like putting companies' private data in the cloud. Feels like the beginning of a flame war, doesn't it?

If I remember well what I was taught a looong time ago, OOP is about 3 things: encapsulation, inheritance and polymorphism.

What I understand from this article is that the first one is about to get shot. A more OOP-friendly approach would be the under-the-hood creation of defaults getters/setters if none existed, just like the creation of a default constructor is handled by the compiler. With annotations to configure in case one property shouldn't be accessed.

But I'm perhaps too old to consider new approaches...

If I remember well what I was taught a looong time ago, OOP is about 3 things: encapsulation, inheritance and polymorphism.

What I understand from this article is that the first one is about to get shot. A more OOP-friendly approach would be the under-the-hood creation of defaults getters/setters if none existed, just like the creation of a default constructor is handled by the compiler. With annotations to configure in case one property shouldn't be accessed.

But I'm perhaps too old to consider new approaches...

Hello,

Don't get me wrong, but displaying tabular data in HTML is done since a loooooong time with the DisplayTaglib. There's a short article on my blog if you're interested. They use taglibs but I see it as an advantage.

For more informations, see their site or their live demos which are really bluffing when you see the tiny amount of config needed on the JSP.

Cheers.

Nicolas

Hello,

Don't get me wrong, but displaying tabular data in HTML is done since a loooooong time with the DisplayTaglib. There's a short article on my blog if you're interested. They use taglibs but I see it as an advantage.

For more informations, see their site or their live demos which are really bluffing when you see the tiny amount of config needed on the JSP.

Cheers.

Nicolas