Pointers to user profile frameworks in Java - java

I'm looking for pointers to something that I may be overlooking (or maybe something that Jivebot hasn't yet written for me). What I want is a pre-rolled Java framework for managing user accounts that takes care of most of the common tasks associated with such.
For instance, Jfacets is a good approach to automagic view controlling, but you still have to roll the view code. I wonder if there's a framework that has pre-rolled components for inputting/storing common user profile information, sessioning, and possibly things like inter-account communication, connecting to common social APIs, exposing an API, etc. (basically some/all of the common tasks that a user profile-based app would want). It can be quick and dirty, this is a prototype app at the moment.
I do know that user profiles are a very app-specific arena, and that I may just have to build something up, just thought I'd check first.
In the absence of a pre-rolled solution, I like what I see in Woko after an initial glance (http://woko.wiki.sourceforge.net/). The preconfigured stack includes Hibernate, Spring, Compass, JFacets, Stripes, and Maven and an API framework. I may just need to build the prototype up leveraging this as much as possible.
Thanks

So, it looks like user profiles are just too situation specific for any framework. Shame, because there's a lot of basic functionality that could be served by a basic framework.
On the "solution" front, I'm attending the Open Source Bridge conference in Portland, Or. and recently saw topics on Scala (Two word description: Java scripting) and a framework built on that called Lift (three word description: CodeIgniter for Java). In short, these technologies rock my world.
Anyone looking for robust web frameworks should check out Lift. Scala allows people who love programming in Python and Ruby to use Java's JVM without the cost, with a lot of syntactic elegance (Scala is somewhat more intuitive to my Python-centric mind than Clojure). Lift is a MVC-style framework built on Scala which is just plain beautiful- and frighteningly easy to use.
Normal disclaimers, but the upshot is that it will take significantly less time to build an app-specific solution for a scalable Java app using these technologies than trying to find a user profile framework to use.

Related

Python web frameworks vs Java web frameworks (how is web development in Python done?)

I am thinking in starting a personal pet web project to experiment with different things and extend my knowledge.
I use Java a lot at work (for web applications :D) and was thinking in making my own in Python since I kinda like this language but never passed the simple scripts stages.
I want to step up a gear regarding Python (using 2.6.5) and don't know what to expect or what framework to choose from: Django, Pylons, web2py etc.
I also don't know how much these frameworks will offer me and how much will I have to write from scratch.
I could use a comparison with Java if somebody can provide me with. I'm thinking at filter functionalities such as sitemesh, custom tags like JSTL; In Python, can I write clean pages of HTML with tags in them or write a lot of print statements (something like servlets did in Java etc?
I don't know exactly how to phrase this question.
I actually need a presentation of how web development is performed in Python, at what level, and what the web frameworks bring to the table.
Can you share from your experience?
TIA!
hi try bottle python framework (bottle.paws.de / bottlepy.org) its really nice to use blistering fast and gets out of your way + the best thing about it is that its one single file to import, i recently migrated from PHP and i have to tell you am so ... loving it!
Python web frameworks run the full gamut of capabilities/facilities, all the way from shims around WSGI such as Bottle and Flask, all the way to full frameworks such as Django and TurboGears, and even "megaframeworks" such as Zope. Each does things slightly differently, but there will be some familiarity from one to the next.
It may sound strange, but there's no need to know "how web development is performed in Python" to start doing it.
In fact, working with language/framework/etc is a single most reliable way to get understanding of it. You won't gain a lot from one-page summaries.
Also, comparing it with Java isn't likely to help. There's no point in doing "Java-style development in Python". If you want to benefit, you'll need to clear your mind and do everything "Python-way".
As to what Python framework to choose, Django seems like like a good starting point. It's very popular, which means you won't be left without tutorials/documentation/help.
PS Short version: just do it.
Python web frameworks do it in a similar way as some Java-based frameworks. I can speak for Django here.
A good comparison could be Play! vs. Django. Both of them foster using an MVC architecture (or MTV = models, templates, views) and already provide you with a lot of things like CRUD operations in admin pages, ORM, authentication, URL configurations, a template language and much more.
Other Java-based frameworks might differ a lot, and I can't give you a general answer. Depending on the choice, there are only few differences. You can simply choose the language and framework you like the most. I'd recommend to go through some tutorials (Django tutorial, Play! framework tutorial for instance) and look which one works best for your needs.

Is Spring the right choice for me?

I want to start developing a little web-based game, and would appreciate some advice before I get into it. Hopefully this is the place to ask!
The game is basically a fantasy-football style game, where you create a team of players which compete against other users. Nothing fancy.
I haven't coded much since college, and am very rusty. I want to code in Java for a couple of reasons:
It is the language I am most familiar with.
What limited development work I have done since college has been in Java (I have some novice-level experience with Tomcat and Glassfish, i.e. I have got them running and deployed basic webapps I've coded from scratch to them).
I really like what I have seen of the GWT framework so I would like to develop my GUI with that.
The last time I did any programming was about 3 years ago when I wrote a web front-end for a crappy helpdesk system that only had a thick client and a web API. That was done in Java.
So basically, first up, I want to get a skeleton game up and running. Basically allow a user to log in, see their team, log out. So my questions start with:
Is there a particular development framework I should be reading up on? I've seen Spring recommended - is this a good choice? I've found this to get me started if it is the appropriate choice: http://static.springsource.org/docs/Spring-MVC-step-by-step/
What is the easiest way for me to handle login/authentication/authorisation without having to write a security system myself? Hopefully there is some kind of framework/library I can just drop in to the code? Or does Spring Security handle that?
I really like GWT - are there difficulties integrating that with Spring?
Many thanks for your time, I really appreciate it!
Spring is a good choice.
Check out the Spring security module. It's based on aspect-oriented programming ideas.
Looks like Spring does support GWT. It's relatively new (May 2010).
If you're rusty with Java, you might want to minimize the new technologies you introduce at one time.
Java's an object oriented language, so you can write the objects you need to model your game and get them running without any UI or database at all. That would allow you to focus on the game, the objects, and the use cases without getting wrapped around the axle with UI, security, persistence, etc.
Once you have that sorted out and fully tested you can turn your attention to the other features: persistence, UI, security, etc.
Maybe you can try basic authentication/authorization before you dive into Spring Security.
If you bite off too much at once you'll never get this done. Take small steps.
Spring is the par exellance example of what the cool kids don't like about Java. Many, many configuration files that make every aspect of the app customisable but is difficult to keep in your head where stuff belongs. If you are not a huge company this is almost certainly not what you need.
I would encourage you to look into the Play or Wicket framworks if you want to keep using Java. Both are conceptually simpler, don't throw in the kitchen sink and are heavily geared towards web sites. Spring MVC is just a part of the very large Spring ecosystem.
For the Inversion of Control (Dependency Injection) paradigm that Spring often is associated with, I find Guice way more awesome.

a large scale java project solution

I would like to start up a project from scratch. I am a java developer for years. I did even write my own mvc framework some time ago for fun. Now I am working in a company using in-house framework - which i think is a total loss of time and money. I respect the idea of teaming up with different skilled people for a large scale project. The separation of the project is very important; Graphics guys, front end developers, software architectures, software developers, database experts, etc. I cannot risk to use a scripting language like php.
Lately, I am researching java technologies for a large scale project in every aspects. What I mean by that, for the front layer I come across with very famous technologies.
Spring
MyFaces
Tapestry
Google Web Toolkit
Cocoon
Velocity
Every one of them states that it is the simplest, the fastest, the latest technology and whatsoever. Of course only one them can hold the truth. I need a front end technology for fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb. It should also have IDE support, community support, rich documentation and online tutorials. Still I have no experience of those frameworks which to choose from. Maybe there is even better one? And most importantly, I cannot risk to start up on a technology which has development limitations. Is there any suggestions for this layer?
For the business layer, I am sure of EJB and JPA. I do even considering a web service for facade of this layer for interoperability purposes for future extensions. However, I have no idea about securing that layer (it could be applied on its web service level) which is still a problem for me. For the application server I am considering GlassFish.
And for the last question is what IDE should be picked for development. Regarding all the technologies, which are going to be used, an IDE should help me in every step, either doing the configuration for me or helping me configuring with its ready wizards. I suppose the IDE will have proper plugins for to be used technologies.
I know that I want too much, however I have a hope for a combination of technologies which will help me saving time and money in my future plans.
I ll be really glad to hear your responses, experiences for a bigger picture.
edited: There is no ultimate answer, I know that. I am just taking advice. Any answer is appreciated.
Well, I'm going to go out on a limb and give concrete recommendations, since I think the question can be answered.
I'll simply recommend my stack.
My stack is Stripes for the front end, and Glassfish/Java EE 5 on the back end.
Stripes is a simple Action (or MVC, whatever floats your boat), that has a small, but robust and vocal community. It has tight integration with JPA (through a plug in), a very good, and current, printer book on the topic as well as excellent reference documentation. It's main rendering tech is JSP with JSP Tags and EL.
It is not a component framework like JSF/MyFaces, so it's implementation is simpler, and it's lifecycle is simpler. It works very well with Ajax.
The key factor around Stripes, since it's based on the HTTP request cycle is that it does most of the grunge work for you, yet is very lightweight. It's easy to pick up and understand. Creating a basic Stripes app is a couple lines in the web.xml and two jars (one of which is log4j). If you can think in HTTP, then Stripes is a good fit for you.
On the back end I would simply stick with EJB and GlassFish. Java EE 6 and GFv3 are out have been out for sometime. It offers a lot of new features over Java EE 5, and GlassFish offers most any web service tech you would like to use. Java EE 6 and Spring are pretty much equal on a bullet point by bullet point basis, and since you were looking at GF, you may as well use EJB since it's there and integrated in the box. If you were using Tomcat, then Spring might be a good choice.
And, that's it. That's all you need (I dunno what you wanted Velocity for, you can add that trivially if you like, but I wouldn't use it for pages, personally, modern JSP is much better IMHO).
Glassfish will secure your web services, you can use Java EE security with your web apps, you can share logic between the back end EJBs and your web app and web services. It all works out of the box with 15 minutes of configuration to get Stripes running.
I use NetBeans, but all of the other IDEs work as well. NetBeans is nice because it come integrated with Glassfish. One less thing to configure. Download it, fire it up, and it works.
There's a Stripes plugin for NetBeans, that I don't use. I don't see a need. Once you add your few lines to your web.xml that you cut and paste from the web site, you never see Stripes again. From there, it's all simple annotations.
Unless you have a crushing need for all of the complexity and learning curve of a component framework, it doesn't get any better than Stripes, and GF w/Java EE 6 has everything you need in the box.
So, in summary: Stripes distro from www.stripesframework.org, NetBeans download from netbeans.org, and stripersist from stripes-stuff.sourceforge.net. It's a rock solid foundation that will go wherever you want to take it.
Come on by to the Stripes IRC on freenode at #stripes, and we'll answer any question you have (or hit the mailing list).
Well, first of all, your question is not good. Every technology has it's bright sides and dark sides. To choose some specific technology - you need experience in all of them to estimate which problems can emerge with your project. Given your definition: fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb - 90% of frameworks support all of it either directly or using some plugins.
Moreover, various technologies are better optimized for various needs. You can't have a all-in-one-super-framework that is flawless and does everything the best way possible. Given that the framework is highly scalable and fast (example: Spring and/or Portlets) will make it hard to configure for some small tasks.
So the only thing I can recommend is to google "Java Web Framework Comparison" and hope for the best.
As about IDE, I can see only 2 choices: IntelliJ Idea and Eclipse. Again, there is no clear winner so yet again google is the only source of information you can get.
Added:
Talking about frameworks again, complex projects use several of them at once taking the best parts of each to aid with the specific project needs. But to do that effectively - you need to be a guru in all of the mixed technologies.
There is almost no way that someone can actually answer this question for you. In terms of frontend technology, one of the frameworks will work for you and others won't. It all depends on which one makes sense to you. My suggestion would be to try them all out and pick the ones that you feel the most comfortable with.
With that being said, I do have a few suggestions. First, don't limit yourself to using Java. If it were me, I would use Ruby on Rails running on jRuby as the frontend as it is the fastest framework for developing web applications that I have used. By running it on jRuby, it allows you to hook into Java and let java and its libraries do all the heavy lifting on the back end. I would stay away from web services and implement things using ReST.
In terms of an IDE, definitely go with IntelliJ IDEA. It may take a little bit to get used to, but it is definitely the fastest IDE on the market. However, both Eclipse and Netbeans are also very good for Java and a tad cheaper.
Once again, the answer is, "it depends".
All of the above projects started off with simple ideas. As they gained traction, they have all added neighboring features which are useful to some but not necessarily all. In other words, you will have to do deep analysis to pick the perfect framework.
You are not going to find a perfect match unless you just happen to be of like mind as the dozens of people working on the particular framework, assuming that all those minds were ever in perfect agreement. The only "perfect" fit is the one you write yourself, and even then you find it's not perfect as you are limited in time and effort on developing the framework; after all, you DO have a program to write, and the framework development time competes with the program development time.
As far as IDEs go, there's differences in taste and style. I tend to gravitate between the old standbys of Netbeans and Eclipse, and my next IDE to play with will be IntelliJ Idea. The thing to remember is that most people commit to one IDE and then defame the rest, so you really can't get a good comparison. IDEs take too much time to really learn for a person to give a honest unbiased opinion. A good candidate IDE "X" will be the worst in some eyes and be the best in others.
Given how the other answers look, I would say the biggest remaining factor is the learning curve for you and your team. Given your description of the separation of roles, your primary concern should be picking an overarching framework, such as Spring. From there, your database guys can pick whatever they want for data persistence (hibernate, jdbc, whatever) and your gui guys can pick whatever they want for their front-end (tapestry, jsf, etc.).
The primary concern I would have with such a distinct separation of roles would be the communication on the team. Make sure that their is a high degree of open communication, especially when discussing interface design, as those will be integral in the success or failure of your project (especially if you pick Spring).
As far as IDEs go, it's personal preference. The two mentioned in the other posts (Eclipse and IntelliJ) are the two I hear the most about, with Eclipse being my standard IDE for the last 4 or 5 years. I'm not familiar with IntelliJ, but I know that Eclipse has plug-ins to support Spring, Hibernate, and a host of other frameworks and ORM solutions. It also has plug-ins to support other languages as well, such as Ruby and PHP.
"I did even write my own mvc framework some time ago for fun" - at the end of the day it may happen that you will regret that you did not stay with it. In fact the technology that is better than currently "famous" most probably is the one that will be famous a little bit later, not now. Half of your list is already "famous" as obsolete.

Web: When should I consider using Java rather than PHP, Python/Django, Ruby/Rails, etc?

If gathering requirements for a medium-to-large web-based project, at what point should one consider using Java-based back-end, JSP, etc, over a scripting language like PHP, Python, or Ruby?
Hearing "use the right tool...", when is Java the right tool for web-based projects?
What is the "Best" language is often degrades to an emotional debate rather than practical. Champions of each language are extremely good at making arguments for why each language is the best. I ususally look ata couple of factors:
A) What languages are you and your team confortable with?
B) Is there an existing application/system to be extended or integrated? If so, what languages are most effective for such an integration
C) Are there built in or redily available libararies, components, etc that will allow you to more effectively produce results in one language over another
My decisions almost always boil down to what language/platform is my team going to be most effective on both developming and maintaining.
In my opinion, the language decision cannot be made independently of the larger development and runtime platform. This is implied by what James Conigliaro wrote, and also by what jonnii wrote, but neither called it out specifically.
Making such a decision, people often use unwarranted relative weightings for different evaluation criteria. For example, one of the criteria might be "runs on iPhone." But if you are not actually developing on an iPhone, you really don't care.
"Performance" is another criterion that can get an unwarranted weighting. Most Intel-based servers today, costing let's say $2000 without storage, are plenty fast to support a fairly high-volume web site regardless of your choice of language. If your load exceeds that which can be run on a single server (don't assume!), or if you need to share the server among different workloads, then perf may become more important. But generally your app load will fit in a 1-server box.
The development environment, including the IDE but also the source code control, the configuration management, and defect tracking - I guess what you might call application lifecycle stuff - is more important, in my opinion, than the language per se.
Another aspect you may wish to consider is, the "pull" the language itself will have on devs for your team. In the early days of Java, you could attract devs just by saying "we're doing it in Java." Now, that phenomenon has largely faded for Java, but in pockets it may still be true for other langs and platforms. This factor may or may not be important to you.
Pick the language/platform that your team is most comfortable using, the one which matches your deployment target and that you're mostly proficient in.
I have over 20 years of programming experience and I learned one important fact: it doesn't matter which tool you use, as long as you're comfortable using that tool. For larger teams, all team members must be comfortable with the choice you made.
I always tell people that it doesn't matter which tools you used to create an application. All that counts is if it will work as expected.
I'm planning to use Java for a project served using Google App Engine (Java support, of course). This is not The Answer [tm], but only my 2 cents :-)
Whoever has the libraries you need:
If you want to customize something pre-made, use PHP. This will usually be shopping carts, forums, and CMS
Java will have more libraries for random things (like fetching RSS feeds)
Don't know about Python/Ruby on Rails;
Rails is simple to learn, well organized and well documented. It's also agile and RAD (rapid application development). It's not perfect, but you could give it a try. It's another take on the web development. Java web framework are not so easy to understand and start is not so simple IMHO.
If you have to build a large web application, with rails you could separate the monolith app with different apps and then use ActiveResource restfully.
http://guides.rubyonrails.org
Almost always :-)
What I mean is that you can do any web project with Java/JSP adding more or less to the mix ( Spring, iBatis, etc )
But, as already pointed out, there are cases when you decide to use something else because for instance your team has a lot of experience with younameit and no experience with java or things like that.

How to improve productivity when developing Java EE based web applications

I'd like to know how you address the seemingly low productivity of Java EE-based web application development compared to other technology stacks (Seaside, Ruby on Rails, etc).
The constraints are:
The finished web application must be deployable on Java EE compliant application containers
If possible, previous investment in Java-based solution should be preserved, i.e. native interoperability with Java-based systems and libraries should be possible
Due to team structure, Java as implementation language is preferred, although less exotic JVM-based languages (i.e. Groovy) might be acceptable as well
The resulting system needs to be architecturally sound
The resulting system needs to be extensible and maintainable
To not let this dwindle into a philosophical discussion, I'm only interested in suggestions that are based on practical experience. Possible examples include domain specific languages, frameworks and MDSD.
If you point to an abstract class of solutions (like MDA / MDSD), please provide details on how you implemented it as well as information about common pitfalls and best practices.
If you disagree on the assumption that Java EE-based web application development implies inferior productivity, I'd like to hear your reasoning as well.
EDIT:
As there are a lot less answers than I expected, I'll accept accounts of abortive attempts as well, basically extending the question to "How (not) to improve productivity when developing Java EE based web applications?".
I believe the Java EE Java stack is actually very good. There are a few reasons explaining the low productivity of Java EE:
Being “the enterprise stack”, it is often used to create boring, ugly, “good enough” applications and, in general, enterprises tend not to attract great developers who love programming, and think and care about what they do. The quality of software in the enterprise world is not great.
Being the enterprise stack where the money is, software vendors try to sell something to them. They create huge, complex and expensive solutions not because they are good, but simply because they could sell them to enterprises.
Enterprises are often very risk averse and everything they do better be “standardized”. Standards are created either after some technology proved to be successful or before. In both cases, it’s bad for enterprises (and Java). Enterprises end up using either good technology too late or a downright failed technology. The latter case is also very dangerous because it creates a false perception that a technology (otherwise a complete failure) must be good if it is standardized and everyone is using it.
Historically, Java EE platform seemed to have attracted a lot of architecture astronauts and developers in big companies promoted to architects whose only purpose was to create more layers, more frameworks, more abstractions and more complexity.
It’s not that there are no good Java tools and frameworks; it’s that there are too many bad ones, too many over-engineered ones, too many bureaucratic processes and methodologies, too many useless standards.
In such a messy world it’s not just the particular selection of tools you choose that affects your productivity. It’s mainly about you, about your values, about how you can reject the majority of solutions proposed to you by the community, vendors, co-workers and managers. It’s about you going against the current, about your common sense, about you questioning every mainstream belief and “best practice”.
That said, tools alone are not going to change your productivity much, and conversely, the right people can be productive with inferior tools too.
My advice:
Don’t use a technology only because it’s standard, because everyone uses it, or because it’s officially recommended by Sun. Use a technology only if you personally think it’s the best tool for your job. This way you may find yourself rejecting technologies such as JSF, JSP, Web services, JMS, EJB, JTA, OSGi, MDA.
Keep it simple, use your common sense, question everything. Do you really need to publish your objects for remote access? Do you really need to create another abstraction layer so that you can switch from Hibernate to TopLink? Do you really need to convert your data to/from XML ten times every time you need them? Do you really need XML schema? Do you really need everything to be configurable are interchangeable? At runtime? By non-developers?
Keep the process simple. Be agile. Do you really need that documentation? Do you really need to describe every screen in a huge table, have it approved, type it in to some home-made tool and then generate JSP? Do you have competent programmers or you design everything first and programmers only “translate” to Java?
WYSIWYG design of HTML doesn’t work.
Graphical programming in general doesn’t work. This includes UML as blueprint and UML as programming language, MDA, drawing page flow diagrams. Code generation is bad.
Never design a framework prior to using it, always harvest a framework.
Prefer frameworks that have only little XML configuration.
Strive for low LOC count. Look at actual characters in your code. Is every character important? Think. What can you do to make your code smaller? Do you need that class? What does it do? Why do you need to do that?
Testing is not sacred cow; you don’t need 100 % test coverage. Test only what makes sense. If it’s difficult to test, make it simpler; or don’t test it at all. Don’t test visual appearance.
And finally, some concrete Java recommendations:
For presentation layer try Tapestry. Why do I love it? Because with Tapestry you can create beautiful code. It’s designed specifically for that, so that your code can be beautiful. Your code. By beautiful I mean everything that matters – it’s short, easy to change, easy to read, easy to create your abstractions, and still flexible, it doesn’t try to hide the fact that you are developing for the web. Of course, it’s still you who makes your code beautiful.
Feel free to use Hibernate, especially for CRUD and large apps. Don’t bother with JPA. It’s not a silver bullet though, with ORM you are always going to trade one set of problems with another.
Only a little Spring, you shouldn’t need much since you’ve carefully avoided all the Java EE traps. Use dependency injection sparingly.
After all of that, you may find the Java language too verbose and not very helpful when abstracting away you copy/pasted code. If you want to experiment, try Scala. The problem is that the main selling point of Scala is that you get all the benefits of modern languages while still keeping type safety, and at the same time, there is no solid IDE support. Being used to super-cool Java IDEs, it doesn’t make much sense to switch to Scala unless there’s an IDE support that is stable and reliable. Stable enough is not enough.
Frameworks like Spring, Hibernate, Wicket certainly help to simplify and accelerate web development as they provide a high degree of testability and integrate very well. But it's not enough to reach RoR productivity, even if you have a good set of development practices. There is still too much technical stuff and plumbing required.
Grails is maybe the missing piece in this picture to get closer to RoR. It's my next experimentation.
BTW, my MDA experiences are the contrary of a productivity improvement so I won't mention them (actually, MDA was killing our productivity).
Javarebel can greatly reduce time spent during web development using Java.
Let me quote here the official website:
JavaRebel is a JVM plugin (-javaagent) that enables you to see changes to your code immediately, without the need to redeploy an application or perform a container restart. If you're tired of watching the logs roll by, and want to see your changes so that you can keep going - JavaRebel is your new best friend.
One important point when discussing Java EE productivity: you should be using Java EE 5 and EJB3.x since they provide for new level of productivity (and functionality) compared to previous releases.
Staying within standard Java EE specs is absolutely important, e.g. using Hibernate instead of JPA is not beneficial to productivity. There is no limitation to fall back to Hibernate features when using JPA, but by using Hibernate instead of JPA you are locked in into single persistence provider with no cheap way out. The whole idea behind using standards is the same: conceptual flexibility (by plugging in different implementations) with available extensibility (by using proprietary extensions if absolutely necessary). Java EE 5 and EJB3 are huge steps in this direction. Of course, you want to minimize any proprietary features but if some seem absolutely necessary it's a good sign that they will be part of spec in next release...
Main obstacles to Java EE productivity are in its enterprise focus (offers a lot more than than needed for majority of projects) and in its legacy (backward compatibility). There is also a lot more to be done in presentation tier with JSF and state management - watch for JSR-299 to address these among other improvements.
Grails is a Java webapp framework very much modelled after Ruby on Rails, with similar principles (DRY, CoC) and productivity gains, but based on existing Java frameworks (Spring, Hibernate, several others).
I've been working on an exploratory project using Grails for a few weeks now (no previous experience in Grails or Groovy), and I'm quite impressed. There are a few rough edges - it's not as mature as RoR, but you can get results quickly and there's never the feeling that the framework is getting in your way.
Maybe it's best illustrated by this concrete example: I wanted to edit a 2D array of domain objects in a grid on a single webpage and found that the automatic mapping of the resulting HTML request data to the domain objects (provided by Spring MVC, I believe) had a bug that caused some data to be mapped to the wrong objects. I looked around on the web for an hour, but apparently nobody had encountered or solved the problem. Eventually I decided to forego the automatic mapping and do it "manually" - and then found that it took me no more than about 10 lines of code...
It's often cited that RoR and similar frameworks based on dynamic languages are more productive environments, but I am really interested to know if there are hard data to back this up. This wouldn't be easy, as one should be made certain that she is not comparing apples with oranges. Things like type of project (web 2.0, enterprise application) and team size should be taken into consideration. However, for small projects it is more than evident that such frameworks are indeed far more productive than Java EE. So this is a short list of arguments used to support this and what you can do for them in the Java world.
Ruby is a more intuitive and concise language. You can do the same thing with much less code.
I don't think you can have the same thing in Java, unless of course you use a dynamic language that runs in the JVM (JRuby, Scala, Groovy). Otherwise, your IDE can help. In Jave an IDE is an essential tool and it will pay you back if you learn to use it well (code generation, snippets, refactoring). In fact there are many things you can do with a Java IDE that are simply impossible to do with a Ruby or Python IDE. Plus you have the benefits of a static typed language. It may take more time to type, but it helps you avoid common mistakes.
Ruby is much more fun to use. Makes the developer happier and more productive.
Same as above. Highly subjective argument in my opinion though.
Convention over configuration makes things faster
A dependency injection framework like Spring or Guice can help
Scaffolding, MVC already there for you.
Again Java MVC frameworks can help
Databases made easy. Load database items as objects. Can change the database on the fly.
Hibernate, iBatis or another ORM framework can help. With Hibernate Tools you can achieve similar functionality with what you have in RoR with yml files
Load new modules instantly
Maven or Ant Ivy can help
Easy deployment for testing
Your IDE or Jetty can help. In fact debugging is easier with Java
Testing integrated with the framework. Use of mock objects facilitate testing
A dependency injection framework can help with mock objects. JUnit was a pioneer of unit frameworks. I don't think that Java is less easy to test.
I would definitely go for Spring together with Hibernate for persistency related stuff.
Why Spring?
The advantage of using Spring instead of another framework is that Springs philosophy is to be "non-invasive". Usually when you're using a framework most probably you'll start to depend on that framework which can be a bad issue if the application is considered to run for a longer time where you then have also to do maintenance etc. Spring uses the so-called "Inversion of Control" (IoC) pattern. Basically your code doesn't (it can but it doesn't have to) call Spring, but Spring will call you (Hollywood principle: "don't call me, I'll call you"). So for instance you can use normal POJOs (Plain Old Java Objects) and you don't have to inherit from any framework-related classes/interfaces.
Another big problem (if not the biggest) in Software Engineering are dependencies. You'll fight for reducing them as much as possible since they will make your life harder (especially in maintenance later on). Spring reduces dependencies among your components drammatically by managing the instantiation of components through configuration files and the dependency injection pattern. I wouldn't want to go on, the best thing is that you start reading some tutorials at the official Spring website. Initially it may need some time in the understanding but once you got it you'll earn a lot of benefits.
Since Jython 2.5 you can use django to satisfy the requirements you listed. It's pretty easy to generate war files from django projects and deploy them on J2EE application servers.
Just wanted to pitch in another idea... you can actually use JRuby and Rails (similar to the previous comment about Django and Jython).
If you use JRuby with Rails and JRuby Rack (and maybe some other utilities... I wasn't the one to actually get the integration going initially), you can deploy JRuby Rails additions to an existing Java web app. We have a legacy JSP application deployed with Tomcat, and are now starting to add new pages using Rails with just that setup (in addition to extending the JSP side when necessary). So far it has been quite successful, though we don't have any of the major high traffic pages implemented in Rails, so I don't know how well it will scale.
We have full access to the session, and have even set up mechanisms to invoke JSPs from Rails pages (such as existing header and footer type JSP includes). It takes some effort and trial and error to fully integrate the 2, but if Rails and JRuby is an option, I highly recommend it (as a personal fan of Ruby).
A colleague has dabbled in JBoss Seam, which is a framework by Gavin King (the guy who brought us Hibernate), which was meant to emulate Rails. Having seen both, I feel Rails is a lot easier to develop with.
Use AOP (Aspect Oriented Programming) for cross cutting aspects like logging, authorization etc. You can either use Spring AOP or AspectJ. It makes code clutter free and maintainable.
I've used Jboss Seam for the past couple of years and find it to be very productive way to develop in Java EE (utilising EJB3, Hibernate, Facelets). I also do the odd bit of PHP coding on the side and can honestly say that I'm more productive with Seam (although that's probably also an indication of my PHP skills.)
For me a couple of the highlights would be:
Hot deploy of code (an absolute must-have)
DRY with Facelets
Annotation based configuration
Extensive drop-in components (especially ajax4jsf)
IDE Support from Jboss Tools
There are tools in the IDE and from the command line to build skeleton code in a similar way to RoR.
Well, I'm not really a Java guy, so I can't say much, except for... JSF
We tried to use it for some time and it was a disaster. Almots all basics steps had to be passed with lots of pain, no documentation, no examples, no community knowledge. We used then one plugin for Eclipse (Exadel Studio), we had a look at a few other JSF frameworks, they were all incompatible and poorly documented. As a matter of fact, of all those we tried, only Sun framework (forgot its name, based on NetBeans) could create a new JSF project even compilable out of the box. The rest required many days of configuration of apache and other things, which for an unexperienced person is a real challenge (though I managed it).
Our team spent a few months on something which was done later in just a few weeks with ASP.NET. People were both inexperienced in JSF and ASP.NET.
If JSF ecosystem is still that bad as it was in 2007, I would recommend avoiding it altogether, productivity is out of the question anyway. Maybe stick with JSP or something that is time-proved and well developed?
I would go with the Lift framework written in Scala. You will see a great productivity boost just by switching to Scala. Scala is also very stable and it's extremely easy to call Java code from your Scala code. Not only that but it's quite similar to Java but with some added features. For some examples you should refer to 5 Things a Java developer needs to know about Scala. Twitter will move part of it's codebase to Scala.
You will never "get stuck" on a piece of code because you can just think about how you would do it in Java and write similar code. First class functions and actors will give you an even greater productivity boost and are both in Scala. Scala is of course statically typed and has a performance that is similar to Java.
I will quote the author of the Lift framework for an description of it:
Lift borrows from the best of existing
frameworks, providing
Seaside's highly granular sessions and security Rails fast flash-to-bang
Django's "more than just CRUD is included"
Wicket's designer-friendly templating style (see Lift View
First)
And because Lift applications are
written in Scala, an elegant new JVM
language, you can still use your
favorite Java libraries and deploy to
your favorite Servlet Container. Use
the code you've already written and
deploy to the container you've already
configured!
Some basic rules:
Kick out the appserver - a HUGE win in turnaround and quality. Keep a web container if you have to, but configure everything in Spring and/or Hibernate so the web.xml is minimal.
Test everything, which you can now do because of step 1 (no deploy-time XMLs or code generation needed: everything is configured in the development already).
Use Wicket to implement your web tier - nobody needs JSP any more; Wicket is 10 times more productive plus easy to test (see step 2).
Use SCRUM and agile development methodologies
The result is Java productivity as high as 4GLs allow - we at Atomikos have several migration projects we did like this. Because we migrated from 4GL platforms to Java/Java EE, we could compare the estimates in both.
Also see this blog post: http://blog.atomikos.com/?p=87
HTH
Guy

Categories

Resources