Posts Tagged ‘Java’
Wednesday, November 18th, 2009
I had an interesting discussion with a colleague of mine regarding the differences between the proxy and the decorator pattern which made me give it some thought. To the untrained eye (that includes my eye!), they seem exactly the same. Infact you sometimes wonder, why the heck are there two names for the same pattern. As we’ll soon see, they are anything but the same.
I think we’re all aware that the decorator pattern is used to add behavior to existing code. This does not stop at one kind of behavior but any number of different things that we want to do. A proxy on the other hand simply delegates all calls to the underlying object delaying costly operations till they are absolutely neccessary. This basically means that what a proxy can do is decided at compile time and cannot be changed by the calling code after instantiation. Using the decorator pattern the behavior of the underlying object can be changed at runtime by adding multiple decorators to it. This behavior addition takes place at runtime depending on say user input. To put it simply, proxy is compile time, decorator is runtime.
(more…)
Tags: design pattern, Java
Posted in Java | No Comments »
Wednesday, April 8th, 2009
It’s ironic the stuff we get used to as developers. There’s so much we do repeatedly in every class or in every project or maybe even in every method yet we never realize that it’s probably best to add a new “feature” to java to make our life easier. While searching for some reading material on java’s handling of String (just to clear up some of my own personal doubts) I came across a very interesting OpenJDK sub-project, Coin. Coin, simply put, is a project to determine what small language changes should be added to JDK7. Wonderful, let’s see what people have come up with. And that’s just week 4 submissions.
(more…)
Tags: Java, java internals
Posted in Java | No Comments »
Wednesday, March 11th, 2009
In-memory cache’s can be extremely useful for small web applications where you don’t want to full-blown cache system like ehCache or simply can’t afford one. I recently had such a requirement and I must say that I kind of made a mess of it. The requirement was to cache User objects so that we didn’t have to make too many calls to the database. Let me just say outright that while such a cache is not the best idea in the world, it isn’t the worst either. When you simply need to cache a few objects to reduce the load on the db in a moderately loaded web-app, this implementation works just fine.
The service layer was my choice for the cache, I use the Controller -> Service -> DAO model in all my webapps mainly because it keeps the code clean and also because it makes it much easier to manage transactions across DAO’s. (more…)
Tags: cache, Java, java internals, web
Posted in Java | No Comments »
Friday, February 13th, 2009
I hate writing pagination code. Infact I hate it so much, I try not to paginate my lists at all. ( I know, i know, very bad on my part)
. Writing pagination code totally destroys the code reuse in an application, developers generally just copy paste the very same pagination code all over the place over and over again. Not to mention decorating such pagination displays is a pain in the ass as well. So while searching for a more concrete solution to my problem I stumbled upon displaytag.
Display tag is by far the most comprehensive pagination solution that I have ever come across. Not only is the library extremely stable, (more…)
Tags: displaytag, Java, jsp, web
Posted in Ajax, Spring | 6 Comments »
Thursday, February 12th, 2009
I have noticed a lot of people on the internet asking about method inlining. The term generally arises whenever the final keyword is discussed. Basically, it is said that compilers inline methods which are declared final thereby avoiding the cost of putting them on the stack etc and thus improving performance drastically under heavy load conditions. The same is true for variables as well, their values are inlined thereby avoiding the cost of performing lookups at runtime. What nobody talks about is what exactly is inlining.
Consider the following class :
public class Inline {
private int i;
public void methodA() {
methodB();
}
public final void methodB() {
i++;
i--;
}
}
methodB() is marked final in this case. It cannot be overriden. The compiler sees this and decides to alter the byte code of methodA() to instead look like this :
public void methodA() {
i++;
i--;
}
methodB() has now been inlined into methodA() to save the cost of pushing a method onto the stack. This invocation will work faster than the earlier one although its almost impossible to determine how much faster without a proper production environment. It’s also important to note that java code is first compiled into byte code and then into runtime code by the JVM. This change of code takes place in the JVM and not during compilation. If you open your class file you will see nothing different in it from the source file.
final variables work in the same way except calls to them are replaced by their actual values because those are not going to change once they’re initialized.
It’s been said that the newer VM’s (ever since Hotspot) no longer provide benefits of marking methods and variables final as they deduce and mark them final on their own during runtime.
Tags: Java, java internals
Posted in Java | 1 Comment »
Wednesday, February 11th, 2009
I wish spring security would work on their documentation and tell people how easy it is to implement a custom service for loading user details. You don’t HAVE to use JDBC to do that, you can write your very own hibernate, toplink or whatever DAO to do just that. It’s important to realise that spring-security does not send your password to the database ever. Instead it loads a user’s details and then compares it’s password internally before validating the user and granting it access to internal pages. (more…)
Tags: dwr, Java, Spring, spring security, web security
Posted in Spring Security | 11 Comments »
Tuesday, February 10th, 2009
Form validation is an integral part of any web application. While most developers rely on client side validations, the good ones always perform server side validations as well before accepting any data. You never know what kind of a malicious attack/vulnerability might be exposed if you don’t validate all data. Submitting, validating and then returning to the form again (if errors exist) is the normal flow but we can assist the user further by validating his data immediately. This form of validating user data is in no way supposed to substitute server side validation but only supposed to help the user and make your interface a little more snazzy.
(more…)
Tags: Ajax, dwr, Java, Spring
Posted in Ajax, Spring | 3 Comments »
Monday, February 9th, 2009
In my earlier article I had detailed how to get DWR working with spring. Once you get that done, how exactly do you use it? Even though DWR provides a very powerful debugging page, a real-world example never hurts.
I’ll construct a simple page which will present the user with a list of countries (populated via DWR on body load). Once the user selects a country (more…)
Tags: Ajax, dwr, Java, Spring
Posted in Ajax, Spring | 3 Comments »
Monday, February 9th, 2009
So I managed to configure spring security in my last article here but what do I do now. How do I create the login form, login.jsp for my users to authenticate from. I searched around and found a few articles but none that listed out the login page. Then I looked in the spring-security distribution (more…)
Tags: Java, Spring, spring security, web security
Posted in Spring Security | 7 Comments »
Sunday, February 8th, 2009
I have written another post listing how to construct your login and logout pages to work with spring-security. It’s important that you read this post first if you’re new to spring-security.
Security in web applications is a big concern. More often than not developers miss securing a few pages here and there. These pages aren’t a huge concern till someone finds them and starts to mess with your system using them. Then the scramble to fix and re-evaluate your security starts. So, why don’t we secure ALL our pages instead of most of them? And why don’t we allow access to only those which we define and block access to everything else? This inverted model of security is what has been implemented in spring security. It’s a beautiful and powerful solution to securing web apps. Yes, i’m a spring fanboi but you’ll love spring security too once you love it.
As with anything else related to spring the learning curve on spring-security is just as steep. But once you get the hang of it, it’s easy peasy and you can use the same configuration over and over again in your web apps. It’s also worthwhile to mention that spring-security’s documentation could be a LOT better in terms of content not to mention better laid out. (more…)
Tags: Java, security, Spring, spring security
Posted in Spring Security | 12 Comments »
Saturday, February 7th, 2009
I like DWR, it’s a very strong framework for enriching your simple web application with ajax. It’s particularly useful for java developers because no one likes to write javascript to make XMLHttpRequest’s to call the server, parse the response and then set stuff in your jsp so that the response is displayed in a proper manner. You can effectively expose your entire class simply by defining it’s methods in your dwr.xml and then writing converter’s for your objects. The util.js that comes with dwr is very useful too even if you aren’t using dwr, it provides a lot of helpful methods to do stuff in javascript.
The debug page is probably what I loved the most about dwr. It lists out what classes have been exposed including their methods in a very simple manner. You can immediately test if you have configured dwr and if it’s working properly. You can also test out your exposed methods, with and without parameters, and see their responses. It’s lovely and I wish more applications would do this.
Running DWR with spring however is a (more…)
Tags: dwr, Java, Spring, spring dwr integration
Posted in Ajax, Spring | 34 Comments »
Friday, February 6th, 2009
A question commonly asked on the spring forums is that a service makes calls to multiple DAOs, how can ALL the calls be rolledback if any of the calls throws an exception. The simplest way to do this is to make your service transactional while keeping your DAOs non-transactional.
Example Service :
//imports & package
@Service
@Transactional
public class UserServiceImpl implements UserService {
@Override
public void addUser(User user) {
userDao.doFirstOperation();
userDao.doSecondOperation();
}
}
Notice the lack of @Transactional annotation in the DAO below.
public class UserDao {
public void doFirstOperation() {
// some stuff
}
public void doSecondOperation() {
// some stuff
}
}
Remember that your DAO methods MUST through an unchecked or runtime exception for the transaction to rollback on its own. Otherwise you have to declare the rollback in case of a checked exception.
Tags: Java, Spring, transaction management
Posted in Spring, Tips & Tricks | 5 Comments »
Saturday, January 31st, 2009
More often than not you need your java program to perform an operation at a particular time. It gets trickier when the operation needs to be performed at regular intervals. There are a lot of solutions to implement a java “cron” of sorts available. There’s the quartz scheduler which has pretty much everything that you will ever need in terms of scheduling, then there’s Spring TaskExecutor’s which can do pretty much everything but are a lot easier to configure than a full blown job scheduler.
(more…)
Tags: cron, Java, java cron, job scheduling
Posted in Java | 2 Comments »
Saturday, January 31st, 2009
Spring Framework is by the most versatile framework for java applications. It can be used with any kind of application, be it an applet, a swing app or a web application.
Spring transaction management is one of the most powerful features of spring. It manages your transactions for you with minimal code, infact all you need to do is put a few lines of code in your configuration file and then annotate your classes/methods with the @Transactional annotation. Combining this with ORM tools such as hibernate, what you have is full fledged transaction management running in under 5 minutes.
(more…)
Tags: hibernate, Java, jmx, monitoring, Spring
Posted in Spring, Tips & Tricks | No Comments »
Friday, January 30th, 2009
I’m asked the difference between the two interfaces, Serializable and Externalizable more often than i’d like. It’s pretty simple really. Serializable does all the dirty work for you, it writes the object to the output stream on it’s own without you having to bother about anything at all. Externalizable on the hand makes you do ALL the work. You must handle the reading and writing on your own.
The easiest difference to remember is the methods to be implemented by the class. That information can be easily obtained from the javadocs.
The major difference however, the one most people miss, is that the default no-arg constructor is called during the reconstruction of an object who’s class implements the Serializable interface. However, this call is not made for a class which implements the Externalizable interface.
Hope that helps.
Tags: externalizable, Java, serializable, serialization
Posted in Java | No Comments »