Just as it is a good practice to make all fields private unless they need greater visibility, it is a good practice to make all fields final unless they need to be mutable.
in Java Concurrency in Practice (page 48)
Are you following these fundamental principles?
Just so we’re on the same page, an immutable object is on whose state cannot be changed after construction.
This view is supported by Joshua Bloch in Effective Java (2nd). Item 13 states: “Minimize the accessibility of classes and members.”
The single most important factor that distinguishes a well-designed module from a poorly designed one is the degree to which the module hides its internal data and other implementation details from other modules.
He goes on to say some fundamental principles.
A well designed module hides all of its implementation details, cleanly separating its API from its implementation. Modules then communicate only through their APIs and are oblivious to each others’ inner workings.
Effective Java (2nd), page 67
These are really the basics of information hiding or encapsulation. Basics of OOP programming! It’s a good idea to learn these well.
Think twice before making any fields public. Hold it. No, don’t make it public! Think twice before making it any other than private!
But to make sure you only expose what is absolutely needed requires some thought. You need your own judgment and experience.
As for the second part, item 15 states: “Minimize mutability.”
I think this one is a little harder to justify and not so obvious. But Bloch has some very good arguments. Together with Goetz, they convinced me that I should utilize immutability more often when I’m designing classes.
Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure.
But how? Follow these 5 steps (as per Bloch).
1. Don’t provide any methods that modify the object’s state.
2. Ensure the class can’t be extended.
3. Make all fields final.
4. Make all fields private.
5. Ensure exclusive access to any mutable components.
Goets says it a little bit differently.
An object is immutable if:
– Its state cannot be modified after construction;
– All its fields are final;
– It is properly constructed (the this reference does not escape during construction)
Immutable objects pack a lot of goodies in them.
One more time. Tell me what are the benefits of immutable objects!
They are simple to understand.
They are thread safe.
They require no synchronization.
Let’s end with a great summary note from Bloch, “Classes should be immutable unless there’s a very good reason to make t hem mutable.”
“If a class cannot be made immutable, limit its mutablity as much as possible.”
Learn these design principles!
All in all, I recommend reading Item 15 from the Effective Java book. And re-read a few times until it becomes part of your design logic.
It’s all about getting better.
It’s all about improving.
It’s good to learn from the pros. Everybody needs a little guidance. I know I do. (These 2 books are excellent! Recommended.)
Beginning Java™ EE 6 Platform with GlassFish™ 3
by Antonio Goncalves
Date Read 12/2009
If you’ve been following the Java EE world, you know that Java EE 6 along with Glassfish v3 application server were released recently. This book has been around since mid year! And it’s still the only book on the subject. To me this was a great gift: I was able to get a complete sneak peek at the new technologies to be released ahead of time.
But was it worth it?
Great overview. If you want to learn what the buzz in the Java Enterprise (EE) world is all about, this is a great book to read. The author does a great job in keeping things at a fairly high level. He focuses on giving you just enough details (but not more), so you can actually start playing around with the technology. That makes this book easy to read. And practical — pragmatic!
Covers the important EE technologies. JPA. JSF. EJB. JMS. Web Services (SOAP and REST). JPA is covered really well. Four chapters dedicated to that. Four chapters for EJBs as well. And three for JSF. Two for each of the web services specs (one for SOAP and one for REST). The coverage on these should be enough to get you started and start playing around. The other technologies are covered very briefly.
Quick read. Not too deep. Not too shallow. This is the author’s style. It’s easy to read. The author gives you a lot of examples in between. On the other hand, at times, it would be nice to have a deeper treatment of a given technology.
Lots of examples. I love to see that. But not every chapter is treated the same. Some chapters have a complete example (Putting It All Together), and some don’t. I was able to run the examples from some chapters but not from all. I had to modify several to make it work. I wish a greater care was put in this area. It’s frustrating when you try to run something and you can’t. But if you’re willing to research it by yourself, you will learn more! I guess that’s the upside. But it does slow you down a bit.
Some technologies are not covered. CDI, is not there. Very light treatment of bean validation.
Overall, an excellent overview of Java EE 6, but not a complete guide/reference on the subject. I was very happy to see this book. And I’m very happy that I had read it. From what I see (at least on Amazon), a second edition will come out in a few months — might want to wait for that. Overall, a very good book on Java EE. Recommended.
I am excited. For the first time, I can say that Java EE development can actually be fun and cutting edge. Jeremy Norris recently said, and I retweeted it, “If you’ve chosen Spring by default since 2005 for your EE needs, you owe it to yourself to take a real close look at JEE6.” I totally agree.
Just to give you some background. My exposure to Java EE has been limited. I have not really programmed in it. I did for 6 months or so, but it was in the J2EE 1.3 world and it was ugly/slow/overly complicated. I’ve tried to stay away from J2EE. Spring was a bit different. I’ve done Spring programming for a few years and generally have a good experience with it. But I don’t like too much XML configuration. I don’t like the fact you can easily get “tied” to the framework, which I don’t consider a best practice. Spring is a vast improvement over J2EE, but it’s not optimal either.
But now, Java EE 6 and Spring 3 enter a different ball game. I’m interested to see how it plays out. One thing I’m sure: the newest Java EE will be a good Spring competitor. Will it win? We’ll see.
I’ve always wanted the Java EE platform to be easier. JEE 5 went in that direction, but not far enough. Java EE 6 takes a few more steps. And I believe that it has crossed the “innovative/fun/cutting edge” line while allowing you to do some powerful stuff. Of course, it remains to be seen, but that’s what I feel now.
Here are some of the reasons why I think so…
No XML configs. Gone are EJB descriptors. Gone are JSF navigation rules. You don’t need XML for dependency injection. All of this means that this is really a big step forward. In some cases you might still need an XML config, but I like how it’s “configuration by exception” — that is, you might need one if you want to setup something other than the default configuration.
JSF 2 is fun. If you’ve ever developed web apps in Java, you know that it’s not optimal. I don’t like it when I see Java code inside JSPs. Who uses JSPs any more, anyway? Working with Spring MVC/JSTL is limited. Not bad, but tedious. But with JSF 2 and Managed Beans, you get a really nice, simple, and powerful solution. All you really need is one Managed Bean and one XHTML file. Really easy to get started. And I find this model of development intuitive: your view is tightly connected with the data. You don’t have to marshall/unmarshall the request in your controller. It’s done for you. Nice and simple!
JPA 2 is easy to use and robust. Powerful as well. It’s an excellent solution as an ORM. Ability to use JPA as a stand alone solution is also great.
EJB 3.1 is easy. Yes, easy. Want proof? Add @Stateless to your Java class and you’re done. No more configuration is needed. Want more? Create a webapp, add a Java class, and add a @Stateless bean. Deploy it to an app server and you have an EJB application! Done! No, you don’t need to package it to an EAR file (I hated that). Really cool.
Glassfish v3 is solid. It fully supports Java EE 6. I believe it’s the best EE application server out there. Good job to the team! Plus, with a stack of Java EE 6, Glassfish v3, and Netbeans 6.8 (no, it’s not my IDE), you can have a simple JEE app running in 5 minutes or so.
Testability. Embeddable containers. EJB has one. JPA has one as well. It’s really simple to setup some powerful integration testing. This is some serious stuff. You can test your database logic fully with an embedded database. EJB container testing is easy as well! Built in Java EE 6. You can test your EJBs with JUnit!
There are many other nice features with this release. I don’t know them all. And again, these are just my observations. So far, I’ve only read Beginning Java EE 6 with Glassfish 3 and tried a few things. Nothing serious. I’m going to learn more. I’m going to create applications based on it. This is some really exciting stuff. I just hope corporations that are still in the J2EE world move into the Java EE 6 world soon. They have good reasons for doing so now.