Archive Page 2
The site was down on Sunday and Monday, sorry for that. Thanks for coming back.
Difference between Spring and .NET as a plattform?
0 Comments Published September 20th, 2008 in JavaNot much. Both are written only by one company which makes the source available. Really. But you have to pay for Spring.
JsonBuilder for Scala, REST and Jersey
5 Comments Published September 18th, 2008 in JSON, Java, Jersey, REST, ScalaHow to generate Json for REST? If you’re suspicious of automatic generation like me?* I’ve created a markup builder which can be used with Json and made a look into the future in my post “The best Markup Builder I could build in Java”:
“Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like.”
* For a discussion on why you might not want to use JAXB and XStream see the comments on “REST: Lean JSON and XML from the same code”
Let’s have a look at this quote again. I didn’t use Groovy but with some interest in Scala - because it might be more maintainable than Java after 5-years project life time as it is more concise but not riddled with the Ruby-problems or unreadable for most as Haskell is - I looked at my JsonBuilder code and tried it with Scala.
I went back to the “Experiments to nicely generation JSON” post and did adapt it to Scala.
@Path("/hello")
class HelloWorldResource {
@GET
@ProduceMime(Array("text/html"))
def hello() = "Hello"
@Path("/world")
@GET
@ProduceMime(Array("text/html"))
def helloWorld = $(
$("id", 128),
$("name", "stephan"),
$("roles", roles.map(r => $("name", r.name))),
$("adress", $(
$("street", "mine!"),
$("city", "Berlin")
))
)
}
The generating code looks the same as in Java, with the possibility to include functions for generating nodes. My Java code did need anonymous inner classes to achieve the same - with more noise and less power. The methods are shorter and the focus lies more on generating the JSON data, not the method boilerplate code. Next will be WebBeans or Guice integration.
Ive struggled with some Scala constructs, the JsonAdapter which implements MessageBodyWriter was a little hard to write, especially:
def writeTo(node:Node, aClass:java.lang.Class[_],
typ:Type,
annotations:Array[Annotation],
mediaType:MediaType,
stringObjectMultivaluedMap:MultivaluedMap[String,Object],
outputStream:OutputStream):Unit = {
val writer = new OutputStreamWriter(outputStream);
writeTo(node, writer)
writer.close()
}
[...]
def isWriteable(dataType:java.lang.Class[_], typ:Type, annotations:Array[Annotation]) = {
classOf[json.Node].isAssignableFrom(dataType);
}
But everything works now and I can move on to adapt and learn how to do it better in Scala.
The migration wasn’t that hard, some problems exists and my Scala code looks more like Java than Scala, but it’s a beginning. One of my fears is to translate between Seqs, Lists, Arrays and Java Lists and Iterators all the time when interfacing with Java libraries. Not sure yet how to fix that, perhaps with some wrappers. Scalaz might help too. We’ll see in my future adventures into Scala.
Thanks for listening.
Compared to my IntelliJ IDEA experience, Netbeans works much better with Scala (but worse with Maven). Netbeans does recognize correct code compared to IDEA - but recognizes illegal code as legal too. For example it doesn’t tell you if you implement all methods from an abstract class. And lots of other things are missing from what we are used to in Java. My guess Scala IDEs are 5 years behind Java. Hope they catch up soon.
As a small side note, I’ve got
import javax.ws.rs.{Path, GET, ProduceMime}
@Path("/hello")
class HelloResource {
@GET
@ProduceMime(Array("text/html"))
def hello() = "Hello World"
}
working with Maven2, Jetty and Jersey. Took some time but was interesting. Any ideas for Array("text/html") (Scala does’t support varags the same as Java does) Perhaps a clever implicit? Need to think more.
I’ve played around with the latest Scala plugin for IntelliJ IDEA and I consider it alpha quality at best. It’s hard to get compilation going and it gets often confused with parsing (for very basic files, 10 lines of Scala with annotations for Jersey this time). It feels like Eclipse which will also present errors which are none (for Java!) and after inserting a blank line and saving again, the errors go away.
Scala is harder to parse (type inference, implicits, …) than Java, but this needs to get better to be usable. They hinted that it’s too far behind to get into 8.0, I hope not to far.
But kudos for supporting Groovy, JRuby and Scala and doing their best.
Update: I have the nagging thought in the back of my head and a eerie feeling in my stomach that IDEA can’t to better for Scala than for Groovy because of implicits etc. Hope I’m wrong :-)
Update 2: An update to the Scala plugin destroyed my IDE, it is no longer able to start. It says I should remove the plugin, but doesn’t tell me where it is.
Nach unserem letzten - langen - Ärger mit Lichtblick, der sich nur mit Drohung von rechtlichen Schritten lösen lies, nun erneut Ärger: Nach einem Umzug haben wir zwar eine Endstromstand bekommen mit einer Gutschrift, diesen Monat aber wurde 2x unter 2 Vertragsnummern der gleiche Monatsbetrag abgebucht. Wieder Ärger, wieder Telefonieren, wieder drohen mit Rechtsmitteln. Dabei will ich nur ganz normal Strom aus der Dose.
Functional design patterns and cargo cult blogging
25 Comments Published September 4th, 2008 in JavaAgain, I’ve found someone. I considered stopping last time. But this one is too good. I will only pick some parts of the post, there is not enough time to fight all stupidity there is in the world - I need to choose my battles. As the last two posts, I’ve again chosen someone who rants and has an aggressive and insulting tone without any knowledge of the matter the writes about.
Let’s start. Don’t get fooled by the beginning of his post:
“At the same time, I actually think I’m a fairly good programmer. I also think I have a fairly good understanding of what most of these buzzwords actually mean […]”
As well see shortly, contrary to his introduction he has absolutely no clue what he’s writing about. The first subject of his lengthy rant are design patterns:
“What is so wonderful about design patterns? Some of them are known to be goddamn awful constructs that will only pollute your codebase. What a design pattern really is, is a makeshift solution to a shortcoming in your language. A proper language would make every single design pattern redundant.”
He’s glorifying functional programming later. Do only I find it funny that people ranting against design pattern (the OO ones) don’t see that currying and monads are FP design patterns? Design patterns are best practices for designing software solutions and have nothing to do with OO.
Design patterns in OO languages and Java in particular, are not part of the language. They form a solution to common problems on top of the language. The state monad, the monte carlo monad, backtracking monads, maybe and either monads. All solve problems outside the functional domain of the language. (One could argue currying is not a design pattern but an implementation pattern. Go read the Beck book.)
Simple minded people everywhere. Who can’t see the wood for the trees. This seems prevalent in the functional community - at least the people who blog. If you want to read something about functional programming that is insightful read something from apocalisp. And use OCaml or Scala, or sneak good ideas into your Java code with functional Java.
“What is a design pattern? Code duplication? It’s a recipe for writing the same code over and over. And we all know that this is bad. You shouldn’t have duplicate code.”
The poster has no clue what a design pattern is. He quotes the Visitor pattern himself. The Visitor pattern is a clever way to use handlers with double dispatch and polymorphism. There is no duplication:
public void visit(Customer customer) {
// do something with customer
}
And though other languages don’t need the visitor pattern - Nice with multimethods for example - they essentially do the same thing:
handle(Customer customer)
{
// do something with customer
}
The solution is the same. Those languages have internalized the constructs and have syntactic sugar for less boilerplate. They don’t have new concepts. The concepts are the same.
This is how he describes a Factory
“An object that wraps a function that you can tailor to construct and return an object so you don’t have to construct it completely from scratch when you need it.”
Thats more of a Prototype or Singleton pattern. Factory is a different solution to a different problem.
This makes me sound like a design pattern evangelist. But though I’ve learned a lot about programming from design patterns, I rarely use them. Mostly not because they are bad, but there are myriads of other problems to solve - which can’t be solved by common Design Patterns (yet?).
That said, some should be used more often, NullObject especially. And some are bad - Singletons! No, Singletons are excellent as a pattern. Only the implentation in Java is not very useful with a static method. Inflexible and often hard to test. As most creational patterns, Singletons have been replaced with IoC/DI containers. Those offer more options, creating Singletons -as a concept - being one of them.
Reflection?
“And while it doesn’t have the same buzzword appeal, reflection as a language feature may be worth mentioning too. That too is just a workaround to compensate for missing language features. Great, so it lets you inspect a class to see what methods it has? That should never be necessary. If it has a method, I should be able to call it without going behind the code with introspection.”
Never used Reflection I suppose. Or any meta programming. Read The Art of the Metaobject Protocol. It’s about CLOS! Yes I know, Java has a very weak MOP and CGLIB only goes so far.
He goes on ranting about agile development.
“What does it mean? Anticipating that changes will happen? Testing every part of your code? Working as a team, with other programmers? Get the customer involved? Let them see regularly what you’re up to?”
Nope. It means “Individuals and interactions over processes and tools […]” which a little googling would have turned up. But of course ranting without any knowledge is easier. Knowledge hinders one ranting.
For some real insight into agile, read about Agile vs. Lean. Lots of people like agile because it helps with lean development.
The post is titled “Cargo-cult programming”, what he mainly attributes to Java developers. Cargo cult programming? His post is more like cargo cult ranting. Like lots of bloggers - see the two I’ve written about before - who only parrot what others say about design patterns, functional programming, Java or agile development. Count yourself one more cargo cult blogger.
I hope you’ve read the original post. It’s fun from a certain point of view as you see in this post.
Thanks for listening.
PS: When wanting to comment on his post, his blog told me “Sorry, but it seems you are a Spambot.” That says a lot about the blogger, keeping to oneself and not listening to others helps staying without knowledge and helps with more ranting. I hope none of my commentators see a spam bot message ;-)
Dear DZone and Reddit readers: Some test might result in a great difference between direct access and getters. Running a modified test with -server is 20 times faster for direct access compared to getters. If more stupid benchmarking is involved, this can increase. I suspect the server JVM is optimizing a lot. If you want to learn something, read the linked microbenchmark article :-) The difference between 300 and 20 is 15 times tough. A modified version which uses more than one test object seems to behave different (more than 2). See comments for a discussion on the causes - the JVM might completly inline an object if it detects only one read-access object inside a loop.
They sure seem to come in droves. After my last post, about a Ruby developer who is stupider than a piece of wood, there is another one! He laments how awful Java and OO developement is and how wonderful functional programming. Well functional development is nice, and I often use it with Java, but his post is rather funny because of the errors in it. The post is full of half-knowledge, things he quotes without any knowledge by himself. The blogosphere is full of those people.
I’m not refuting the article line by line, only the best parts:
“While we’re harping about performance, consider that setter and getter methods [in Java] take 300 times longer than direct access. Not percent. Times.”
I found this line hilarious.
public class Test {
public int value = 42;
public int getValue() {
return value;
}
public static void main(String[] args) {
Test test = new Test();
int dummy;
for (int i=0; i<1000000; i++) {
dummy = test.value;
dummy = test.getValue();
}
long tDirektStart = System.currentTimeMillis();
long sum = 0L;
for (int i=0; i<1000000000; i++) {
sum += test.value;
}
long tDirekt = System.currentTimeMillis() - tDirektStart;
sum= 0L;
long tGetterStart = System.currentTimeMillis();
for (int i=0; i<1000000000; i++) {
sum += test.getValue();
}
long tGetter = System.currentTimeMillis() - tGetterStart;
System.out.println("Direkt: " + tDirekt + " " + sum);
System.out.println("Getter: " + tGetter + " " + sum);
}
}
I know, micro benchmarking, I’m not sure what the JVM does in this case, inlining, loop unrolling, object removal, virtual methods and all - and it shouldn’t matter because the JVM optimizing getters is the whole point, but it should enable us to look at the 300 times slower claim:
Direkt: 3470 42000000000
Getter: 3454 42000000000
300 times faster? You bet.
Oh, only one more:
So here’s another problem, one that’ll knock that smug look off the Pythonistas faces. If you’ve ever done a serious project in an OO language then you’ll almost certainly have run into the fragile base class problem.
After more than 10 years of Java and lots of experience in C++, most people agree that inheritance should have been left out of every language - it might be good for frameworks but otherwise it does a lot of harm. The coupling is to big with inheritance. So for the last years people use more often composition not inheritance with Composite Oriented Programming being the extreme. Half knowledge and a blog - a dangerous combination. These “Get the facts” posts take to much time, I’ll need to think about another format for them - or perhaps don’t do any more of them.
The essence of it? Use the right tool, but don’t get fooled by people with outrageous claims - most of the time they are wrong.
Thanks for listening.
Funny, some Rubyists are stupider than a piece of wood
15 Comments Published August 28th, 2008 in Java, RubyThis one for example. He proposes a simple way to make Java developers angry, by showing them some code. His example is
File.open('server.cert').readlines[1..-2].join.gsub(/\n/, '')
and throws a challenge:
Anyhoo, all you have to do now is find someone who uses a big stupid language and throw an example like above to their face and tell them to beat it. See if they can write it more elegantly using their language. The beauty of the trick is that there’s no way in this world that’s gonna happen.
My 20min Java version looks like this - more or less identical:
File.open("server.cert").readlines(1, -2).join().gsub("\n", "")
Poor blogger, another fanboy without a clue who confuses languages and API design - in this case method chaining.
Because there’s a very high probability that the other person, yes, the one who’s using a big stupid language, will get so angry and beat you up.
Nope, I just write the code in Java. That’s all.
(Beside that, the oneliner is hard to read, hard to maintain, hard to reuse. Fine if your the sole developer in a project, bad if there are 50 others who need to maintain your code. I’d prefer a CertStripper ;-)
(As a second side node, where is the fluent interface to google collections, I’ve needed one today)
Update: Someone wrote a comment to the linked blog post by copying parts of this post. And because someone asked: No this cannot be done with the JDK, therefor it’s an API problem. You need to write some code on your own to fluently wrap JDK classes. See the mentioned fluent interface link above to see how this can be done to an existing API.