Web Structures: How is the game different from Spring MVC?

Question

The Play Framework offers the following quick overview, but with the exception of the Groovy template engine (which you can get in Spring MVC if you want), Spring seems to offer all the same features and much more ...

• Correct the error and click reload! Edit your Java files, save, update your browser and immediately see the results! There is no need to compile, deploy or restart the server. Spring does this, which can be annoying.

• The stateless model . A game is a true Nothing in common system. Ready for REST, it scales easily by running multiple instances of the same application on multiple servers. Typical Spring applications have a stateless stateless level; it's not pure RESTful if you don't want to be, but Spring is "ready for REST".

• Efficient template system A clean Groovy-based template system as an expression language. It provides template inheritance, and includes tags. Spring uses Java, but Groovy is also an option.

• Resolve errors quickly When an error occurs, playback shows the source code and the exact line containing the problem. Even in the templates. Spring does it as well.

• All you need to create a cool web application . Provides integration with Hibernate, OpenID, Memcached ... and a plug-in system. Spring integrates with everyone and more.

• Pure Java Code with Java, use any Java library and design with your preferred IDE. Integrates well with eclipse or netbeans. Spring is also pure Java.

• Really fast Starts fast and fast! Subjective, but Spring is pretty fast.

So what makes the Play Framework actually different than Spring MVC?

Answer 1

I find the “pure Java” claim on both sides to be very funny.

Of course, it is unrealistic for a project to use absolutely nothing but java. However, the “pure Java” label must have some standards, I don’t think any framework qualifies.

Play actually changes the semantics of the Java language. Everything is in order, if clearly indicated. If you are doing some bytecode manipulation, just be honest about it. Usually this is done using AOP-ish trick, the instance methods are decorated with additional behavior, their explicit behavior - they are written in the code, as a rule, are saved. It's not that hard to accept, we can pretend our code is subclassed by the framework, and our methods are overridden by additional behavior.

In Play, one static method that calls another static method in the same class can have magical effects, and the behavior is not like calling a method. This is a huge problem if a Java programmer can no longer be sure what a static method call is.

Spring - well, their part of Java is still pure Java. But it is so magical (from java POV) and so heavily dependent on the heavy structure, calling Spring “pure Java” is like calling a hamburger “pure veg” if we don't see the meat. Meat is the best part!