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?

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.

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.

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(...) {

...

}

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.

Hi Seb,

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

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.

@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.

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.

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.

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...

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...

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 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.

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.

@zqudlyba

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

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.

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