Before you ask, I don’t think anything’s wrong with object-oriented programming. But recently I’ve attended an interesting talk at the JAX conference. By the look of it, the speaker, Manuel Mauky, wasn’t happy with object-oriented programming. Instead, he propagated functional programming and Redux.
While I don’t agree with him, I considered his reasoning compelling. I’ll try to summarize it as best as I can.
By definition, object-oriented programming means to combine data with algorithms. To me, this always seemed to be natural. After all, data is meaningless until you know what to do with it. From this point of view, objects join two concepts that belong naturally together.
Manuel tackles things from a different angle. He doesn’t believe that data and behavior belong together. He’s pretty much convinced that the application state should be separate from the functions defining the behavior of the application. We’ll see that this approach has many advantages.
There are all these wonderful tools for profiling Java programs. JVisualVM, JProfiler, Mission Control and the Flight recorder, jhat, just to name a few. Yet every once in a while, you can’t use any of them, for one reason or another. Where do we go from here?
How come there’s no profiler?
The situation is not quite as exotic as you may think. When I was asked recently to write programs in the middleware layer, the lack of tools was the one of the reasons why I denied. More precisely, I was asked to write Java programs running in the webMethods ESB. In theory, that’s a great idea, but the lack of tools makes programming a pain. No debugger. No profiler.
In theory, you can debug such a program using remote debugging, but that requires many preconditions to be fulfilled. The administrator has to start the program with additional parameters, and they have to open the ports in the firewall. Sometimes that’s possible in the development and test stages, but usually it’s completely out of question in the production stage.
However, being a consultant, sometimes I’m asked to help our customer nonetheless. Continue reading
Everybody believes I’m diligent but I’m not. I just know how to make Eclipse do my work. It’s got so many little helpers built-in, it almost feels like an additional team member.
Read on to catch some tricks you might not know yet.
Java developers must be patient. To an incredible extend.
Mind you, back in the mid-90s IBM invented Hot Code Replacement to distract from how slow their WebSphere Application Server was at the time. It took several minutes to start the application server and to deploy an application. This resulted in very slow turn-around cycles. In other words: developers spent a lot of time with waiting.
Luckily IBM implemented Hot Code Replacement in their JDK 1.3 virtual machine (IBM J9 VM), eliminating the nasty waits almost completely. It was an awesome experience at the time. When Hot Code Replacement later was introduced to SUN’s JDK 1.4.1, we were very quick to adopt it.
By default, both Eclipse and Tomcat are configured such that every change of the source code results in reloading the context, which is just another word for restarting the application. Depending on the application, this is just a matter of seconds. It also may take a few minutes if you’re working on a bigger application. In most cases your application state is lost. You have to sign on again and to dig all the way through the seven pages of the wizard you’re working on. Did I mention the error you’re hunting occurs in wizard’s last step?
The good news is it hasn’t be to be this way. Read on to learn how to get rid of the redeployments.
JEE servers tend to create quite a few threads. Sometimes you are looking for a very slow algorithm, maybe even an infinite loop. You don’t know where to find it beforehand, so chances are you didn’t set a breakpoint. At other times the situation is even worse: the infinite loop occurred in a production environment, and you are sent a trace dump. Wouldn’t it be nice to know which thread had been working on the infinite loop?
Have a look at the code snippet without looking at the code. Today it’s not the code I’m interested in. Just look at the left margin. How many symbols do you recognize?
Did you ever look where a stack trace really comes from? You might say it is created where an error occurs. Or you might say the stack trace printout shows the precise line where the exception is thrown. Surprisingly, this is not the case.
A particularly nice feature of the Java language is Introspection. Chances are you are familiar with reflection, being the most popular API that allows a program to analyze itself. But Java doesn’t stop there. This article shows you how easy it is to find out where you are – or rather, where your JVM’s program counter points to.
Today I’ve been debugging a method that uses an aspect woven around it. AspectJ confused me a lot: it made me believe the aspect wasn’t woven around the method at all. But it was woven indeed, as I realized a couple of hours later. Let’s look at the caveat, and why it exists.
Imagine a web server that runs out of memory. Even without running an application. Sounds absurd? Well, that’s exactly what my team and I observe since a couple of weeks.