Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this 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 more...
Fix the bug and hit reload! Edit your Java files, save, refresh your browser and see the results immediately! No need to compile, deploy or restart the server. Spring does this, which can get annoying.
Stateless model Play is a real "Share nothing" system. Ready for REST, it is easily scaled by running multiple instances of the same application on several servers. Typical Spring applications have a stateless application tier; it's not purely RESTful unless you want to be, but Spring is "ready for REST".
Efficient template system A clean template system based on Groovy as an expression language. It provides template inheritence, includes and tags. Spring uses Java, but Groovy is an option too.
Resolve errors quickly When an error occurs, play shows you the source code and the exact line containing the problem. Even in templates. Spring does this as well.
All you need to create a cool web application Provides integration with Hibernate, OpenID, Memcached... And a plugin system. Spring integrates with everything and more.
Pure Java Code with Java, use any Java library and develop with your preferred IDE. Integrates nicely with eclipse or netbeans. Spring is pure Java as well.
Really fast Starts fast and runs fast! Subjective, but Spring is pretty quick.
So what does the Play Framework actually do differently than Spring MVC?
In a nutshell what can Spring do that Play framework cannot (and vice-versa)?
I find the "pure Java" claim on either side very funny.
Of course, it's unrealistic for a project to use absolutely nothing but java. Still, a "pure Java" label should have some standards, I don't think either framework qualifies.
Play actually modifies the semantics of Java language. That is all right as long as it's clearly specified. If you do some byte code manipulation, just be honest about it. Usually it's done by AOP-ish trick, instance methods are decorated with additional behaviors, their manifest behaviors - these written in the code, are usually preserved. This is not too hard to accept, we can pretend our code are subclassed by the framework and our methods are overridden with additional behavior.
In Play, one static method calling another static method in the same class can have magical effects, and the behavior is nothing like a method call. That is a huge problem, if a Java programmer can no longer be certain what a static method call is.
Spring - well, their Java part is still pure Java all right. But it's so magical(from java's POV), and depends so heavily on a heavy framework, calling Spring "pure Java", is like calling a burger "pure vege" if we overlook the meat. The meat is the best part!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am trying study web development using Java but its seems very intimidating. all the tutorials are showing very complex methods, even the sample applications that came with NetBeans. I have some experience working with PHP but none with java.
Is there any simple way to use java on the server to just accept post requests and save to database and then display data from database without using things like javaServer faces?
Is it necessary to use frameworks like spring?
Pls forgive if i am asking stupid questions. i cant seem to find where to start learning from and tutorials seem too confusing.
Links to any good article will be very helpful
Thanks
For this purpose you should be familiar with the Servlet API, and preferably also with MVC frameworks and so on.
For the whole world to be a bit more straightforward for you and to steer away from the average-PHP-community-drawbacks (e.g. nobody tells you how to code well), I'd recommend to read THIS book.
But first of all, start HERE and then move on to THIS SITE.
The other way around (talking about DB access, not the web service here) is using raw SQL via JDBC which I won't recommend unless you have a good reason for it and you're already familiar with using a DB the right way (mysql and mysqli libs of PHP won't necessarily drive you the right path; PDO most probably will however).
Of course you don't necessarily need to use frameworks, but you're (actually in any language) way better off using them. Yes, probably the closest thing to the "nobrainers-php-methodology" (mindless coding; wiring UI, DB access and business logic together in a single file; etc.) is using the Servlet API, and then through a java.sql.Connection send your GET/POST data directly to the DB via JDBC. But doing so is slightly worse than cruelly murdering cute little squirrels/bunnies/kitties/insert_your_favourite_cute_creature_here
You'll also need a servlet container, most common of which is Apache Tomcat.
To learn Web Developing with Java Play Framework 1 is very nice:
Step by Step guide for a cool blog: http://www.playframework.com/documentation/1.2.7/guide1
Documentation: http://www.playframework.com/documentation/1.2.7/home
CRUD module documentation: http://www.playframework.com/documentation/1.2.7/crud
You get compile feedback directly in the browser.
Run your tests in the browser.
No redeployment to containers necessary/hot deployment.
No servlets.
Play 2 is already around, but going through Play 1 is much simpler if you are new a the Java world.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the reasons you should build your web application with raw Java Servlets or by using Spring MVC (or any other frameworks)?
Are there exceptions when you should avoid Spring MVC, what are the advantages of doing it with Raw Servlets?
If you're building a really quick and dirty demo that you have no intention of extending later, spring can result in a lot of additional configuration issues (not really if you've done it before, but I always end up fighting with it one way or another), so that might be a time to consider just using plain old servlets. Generally though, anything beyond just a super fast and dirty demo, using some form of MVC framework is going to make life in the future a lot easier and is also in line with best practices. Spring makes things super easy, just have to spend some time on the front end configuring everything.
I should note, there's nothing you can do with java servlets that you can't do with Spring. The big difference is setup time.
Edit: It's worth noting that when I posted this answer, I was unaware of Spring Boot that is actually quite easy to get up an running using either an embedded web server or a more conventional web container. Here's a link to a quick start example: http://projects.spring.io/spring-boot/#quick-start
Servlet technology is used for more generic server side extension for request-response paradigm.
And Spring just uses it for the Web application over HTTP.
And some quote from here:http://www.reddit.com/r/java/comments/29f3ul/why_is_spring_mvc_better_than_servlets_jsp/
Servlets are based upon a low-level API for handling requests and
responses. Web frameworks like Spring MVC are designed to make
building web applications, which handle HTTP requests and responses,
easier. Most Java web frameworks, including Spring MVC, use servlets
behind the scenes.
You CAN use servlets to write a web application, but you'll have to
handle all of the details manually. You'll get very little help with
typical web stuff like validation, REST, request/response body for
JSON, form binding, etc. You will end up writing lot of utility code
to support your web application.
Web frameworks, on the other hand, are designed to make all of this
stuff simple. With Spring MVC, you aren't bothered with manually
handling the request and response even though you can still get access
to them if you need to. Want to return JSON in Spring MVC? Just add a
#ResponseBody annotation and Spring will append it. Want RESTful URLs?
Easy. Input validation? Piece of cake. Want to bind form data to an
object? Simple. With servlets, you'd have to do all of this stuff
manually.
Using raw servlets can be a good learning experience though. It really
helps to clarify how web frameworks make life easy for you!
I have developed projects both with raw servlet and web app framework.
Framework gives you everything, only you need to is to setup and config the env, coding is much more easier. The result is that you will know nothing about web dev.
However, code with raw api and servlet gives you chance to gain experience and be a programmer.
I don't use Spring a lot. But I don't see how would it have big impact on the performance. MVC's can help, but they can create a mess and extra work and frustration.
The old good way is good enough for most projects implemented by one programmer. MVC's could help when there are more than one developer.
I would use a plain servlet/jsp for most projects. If I need reusable components, I use wicket. Servlets goes with JSPs/freemarker/velocity or other template engine for presentation.
If you follow a naming pattern for your Servlets/JSP, I don't think you need Spring MVC.
I find that, with the addition of Spring version 3+, it becomes much more easier to bootstrap a Spring Web application with all the basics. The advantage of Spring MVC is that once you've bootstrapped the application context and the database connection, it becomes incredibly easy to create new controllers and it follows a much more logic architecture that newer developers may actually find easier as they get more familiar with it.
In fact, at my previous place of work, we were in the process of building a Java Servlet Web application, but we found that we had to create our own architecture or spine of the application and that is actually more work. Spring can take care of that which means that developers can get on with the actually application logic instead of worrying about the architecture too much.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a Java servlet website, but does not use any frameworks like Spring or even Struts! It does have hibernate in it which it uses along side regular sql. It also has no unit tests. It uses cvs and ant. The server can only run Java 1.4 in the JSP's.
Aside from that, the code is fairly well structured.
Are there good ways to add more modern features to the code while minimizing the risk? It seems like we could add some spring features onto new code. And maybe replace the the cvs and Ant with Subversion and Maven, or perhaps something else.
Would it be possible to have new parts of the site running in something like Spring MVC or even JRuby on Rails?
the code is fairly well structured
If that is the case, I would start by writing several tests that ensure that current behavior/business stays the same, while you go ahead and introduce Spring in the mix.
Would it be possible to have new parts of the site running in something like Spring MVC or even JRuby on Rails
Everything is possible, but since the code is already Java, and as you pointed out "well structured", I would go with Spring.
The easiest place to start is to figure out what depends on what in order to start the "website". Once you have that, you would already have different components (on paper + in the code) that you can draft with a Spring "starter" application context, that you can load with web.xml as:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:META-INF/spring/starter-application-context.xml /WEB-INF/spring/transportes-webflow.xml ... </param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
That is before you use any Spring MVC features. Once you have that, see if you can define a domain model for this project. Then you can start converting Servlets to Spring MVC Controllers and Models ( those domains ).
As you move one step at a time, run those tests, to make sure the behavior is still solid. These can be simple JUnit tests, as well as Selenium tests that would ensure that the "website" flow is still intact.
It uses cvs and ant
I would recommend to switch your build architecture to Gradle, it does take a bit or a learning curve to wrap your head around accessing everything in a build script (which is a good thing), but it really pays off.
As to CVS, I prefer git, but if you feel strong about SVN, you can switch to that as well. git, in my opinion, became as standard to Version Control System, as Spring to Java development.
It does have hibernate in it which it uses along side regular sql
Understand the reasons regular SQL is used. If these are performance reasons, you can use store procedures instead (that you can work with from within Spring). Also see the reason Hibernate is used, as it may bring additional complexity, that you may not need, and would be better off with a simple Spring JdbcTemplate.
#tolitius has covered all bases except that I would suggest that you first add Selenium tests to cover all major use cases before embarking on any of these changes. That will make it easier to add improvements in short iterative cycles.
Why do you need to do any of these proposed things? If it's purely for the sake of being current and using newer frameworks, then I would recommend against it.
I think a good start would be to write unit tests under the current code base to help minimize the risk for future changes. Also, assuming the project structure is not too complicated, the migration to SVN should not be too difficult, and shouldn't require a change to any of the source code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a java developer, not seasoned, but I am familiar with most concepts reasonably well.
I recently built a website using Tomcat/JSP (~30 dynamic pages). I made the newbie mistake of including large sections of core logic in the JSP, using the rationalization that it's "just a simple project".
I learned the hard way. So I'm re-building the app now in google app engine using servlets and planning to use Velocity to implement it using a Model-View-Controller design pattern.
I'm also looking at Struts, but haven't used the framework before.
Can someone convince me why I should incorporate struts into this project? Is it really going to buy me a lot for a medium sized project of one or two people?
There is a clear cost in an extra learning curve with strut, will the benefits outweigh the costs? Or will the use of Velocity be enough to segregate the logic? Opinions?
I would look longer term than this project. As you saw, first time you use any technology is largely about making mistakes and learning from them. So this first project won't likely be a shining example of Struts usage once you're done.
Using Struts (and Tiles from what you indicate was a main concern: JSP copy and paste) will however be an excellent delve into "proper" MVC, i.e. it forces you to do things in a particularly structured way, and one which I happened to appreciate a lot, I was a big Struts fan.
That said, there are other options, e.g. Spring contains Spring MVC plus much much more. If you're going to invest in overcoming a learning curve, think about which framework will most benefit you overall in the medium term: which frameworks do employers in your area tend to look for, for example? At this point in time, I would go with Spring where I feel the momentum is but Struts is very good at what it does.
If you're going to learn a framework then I'd recommend Spring MVC over Struts. The learning curve isn't too steep and there are lots of Spring resources available on the internet.
Once you've got Spring in place you will find your application is much simpler to maintain and support. You'll also be able to add enhancements, like security, a lot easier.
First: don't let the name confuse you: Struts2 and Struts are very different frameworks.
Second: changing from JSP to Velocity can be a good or bad decisition, but that's not exactly the point. The point is to switch away from Model1 (rather ancient nomenclature, but still useful). That is, decoupling your view layer from your logic layer. (You can use JSP or Velocity for your view layer).
Furthermore, to decide your view layer is just a part of your architecture: you still must decide who will process the request and produce the data that will be sent to the view. The most basic option is to use plain servlets, but, again, it's better to use some framework. For this, there are a lot of frameworks in Java. The "action based" ones are a subset among them, perhaps the most simple to learn. Among them, the oldest is Struts; today the most used for new projects are (in no particular order) Struts2 , Spring MVC and Stripes - they are quite similar.
Learning to separate the logic is excellent. You can do that without using Velocity, Struts or any framework whatsoever, and you'll likely learn more about what it takes to do this separation if you try it with minimal help first.
Learning a framework (in fact multiple frameworks) is also worthwhile, but I wouldn't personally choose Struts as a first framework unless it's the one used by your employer or a prospective employer. If your employer is using Struts, I hope it's Struts 2, as Struts 1 is getting ancient.
The framework I like to work with the most is Wicket, but it's a radical shift from what you're currently looking at. SpringMVC is also definitely worth a look.
If your employer is already doing web development in Java using a framework, try to learn the framework that's actually in use, and ask your co-workers for help learning it.
Why you should learn Struts? My answer is: because employers often require knowledge of it, especially for maintaining of older projects. I didn't make any precise measurements, but I think that at my region JSF and Struts are used for web application development most often.
Struts is a quite old web framework, and it's quite clumsy to write modern AJAX GUIs with it, so there were created better frameworks. JSF is for me a bit less clumsy, but also has some problems. My favourite web frameworks are Vaadin and GWT, but I'm not suggesting anything for you - you should make the decision by yourself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was chatting to someone the other day who suggested that Rails and PHP are the most suitable platforms for web applications, and to avoid Java. My background is mainly Java, and I know that it is considered by some to be too verbose and "heavyweight", but is used occasionally (e.g. by LinkedIn).
So I'm wondering whether anyone has had success using Java for a recent web application that has gone live, either using the language itself (e.g. with Stripes/Spring + Hibernate), or the runtime with a dymamic language (such as JRuby, Groovy, Jython)? If so, please share what worked and what you would do differently.
Some background (added later):
Tim O'Reilly coined the phrased "Web 2.0" and here is his definition: http://www.oreillynet.com/lpt/a/6228
I think it's the "End of the release cycle" and "Lightweight programming model", involving rapid iterations and simplified deployment, where Java may be less suitable. Thoughts?
I would argue that there is no specific technology for Web 2.0. The main concept behind a Web 2.0 application is that much of the content is provided by it's users and not one specific person. If you can achieve this with Java, then that is fine. Many people are creating startup companies with technology that is free because they don't have the capital.
there are two totally different concepts called 'Web 2.0':
user generated content (usually with some 'social networking')
dynamic AJAX-based web apps
the second one somewhat dictates the technologies that you have to use (at least some JS, and machine-readable content in (some) responses). of course, there's nothing against using Java (or CGI, Perl, whatever) on the server.
the first one doesn't have anything to do with technology, and everything to do with the service itself you're providing. again, you can use anything you want.
why are these two mixed in the same therm? and more to your point: why are dynamic languages assumed 'more appropriate' for it? i'd guess it's just a temporal coincidence, all three things (user-generated content, AJAX, serious dynamic languages) jumped to the limelight roughly at the same time, and most of the proponents of each concept are using the other two.
in short, better avoid undefined marketroid terms like "web 2.0", and use proper descriptions. at least while working. when selling to the VCs and PHBs use any and all buzzwords that come near!
Of course it is. Java has some extremely mature and well tested frameworks for doing web applications, including so called Web 2.0 websites. Hibernate, Spring, even Struts and Tiles, or even Plain Old Servlets will do.
In addition, Java is very fast (see the Debian speed tests) compared to Ruby, which is good for websites handling lots and lots of requests, which Ajax does tend to inflate the number of! :)
Your friends, with all due respect, are dolts. Java is a rich language with incredible tools support. You could build a fantastic backend in Java and use anything you want for the front end.
It took me a while to figure out what to say in this answer because I was agape at the sheer craziness of the notion.
Where I work, all our applications are built using Java. They are web apps, built using either hibernate or direct JDBC on the data end, and using Struts or JSF for the presentation side. I would not work with JSF again unless we had access to the latest version (we were stuck on 1.0 because of our IDE) as we encountered MANY issues with it and were told that they had been fixed in later versions. As for the rest of the technologies, they work fine if you know how to use them.
In general, you are going to be better off developing in a language you know well and is capable of doing the job than in one you barely know but may be the "best" language for the job.
"Web 2.0" more often than not refers to the user interface than the underlying technology powering the webapp.
What's stopping a Java-based webapp from being totally flashy and AJAX-y in the UI layer? Nothing. You'll be writing the middle layers in Java - which is transparent to the user anyway.
I think that the people who gave you this advice are more concerned about being "hip" and (what they perceive to be) current with what is "hot" right now - which is totally irrelevant to the markup of your UI. I wouldn't listen to them.
Wonderful day, I get to post about Wicket again! :)
Java is very suitable for Web2.0 applications as long as you know how to use the tools which are available for you. The Apache Wicket I just linked is a POJO-based web application framework with such incredible way to hide all that boring server-client stuff that it allows you to do just about anything you can think of. The strong point here is that since Wicket is just POJOs, you can get very fast, iterative and unit tested code that works just as one would expect in browser.
To create Web2.0 sites with Java you don't of course have to use Wicket but I'd recommend it anyway.
I build Web apps at work in Java and then I use PHP for my personal projects. While Java is certainly capable of all that you might require it to do, I've found it a little cumbersome at times and have wished I was using PHP (or another language, for that matter). It does depend on what type and size of application you're building, but I think there are good reasons why many people choose PHP, Ruby and Python for their personal projects, i.e. where they get to choose what language they build Web apps in (and not their superiors).