J and I and Me
  Approaches for Über / Fat JAR Deployment in Java EE
I believe the deployment and monitoring model for Java EE Application Server is outdated. If you want to learn more about my opinion refer to my article at JAXenter, the slides or my Interview at InfoQ. Instead I advocate a model to deploy an application including all the needed infrastructure as a large JAR file. This model is supported e.g. by Vert.x, Dropwizard, the Play Framework and of course Spring Boot. However, what about Java EE applications? While in theory there is no reason why a Java EE should not be deployed as a huge JAR file - but there are not that many solutions to actually do that. So here are some approaches that might be worth looking at: Thanks for the discussion over at Twitter and all the help I got there. If you know any other options - please leave a comment. Thanks!
Bookmark and Share
  MongoDB and the CAP Theorem
The CAP theorem by Brewer basically says that a distributed systems can only have two of the following three properties: In real life things are a little different: You cannot really sacrifice partition tolerance. The network will eventually fail. Or nodes might fail.
So here is a different approach to understanding the CAP theorem: Imagine a cluster of nodes. Each has a replicated set of data. When the network or a node fails there are two options to answer a query: First a node can give an answer to a query based on the data on that node. This information might be outdated. The other nodes might have received some update that are not propagated yet. So the node might therefore give an incorrect answer - so the system sacrifices consistency.
The other option in such a situation is to give no answer. Then the system rather won't answer queries than give a potentially incorrect answer. This sacrifices availability - the node does not answer the query even though it is still up.
So let's take the CAP theorem to better understand MongoDB. MongoDB uses a Master / Slave replication scheme. Data is written to a master node and then replicated to the slaves. If a network failure occurs or the master is down a slave takes over as the new master. So how does MongoDB solve the issue concerning CAP? There are settings that influence Mongos behavior: So concerning CAP it leaves you with different options: Besides a trade off between availability and consistency these settings obviously also influence performance.
If you like you can read details about what happens if a MongoDB partitions in Jepsen.
So bottom line: MongoDB allows you to fine tune the trade off between consistency and availability using write concerns and read preferences. Concerning partition tolerance there is really no choice - it will eventually happen. So it can be tuned to be AP or CP or something in between - depending on how you tune it. Final note: This is my take on CAP and where MongoDB stands. If you browse around on the web you might find different takes on it. I am happy to discuss the details - leave a comment!

Labels: , ,

Bookmark and Share
  Why Java's Checked Exceptions Are an Issue
Exceptions were originally introduced to make programs safer. Back in the days languages like C used return codes to signal whether the call was actually successful. The return codes could easily be ignored. So you end up with a program that just continues executing - even though an error occured. Exceptions are meant to solve this. To signal an error an exception is thrown. This exception has to be handled if the error should be resolved. Handling the exception is separated from the rest of the control flow e.g. in a try-block. So handling an error is separated from the rest of the program. Java introduced three types of exceptions: Originally I thought an exception is an extension of the return type of a method. Instead of a value of the "normal" return type it throws or "returns" an exception. So if the program should be sound concerning types every type of exception needs to be handled - just as you would handle a normal return value. Obviously it makes sense to use the type checker to ensure this happens. So checked exceptions make a lot of sense. Checked exceptions are also used throughout the Java APIs. The developers of these APIs obviously know what they are doing - so again checked exceptions again seemed like a good idea. However, later on I did quite a few code reviews. Some typical ways to handle checked exceptions appeared:
  1. Exceptions were just ignored i.e. the catch block was empty.
  2. Exceptions are logged. This is also what the default Eclipse code snippet does. The code just swallows the exception. However, developers are supposed to actually handle the exceptions and not just log them. More often than not a closer examination revealed that the exception really was about a serious problem and the program should probably have signaled a failure to the user - and not just continue and log the problem somewhere. This is pretty much the same situation as ignoring return codes in C - which exceptions were supposed to solve.
  3. Sometime the exception is wrapped and rethrown. This is more or less identical to an unchecked exception. The exception is just propagated. Just the type changes, of course - but that might not justify the code written.
Only seldom the exception is really actually handled e.g. by trying an alternative algorithm or returning some kind of default value. You could argue that this is just the fault of the developers who wrote the code. Why did they not implement proper exception handling? However, some facts made me wonder whether this is actually the correct explanation: So apparently checked exceptions might not be such a smart idea after all - otherwise everybody would be using them. And the reason why so much exception handling is implemented poorly might be that developers are forced to write code to handle exceptions - even if there is no sensible way to do so. This is the primary difference between checked and unchecked exceptions: Unchecked exceptions have a sensible default i.e. the exception is just propagated to the next level in the call hierarchy. Checked exceptions lack such default and must therefore be handled in one way or another. So essentially checked exceptions force the developer of the calling code to handle the exception. This makes only sense if it can be handled sensible. In a lot of cases that is not possible. Therefore I believe checked exceptions should hardly be used. In almost any case it is better to rely on an unchecked exception. Then the default is that the exception is propagated if not handled - which is usually the better alternative. Note that it is still possible to handle the exception if needed. I think relying more on unchecked exceptions is primarily a matter of courage. A lot of projects and libraries in the Java space use checked exceptions. They are without a doubt overused - see JDBC's SQLException for example. It is a checked exception but can hardly ever be handled sensible. Not to follow these bad examples truly takes courage. Maybe introducing checked exception is even the greatest mistake in Java's language design.

Labels: ,

Bookmark and Share
  JAX Preview
This year's JAX will see some interesting sessions that I would like to highlight: Some of my colleagues are also presenting. For example Alexander Frommelt will talk about IT landscapes and also about Portals and whether Portlet are really a good fit for them. Halil-Cem Gürsoy will talk about Google App Engine. So I am really looking forward to the event - and would be glad to meet you there!
Bookmark and Share
  Common Misconceptions: The Waterfall Model
I think the Waterfall Model is the result of a big misunderstanding, probably one of the worst in out industry.
Look at Royce's original paper (PDF can be found here. You will notice that the paper starts with the separation of different activities such as analysis and coding. To me that sound like an attempt to actually define basic software engineering activities instead of just unstructured hacking. The paper goes on and discusses more different phases that a project might go through. It shows a figure pretty much like the Waterfall model we are used to. No surprises so far.
But then the fun starts: The third figure already shows that the steps are not necessarily performed in order. The text says:
... as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.
Let me repeat: The original Waterfall paper says that you might need to go back to previous steps, even remote ones. It even uses the term "iteration".
It goes on and discusses that once you run in production you might learn that your system does not perform well enough. That leads to major problems - and you will probably go back to the analysis. You might call it an iterative approach - even though it is probably not voluntarily.
Even better: The paper suggests:
If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version in so far as critical design / operations areas are concerned.
So essentially you should do at least two iterations - the first version will not get it right. Another hint at an iterative process.
And the paper even suggests to involve the customer - probably one of the most important points in Agile practices.
Of course the paper includes sections that are quite different from the Agile school - such as the focus on documentation. But it is from 1970 - and the author is specialized in systems for spacecrafts. Those still rely a lot on documentation even today because of the extreme risks those systems have.
However, the bottom line is that the original Waterfall paper does not advocate what is now considered the Waterfall Model. It does not require going through the steps in order and it even mentions that the first release will not be a good solutions. Quite contrarily: It talks about iterations - very limited of course but it hints the direction Agile and iterative processes took later on.
I am still confused how the industry was able to misunderstand this paper. I wonder how much damage it did. Even today people still talk about Waterfall. I think everyone working with software processes should read this paper. I also suggest to use the term "Misunderstood Waterfall Model" when discussing a model that suggest going through the steps in a strict order. Because that model is just a misunderstanding, it is not what Royce described.
Oh, and next time someone talks about the Waterfall Model - don't forget to ask him or her whether he has read the original paper about it...
Bookmark and Share
  Some Possible Enhancements for Java and Java EE
The recent discusssion about Java EE and Spring made me think. Actually I find it odd to fight over the programming model used to develop Java applications. Neither Java EE nor Spring will go away - the market shares of both are just too large. At the end everyone involved in the discussion is trying to sell a platform i.e. an application or web server. That product must offer good support for both programming models - and all the others like Scala, Groovy etc. IMHO the programming models have a lot in common now. Spring also covers advanced challenges like Social Media, NoSQL etc - see my older blog post Spring vs. Java EE and Why I Don't Care. So it is not in the field of programming models where innovation is laking. Instead we should focus on improving the platform. So what is it that would really make Java a better platform? Here are some ideas: Those are just some - possibly crazy - ideas. My intention is to focus on making the Java platform better for all of us. And I believe for that the discussion around the future of Java must focus more on the JVM and the infrastructure like web or application server than on programming models. There is quite some innovation in the area of the programming models anyway. For example there are lots and lots of Open Source projects - frameworks and complete languages. But for infrastructure standards are needed - so any server and environment can work with the solution. So that is what the standardization process should focus on. What do you think? I am looking forward to your comments!
Bookmark and Share
  Testing: Again
As you have probably noticed, the last blog posting Testing Considered Harmful was actually a April Fool's Joke. I believe Test Driven Development is one of the most important innovations in the last years. I have been infected ever since Kent Beck explained JUnit to me. Here are some things adesso does to make TDD a reality: The list could go on. So please program - and drive - safely! If you were caught by the April Fool's Joke: I hope you don't mind. If you do: I apologize.
Bookmark and Share
J for Java | I for Internet, iMac, iPod and iPad | Me for me

Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 /


Google +
Das Spring Buch



Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff