Live data from Hacker News

Everything that's wrong with Java in a single class

plus.google.com

141–150 of 159 posts

Re: Everything that's wrong with Java in a single class

#141
post #22

I hate this kind of post. It's the tech equivalent of "You're a stupidhead". If you want to criticize Java then at least make some meaningful points. Just off the top of my head: - Java logging is a clusterfuck - Something as simple as wanting symbolic links in a Maven build requires a third party plugin, last updated in 2007 (maven-junction-plugin) that requires something no longer in the central repo; - No lambdas…

The class combines no less than 6 concepts / design patterns: - Abstract - Singleton - Proxy - Factory - Bean - Interceptors It's not just a long name. The class makes sense in the context of this framework. The core problem (as others here point out) is that the Java flavor of OOP makes writing this sort of code idiomatic. On the upside, you feel really smart once you grok all these concepts simultaneously. After a…

This is a great comment. This is what a Java "Engineer" or "Architect" is supposed to understand. It is complex, but seems too abstracted from programming reality that it makes programming simple things more complicated then they have to be.

Re: Everything that's wrong with Java in a single class

#142
post #141

Earlier quoted context omitted.

The class combines no less than 6 concepts / design patterns: - Abstract - Singleton - Proxy - Factory - Bean - Interceptors It's not just a long name. The class makes sense in the context of this framework. The core problem (as others here point out) is that the Java flavor of OOP makes writing this sort of code idiomatic. On the upside, you feel really smart once you grok all these concepts simultaneously. After a…

This is a great comment. This is what a Java "Engineer" or "Architect" is supposed to understand. It is complex, but seems too abstracted from programming reality that it makes programming simple things more complicated then they have to be.

All of these things are useful and valid techniques for building scalable, maintainable and extensible code.

Abstract is a pretty basic OO concept. You make an abstract class when you want it to be derived and never used directly.

Singleton is where a class can only ever create one object. Harder than it sounds.

Proxy is where the class interfaces with something else. Again, very useful. Proxies are used by Spring to implement AOP.

Factory - abstracts away the creation of objects, in other words the client object does not need to know how to create objects. It's used extensively in the Spring IoC container.

Beans are object that use simple but powerful conventions of creating reusable components in Java.

Interceptors at used by AOP.

If you use these concepts as they are intended to be used then your code will be cleaner, maintainable and a joy to work with.

Re: Everything that's wrong with Java in a single class

#143

Earlier quoted context omitted.

My favorite part is that the first word is "convenient." At the point that you need this class, absolutely nothing about the situation could possibly be considered "convenient."

I read that as sarcasm by the author. I refuse to believe anyone would word it like this without sarcasm.

...or it could be a common malady amongst programmer: inability to write clear documentation. I note that it's much clearer in the most recent documentation.

Re: Everything that's wrong with Java in a single class

#144

Earlier quoted context omitted.

Oh totally. I'm enjoying believing that this commit was part of a patch submitted with the explanation: "Added a new superclass because you wouldn't believe how hard it was to to create beans that create beans that create only singletons!" Turtles all the way down.

Yeah, that would be amusing if it was accurate. Only that's not what it does. It is actually a way of extending the bean creation part of the framework that produces singleton scoped proxy objects. I'm curious: what would you name that class?

I can assure you I wouldn't name that class.

But honestly, I'm kidding around. I'm not arguing the class is silly, or poorly named. I bet it's perfectly named. I'm not arguing the author did a bad thing here, I'm sure he or she did something awesome. All I'm saying is that the context that makes writing that class description necessary is totally hilarious.

Let's just agree on that. It doesn't mean Java sucks or Spring sucks. Big complicated projects sometimes lead to pretty wacky situations and we ought to be able to laugh at them. I'm certainly not suggesting other languages don't have the same culdesacs of lunacy.. they totally all do. Can you imagine the number of times someone's posted "Everything that's wrong with Perl in one line of code" ?

I really don't see any reason to take this stuff so seriously.

Re: Everything that's wrong with Java in a single class

#145

Earlier quoted context omitted.

You won't find anywhere near this level of abstraction in the standard library, at least not that I am aware. The Java culture is understandably implicated by this though, because Spring is not some niche framework being perpetrated in some fringe corner of the Java-verse. It is very much the mainstream of Enterprise Java. Of course there are lots of Java developers outside of that set who are doing great work. And a…

Last I checked, the standard library wasn't trying to implement an IoC container. Your comment is actually fairly amusing, given that Spring was developed originally as an answer to the overly abstract mess that was the original version of Enterprise JavaBeans. Interestingly, things like @Inject came after Spring, and were inspired by Spring and a number of other containers.

I was just referring to the standard library in J2SE. Of course it isn't trying to do an IoC container - but there was a comment above about whether or not this is a "Java" issue and it really is not. My last contact with this was before EJB 3 so I wouldn't even try to speak to how Spring and J2EE have evolved to help manage complexity.

Re: Everything that's wrong with Java in a single class

#146

Earlier quoted context omitted.

A bit of column A and a bit of column B. People who write Java are exposed to rampant overuse of design patterns when looking at examples of a) what the community considers Good Java and b) all over their internal projects. This is partially because Java lives, by design, in a Kingdom of Nouns and partially because there's just no good way in the standard language / library / toolchain to do some things without going…

I don't want to play code golf with you, because I think your point is generally valid, but you can happily and idiomatically reduce the Java method itself to 10 lines with some sympathetic scaffolding from the other classes (this is actually how a lot of code in our game is implemented rather than some theoretical optimum): public class Student implements Comparable { @NotNull public List getTests() { ... } @NotNull…

that, or even 10 lines, is still several orders of magnitude more code than how you do it in a dynamic language like ruby or python

Re: Everything that's wrong with Java in a single class

#147
post #146

Earlier quoted context omitted.

I don't want to play code golf with you, because I think your point is generally valid, but you can happily and idiomatically reduce the Java method itself to 10 lines with some sympathetic scaffolding from the other classes (this is actually how a lot of code in our game is implemented rather than some theoretical optimum): public class Student implements Comparable { @NotNull public List getTests() { ... } @NotNull…

that, or even 10 lines, is still several orders of magnitude more code than how you do it in a dynamic language like ruby or python

It's not really dynamism so much as a functional outlook. Here it is in Scala (probably with a healthy number of syntax errors, and certainly with a whiff of inexperience):

  def studentsWhoHaveNotTakenAtLeastOneTest = getStudents.filter{s => s.getTests.filter{t => !t.isTaken}.size > 0}.sorted
You could get a similar amount of code in Java using something like FunctionalJava but that's not really a fair comparison, because patio11 is illustrating Java as it's spotted in the wild, and thus so am I. But with appropriate libraries and implementation patterns you can certainly write concise Java if you so choose.

Re: Everything that's wrong with Java in a single class

#148

Earlier quoted context omitted.

More likely just one implementation of IProblemFactory.

If I wrote that it would have been downvoted to - points range by now.

I'm a swell guy, that's why I don't get as much hate (?)

Re: Everything that's wrong with Java in a single class

#149

Earlier quoted context omitted.

Yeah, that would be amusing if it was accurate. Only that's not what it does. It is actually a way of extending the bean creation part of the framework that produces singleton scoped proxy objects. I'm curious: what would you name that class?

I can assure you I wouldn't name that class. But honestly, I'm kidding around. I'm not arguing the class is silly, or poorly named. I bet it's perfectly named. I'm not arguing the author did a bad thing here, I'm sure he or she did something awesome. All I'm saying is that the context that makes writing that class description necessary is totally hilarious. Let's just agree on that. It doesn't mean Java sucks or Spri…

The context makes it entirely appropriate. A FactoryBean allows you to construct complex objects, or construct objects Spring can't easily create itself (e.g. JndiFactoryBean). A ProxyFactoryBean builds Spring AOP proxy beans.

As it turns out, there was no need for the class as it has been deprecated. However, providing an abstract singleton scoped proxy factory bean is indeed convenient. If there was a need for a factory that creates AOP proxies then it would be very useful to have an abstract class that implements most of the methods for you, and create them with singleton scope. In that case, AbstractSingletonProxyFactoryBean is sensible.

It's a corner case. It was used by one class, but that was deprecated later, so this was deprecated as there wasn't really a need for the convenience class.

I take this lot of stuff seriously because I see a lot of ignorant pattern bashing by those who haven't taken the time to understand why patterns are very useful and potentially can make OOP code cleaner and easier to maintain.

Re: Everything that's wrong with Java in a single class

#150
post #117

A few days ago there was a discussion about spaghetti code, and in the comments other flavors of pasta were discussed. One of them was ravioli. This is a prime example of what "ravioli code" looks like. It's probably as easy to read goto spaghetti as it is to try to decipher whatever this class does.

What's so hard to understand? It's a convenient superclass for FactoryBean types that produce singleton-scoped proxy objects. If you understand the basics of Spring and how Spring does AOP, then this isn't difficult to understand at all.
Post reply on HN