Donnerstag, 31. Juli 2014
Mittwoch, 30. Juli 2014
Dienstag, 29. Juli 2014
Sonntag, 27. Juli 2014
Samstag, 26. Juli 2014
Freitag, 25. Juli 2014
Mittwoch, 23. Juli 2014
Dienstag, 22. Juli 2014
Montag, 21. Juli 2014
Why Spring makes me sick #15
From the Spring Framework Reference Documentation:
"There are a few restrictions due to the fact that CGLIB dynamically adds features at startup-time:
"There are a few restrictions due to the fact that CGLIB dynamically adds features at startup-time:
- Configuration classes should not be final
- They should have a constructor with no arguments"
But in fact they are not - I had to write tests to check it.
A documentation, which is not specific can be quite useless...
A documentation, which is not specific can be quite useless...
Why Spring makes me sick #14
While investigating Spring I have written numerous test with seemingly independent configurations. But a couple of times adding new tests unexpectedly broke tests e.g. because I added a second bean of a certain type, but in an older test Spring expected only one bean of that type.
Is that my fault? Strictly speaking: Yes, because I must e.g. not autowire a single bean, when more are defined.
BUT if I run into this problem, namely breaking the application by adding another bean, for my tests, which are not that much code and only I work on, imagine how many problems this can create, when multiple developers work on a large code base.
What really makes this bad is, that due to the 'dynamic' way spring is configured, such problems may not occur in the test suite, but only in production code. And since Spring errors only turn up at run time, combined with lazy initialization this is a time bomb.
Oh, and good luck finding and solving such a problem in a complex Spring configuration.
Is that my fault? Strictly speaking: Yes, because I must e.g. not autowire a single bean, when more are defined.
BUT if I run into this problem, namely breaking the application by adding another bean, for my tests, which are not that much code and only I work on, imagine how many problems this can create, when multiple developers work on a large code base.
What really makes this bad is, that due to the 'dynamic' way spring is configured, such problems may not occur in the test suite, but only in production code. And since Spring errors only turn up at run time, combined with lazy initialization this is a time bomb.
Oh, and good luck finding and solving such a problem in a complex Spring configuration.
Sonntag, 20. Juli 2014
Samstag, 19. Juli 2014
Freitag, 18. Juli 2014
Why Spring makes me sick #13
Spring is often counter intuitive. Of course, if you know your Spring, you should know how it behaves, but I doubt that anyone knows the entire API by heart, and somebody, who is not a Spring-trained will have a hard time with constructs like this:
@Configuration
public class SpringConfig
{
@Bean
public BeanA beanA()
{
return new BeanA();
}
}
Any Java developer should expect method beanA() to return a new instance on every call.
But in Spring things are different: The @Bean makes the method a bean definition and since Spring beans are singletons by default, you will get the same instance on every call.
@Configuration
public class SpringConfig
{
@Bean
public BeanA beanA()
{
return new BeanA();
}
}
Any Java developer should expect method beanA() to return a new instance on every call.
But in Spring things are different: The @Bean makes the method a bean definition and since Spring beans are singletons by default, you will get the same instance on every call.
Donnerstag, 17. Juli 2014
Why Spring makes me sick #12
This one is obvious but still very annoying: I just changed the package structure of my Spring test classes and while Eclipse did most things on the Java level for me automatically, I had to change the Spring XML configs manually, which was not a fun task.
And of course I had to run the tests, to see the actual problems, while on the other hand every Java problem was shown by Eclipse immediately when I changed things.
And of course I had to run the tests, to see the actual problems, while on the other hand every Java problem was shown by Eclipse immediately when I changed things.
Why Spring makes me sick #11
From the Spring Framework Reference Documentation: "the Spring IoC container allows a
Sounds harmless, but is the worst I've found so far: Using
The concrete
BeanFactoryPostProcessor to read the
configuration metadata and potentially change it before the container instantiates
any beans other than BeanFactoryPostProcessors." Sounds harmless, but is the worst I've found so far: Using
BeanFactoryPostProcessor one can change any property of any bean.The concrete
BeanFactoryPostProcessor implementation does not have to refer to the beans it modifies and can be added to the config with a single XML element, that does not refer to BeanFactoryPostProcessor. In other words, one can really fuck up any application with under 10 lines of Java & XML, in a way that is very hard to detect.Why Spring makes me sick #10
Spring uses BeanPostProcessors to make it possible, to modify objects when they are created and initialized.
So far so bad (bad because the unsuspecting developer may never find out what messed with his class, because the the actual BeanPostProcessor instances don't even need to have a reference to the types they are modifying).
But what is really, really bad, is that the BeanPostProcessors (may) even return different objects i.e. you configure one type of bean class and actually get a different class at run time. And all automagically in the background with no way to trace it.
So far so bad (bad because the unsuspecting developer may never find out what messed with his class, because the the actual BeanPostProcessor instances don't even need to have a reference to the types they are modifying).
But what is really, really bad, is that the BeanPostProcessors (may) even return different objects i.e. you configure one type of bean class and actually get a different class at run time. And all automagically in the background with no way to trace it.
Mittwoch, 16. Juli 2014
Why Spring makes me sick #9
From the Spring Framework Reference Documentation: "For example, the following definition:
What this does is call init() when the class is created. Since this is in the Spring configuration, init() is only called when the class is created via the Spring framework. Hence the class is coupled to Spring and will not work without it.
The coupling may no be visible in the Java code, but it is still there. And moving things from Java to XML does the opposite of improving tings...
< bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>... does not couple the code to Spring."
What this does is call init() when the class is created. Since this is in the Spring configuration, init() is only called when the class is created via the Spring framework. Hence the class is coupled to Spring and will not work without it.
The coupling may no be visible in the Java code, but it is still there. And moving things from Java to XML does the opposite of improving tings...
Why Spring makes me sick #8
From the Spring Framework Reference Documentation: "This approach is
powerful and flexible in that you can choose the scope of the objects you create
through configuration instead of having to bake in the scope of an object at the Java
class level."
This essentially means, that you can not rely on the scope of an object, because the scope can be changed via configuration.
Further more: Change the scope in the config and likely break the application.
Scope errors are often only discovered after a relatively long time and are hard to find.
This essentially means, that you can not rely on the scope of an object, because the scope can be changed via configuration.
Further more: Change the scope in the config and likely break the application.
Scope errors are often only discovered after a relatively long time and are hard to find.
Why Spring makes me sick #7
From the Spring Framework Reference Documentation: "A less useful form of method injection than lookup method Injection is the ability to
replace arbitrary methods in a managed bean with another method implementation. Users
may safely skip the rest of this section until the functionality is actually needed."
This is essentially as bad as Why Spring makes me sick #6, but I think that this description means, that even the Spring guys think, that it is bad.
This is essentially as bad as Why Spring makes me sick #6, but I think that this description means, that even the Spring guys think, that it is bad.
Why Spring makes me sick #6
From the Spring Framework Reference Documentation: "Lookup method injection is the ability of the container to override methods on
container managed beans, to return the lookup result for another named bean in the
container."
I essence this means, that spring will either a) replace a method or b) implement an abstract method. At run time. With a dynamically generated class.
For the developer this means that either a) a method, he sees in the source code, is not what is actually executed at run time or b) the abstract method, he sees in the source code, and for which he can find no implementation, is still somehow executed at run time. Further more the class, he sees in the source code, is not the class that will eventually be executed. And of course, if the method was abstract, then the class was abstract too and there will probably be no implementation of this abstract class.
Nightmare is the first association that pops up in my mind. How is anyone supposed to debug such a mess?
The horror.
Luckily, this mechanism is used in the project I'm currently working on...
I essence this means, that spring will either a) replace a method or b) implement an abstract method. At run time. With a dynamically generated class.
For the developer this means that either a) a method, he sees in the source code, is not what is actually executed at run time or b) the abstract method, he sees in the source code, and for which he can find no implementation, is still somehow executed at run time. Further more the class, he sees in the source code, is not the class that will eventually be executed. And of course, if the method was abstract, then the class was abstract too and there will probably be no implementation of this abstract class.
Nightmare is the first association that pops up in my mind. How is anyone supposed to debug such a mess?
The horror.
Luckily, this mechanism is used in the project I'm currently working on...
Dienstag, 15. Juli 2014
Why Spring makes me sick #5
From the Spring Framework Reference Documentation: "You use
So why is it then, that all examples use
It is simply impossible to inject Spring beans without depending on Spring APIs.
getBean() to retrieve instances of your beans. ... Indeed, your application code should have no calls to the
getBean() method at all, and thus no dependency on Spring APIs at all."So why is it then, that all examples use
getBean()?It is simply impossible to inject Spring beans without depending on Spring APIs.
Why Spring makes me sick #4
From the Spring Framework Reference Documentation: "Spring sets properties and resolves dependencies as late as possible, when
the bean is actually created. This means that a Spring container which has loaded
correctly can later generate an exception when you request an object..."
That is exactly what I do not want.
Spring configuration via XMLs breaks type safety i.e. there is no way to see type errors at compile time (though that is not the only kind of error a Spring configuration can contain).
Further more not adhering to the fail-fast-paradigm will, according to Murphy, make applications fail in the worst possible moment. This is really dangerous...
That is exactly what I do not want.
Spring configuration via XMLs breaks type safety i.e. there is no way to see type errors at compile time (though that is not the only kind of error a Spring configuration can contain).
Further more not adhering to the fail-fast-paradigm will, according to Murphy, make applications fail in the worst possible moment. This is really dangerous...
Why Spring makes me sick #3
From the Spring Framework Reference Documentation: "Code is cleaner with the DI principle and decoupling is more effective when objects are
provided with their dependencies. The object does not look up its dependencies, and does
not know the location or class of the dependencies."
This is so wrong. While code may be cleaner with DI it is also harder to understand (instances appear magically at run time) and much harder to debug (one can't easily trace objects back to their creation). Further more each object has to know its dependencies - otherwise they would not compile.
And the half-sentence about decoupling seems only to be there to increase the buzzword score, as it makes no sense at all (objects do always have to be provided with their dependencies and that does not change coupling in any way).
This is so wrong. While code may be cleaner with DI it is also harder to understand (instances appear magically at run time) and much harder to debug (one can't easily trace objects back to their creation). Further more each object has to know its dependencies - otherwise they would not compile.
And the half-sentence about decoupling seems only to be there to increase the buzzword score, as it makes no sense at all (objects do always have to be provided with their dependencies and that does not change coupling in any way).
Why Spring makes me sick #2
From the Spring Framework Reference Documentation: "Most Spring users prefer actual JavaBeans with
only a default (no-argument) constructor and appropriate setters and getters modeled
after the properties in the container. You can also have more exotic non-bean-style
classes in your container."
No one writes classes that have only default constructors - on the contrary, there are many reasons to write classes, that do not have a default constructor. And those are very common and thus far from exotic.
Update 16:25:
I just found that further down in the reference docs they write "The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not
Yes, that's the way it is supposed to be (have been reading Joshua Bloch, haven't we?), but it totally contradicts the original statements...
No one writes classes that have only default constructors - on the contrary, there are many reasons to write classes, that do not have a default constructor. And those are very common and thus far from exotic.
Update 16:25:
I just found that further down in the reference docs they write "The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not
null. Furthermore constructor-injected components are always returned to client
(calling) code in a fully initialized state."Yes, that's the way it is supposed to be (have been reading Joshua Bloch, haven't we?), but it totally contradicts the original statements...
Why Spring makes me sick #1
From the Spring Framework Reference Documentation: "IoC
is also known as dependency injection (DI)"
WTF? IoC does not equal DI.
WTF? IoC does not equal DI.
Why Spring makes me sick #0
From the Spring Framework Reference Documentation: "The Spring Framework is a lightweight solution..."
In release 4.0 there are about 3000 classes, the distribution contains 64 JAR files, the documentation (Reference & API) is about 126MB large. Not exactly lightweight, if you ask me...
In release 4.0 there are about 3000 classes, the distribution contains 64 JAR files, the documentation (Reference & API) is about 126MB large. Not exactly lightweight, if you ask me...
Montag, 14. Juli 2014
Sonntag, 13. Juli 2014
Freitag, 11. Juli 2014
Mittwoch, 9. Juli 2014
Samstag, 5. Juli 2014
Donnerstag, 3. Juli 2014
Mittwoch, 2. Juli 2014
Dienstag, 1. Juli 2014
Abonnieren
Posts (Atom)