8 ms·

On a related note, I saw this on reddit this morning: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html

On a related note, I saw this on reddit this morning: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory.html?rel=html http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server... What's sad is that I have no idea if this is a joke or not.

jimbokun 18y ago
Perfect thing to show people, when they want to know if Java is a good fit for their problem. Even a Pointy Haired Boss, shown this, might understand why Rails or Django or something might be a better way to go than dealing with this. EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this isn't the fault of Java the Language, but the "enterprise architecture" community that write Java frameworks like this.
- dgabriel 18y ago
  Java is not the problem, the architecture is the problem. If you try hard enough, you can make something unwieldy and atrocious in ANY language. That's why enterprise architects get the big bucks.
  - chaostheory 18y ago
    That may be true, but it's a hell of a lot easier to make fugly spaghetti in something statically typed like Java (or C#, C++, and so on). After 8 years of Java, I personally found it really refreshing to build stuff in Python and Ruby.
    - dgabriel 18y ago
      I don't know. After seeing some pretty unbelievable crap in VB, php, and javascript, I bet it's more a matter of numbers. The kinds of people who program in Python or Ruby aren't off the assembly line because the industry demand isn't as high. If one of those languages manages to become as widely used as Java, plan on seeing fugly spaghetti.
  - azanar 18y ago
    And if you try even harder, you can make something that is compact, but elegant and functional. It is still architecture, but it is good architecture. It's not the architecture that is the problem, it is the architect. Or specifically the motivations provided to the architect based on the compensation they are given. Unwieldy and atrocious looks like it took longer to the untrained eye, even if it probably didn't, so they face less grilling about the claimed effort involved. Simple to use is, in my experience, rarely simple to build. But it is simple to understand, and there is a unreasonable cognitive bias that simple to understand means simple to conceive. If that point can become more a part of everyone's collective wisdom, I suspect we would cure at least part of the motivation for creating these unwieldy systems.
  - Andys 18y ago
    The thing is, if you're writing a Ruby framework and there's a tiny chance someone will want to extend some part of it, they can do it without you needing layers of ClassFactoryFactory crud.
- axod 18y ago
  That's a ridiculous statement. Idiocy can be written in any language, including Java.
st3fan 18y ago
The Apache XML-RPC framework is a complete joke. It is completely over-engineered with crazy patterns and stupid extensibility hooks that nobody is waiting for. When Polar Rose still used XML-RPC we rolled our own framework that integrates well with Spring. You basically expose your POJO and be done with it ... http://code.google.com/p/polarrose-spring-xmlrpc http://code.google.com/p/polarrose-spring-xmlrpc
khill 18y ago
It's funnier with the Xzibit reference.
EliAndrewC 18y ago
On a similar note, the code parse an XML document in Java: Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml"); That's not even a framework; it's just what's in the standard library for parsing XML.
- ynd 18y ago
  I bet they were looking for extensibility. I wonder if they ever thought of providing two interfaces. 1. The first is the common case. Document doc = new DocumentBuilder().parse("test.xml"); 2. The second is more cumbersome but provides options. Document doc = DocumentBuilderFactory.newInstance(opts).newDocumentBuilder(opts2).parse("test.xml");
  - ntoshev 18y ago
    This is the facade pattern :) If you need it, this means you are overengineering. Applying it is even more overengineering.
  - EliAndrewC 18y ago
    I think the common case could be even simpler Document doc = DocumentBuilder.parse("test.xml"); no need to manually create an instance of the builder.
- michaelneale 18y ago
  You can lay for that in the gang of four book which recommended things like "abstract factory" - the odd thing was, I thought most of those authors were ex smalltalkers?

jimbokun 18y ago

Perfect thing to show people, when they want to know if Java is a good fit for their problem. Even a Pointy Haired Boss, shown this, might understand why Rails or Django or something might be a better way to go than dealing with this. EDIT: OK, so instead of Java, that should read "to know if enterprisey Java frameworks are a good fit for their problem." The irony is, that I just was IM'ing a friend about how this isn't the fault of Java the Language, but the "enterprise architecture" community that write Java frameworks like this.

dgabriel 18y ago
Java is not the problem, the architecture is the problem. If you try hard enough, you can make something unwieldy and atrocious in ANY language. That's why enterprise architects get the big bucks.
- chaostheory 18y ago
  That may be true, but it's a hell of a lot easier to make fugly spaghetti in something statically typed like Java (or C#, C++, and so on). After 8 years of Java, I personally found it really refreshing to build stuff in Python and Ruby.
  - dgabriel 18y ago
    I don't know. After seeing some pretty unbelievable crap in VB, php, and javascript, I bet it's more a matter of numbers. The kinds of people who program in Python or Ruby aren't off the assembly line because the industry demand isn't as high. If one of those languages manages to become as widely used as Java, plan on seeing fugly spaghetti.
- azanar 18y ago
  And if you try even harder, you can make something that is compact, but elegant and functional. It is still architecture, but it is good architecture. It's not the architecture that is the problem, it is the architect. Or specifically the motivations provided to the architect based on the compensation they are given. Unwieldy and atrocious looks like it took longer to the untrained eye, even if it probably didn't, so they face less grilling about the claimed effort involved. Simple to use is, in my experience, rarely simple to build. But it is simple to understand, and there is a unreasonable cognitive bias that simple to understand means simple to conceive. If that point can become more a part of everyone's collective wisdom, I suspect we would cure at least part of the motivation for creating these unwieldy systems.
- Andys 18y ago
  The thing is, if you're writing a Ruby framework and there's a tiny chance someone will want to extend some part of it, they can do it without you needing layers of ClassFactoryFactory crud.
axod 18y ago
That's a ridiculous statement. Idiocy can be written in any language, including Java.

st3fan 18y ago

The Apache XML-RPC framework is a complete joke. It is completely over-engineered with crazy patterns and stupid extensibility hooks that nobody is waiting for. When Polar Rose still used XML-RPC we rolled our own framework that integrates well with Spring. You basically expose your POJO and be done with it ... http://code.google.com/p/polarrose-spring-xmlrpc http://code.google.com/p/polarrose-spring-xmlrpc

khill 18y ago

It's funnier with the Xzibit reference.

EliAndrewC 18y ago

On a similar note, the code parse an XML document in Java: Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse("test.xml"); That's not even a framework; it's just what's in the standard library for parsing XML.

ynd 18y ago
I bet they were looking for extensibility. I wonder if they ever thought of providing two interfaces. 1. The first is the common case. Document doc = new DocumentBuilder().parse("test.xml"); 2. The second is more cumbersome but provides options. Document doc = DocumentBuilderFactory.newInstance(opts).newDocumentBuilder(opts2).parse("test.xml");
- ntoshev 18y ago
  This is the facade pattern :) If you need it, this means you are overengineering. Applying it is even more overengineering.
- EliAndrewC 18y ago
  I think the common case could be even simpler Document doc = DocumentBuilder.parse("test.xml"); no need to manually create an instance of the builder.
michaelneale 18y ago
You can lay for that in the gang of four book which recommended things like "abstract factory" - the odd thing was, I thought most of those authors were ex smalltalkers?