Develop Reference

How to write a unit test framework?

How to write a unit test framework?
Can anyone suggest some good reading?
I wish to work on basic building blocks that we use as programmers, so I am thinking of working on developing a unit test framework for Java.
I don't intend to write a framework that will replace junit;
my intention is to gain some experience by doing a worthy project.

There are several books that describe how to build a unit test framework. One of those is Test-Driven Development: By Example (TDD) by Kent Beck. Another book you might look at is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros.
Why do you want to build your own unit test framework?
Which ones have you tried and what did you find that was missing?
If (as your comments suggest) your objective is to learn about the factors that go into making a good unit test framework by doing it yourself, then chapters 18-24 (Part II: The xUnit Example) of the TDD book show how it can be done in Python. Adapting that to Java would probably teach you quite a lot about Python, unit testing frameworks and possibly Java too.
It will still be valuable to you to have some experience with some unit test framework so that you can compare what you produce with what others have produced. Who knows, you might have some fundamental insight that they've missed and you may improve things for everyone. (It isn't very likely, I'm sorry to say, but it is possible.)
Note that the TDD people are quite adamant that TDD does not work well with databases. That is a nuisance to me as my work is centred on DBMS development; it means I have to adapt the techniques usually espoused in the literature to accommodate the realities of 'testing whether the DBMS works does mean testing against a DBMS'. I believe that the primary reason for their concern is that setting up a database to a known state takes time, and therefore makes testing slower. I can understand that concern - it is a practical problem.

Basically, it consists of three parts:
preparing set of tests
running tests
making reports
Preparing set of tests means that your framework should collect all tests which you want to run. You can specify these tests (usually classes with test methods which satisfy some convention or marked with certain annotation or implement marker interface) in a separate file (java or xml), or you can find them dynamically (making a search over classpath).
If you choose the dynamic searching, then you'll probably have to use some libraries which can analyse java bytecode. Otherwise you'll have to load all the classes in your classpath, and this a) requires much time and b) will execute all static initializers of loaded classes and can cause unexpected tests results.
Running tests can vary significantly depending on features of your framework. The simplest way is just calling test methods inside a try/catch block, analysing and saving results (you have to analyze 2 situations - when the assertion exception was thrown and when it was not thrown).
Making reports is all about printing analyzed results in xml/html/wiki or whatever else format.

The Cook's Tour is written by Kent Beck (I believe; it's not attributed), and describes the thought process that went into writing JUnit. I would suggest reading it and considering how you might choose an alternate line of development.

Java development standards and tools (compared to C#)

I don't have any knowledge of Java platform and I wonder which tools (and methodologies) could be used to help developing maintainable code written in Java.
I know one can use:
Agile methodology in any environment
jUnit/jMock for unit testing code (similar to NUnit/Moq in .net world)
Checkstyle for coding standards - is this similar to StyleCop or FxCop or both?
I suppose you can also write layered applications in Java (like assemblies for different tiers in .net)
Are there any automated testing OSS/Licensed tools that are worth mentioning
Are there any code generators that are very popular in Java world
Are there also any other popular tools/methods that a Java developer/team can use that I don't have access to in .net world? Would you suggest other tools and approaches in Java world?

In java there are a lot of frameworks. For example, you don't have to use JUnit, you could use TestNG with basically just as much tool support. There are several mocking frameworks as well.
In terms of coding standards, IDEs come with that built in, as well as there being several others available (I'm most familiar with the IDE ones, so I don't know names off hand).
You have Eclipse as an IDE if you want free, as well as NetBeans and for money there is IntelliJ IDEA among others. Then there are some IDEs from big vendors intended to support their specific application servers.
In terms of building "assemblies" (jars, wars and ears in the java world), there are some built in tools in IDEs for one-man projects, and there is Ant or Maven for a full fledged build tool.
There are many options in automated testing tools. If you mean continuous integration, there is CruiseControl that is free, and TeamCity which has no cost for low usage.
In terms of code generators, in general the Java world is kind of trying to move away from them in favor of annotations, but the name that comes to mind is xdoclet. In GUI building there are a bunch of code generators strictly for building the GUI of course.
That really barely scratches the surface. For example, application servers (JBoss, Oracle (they now own two with the Sun purchase) and IBM among others) are a big decision point in many Java projects (it depends what kind of project).
None of the categories discussed are intended to be exhaustive, just enough to give you a jumping point of what to look into. There are many more in each category.
The great thing about Java is that there are so many choices. The bad thing about Java is that there are so many choices ...

Responding to #2: Code coverage tools like EMMA are often used to evaluate the extent of current tests.
Responding to #5: Findbugs and PMD are extremely popular static analysis tools.

You can use Hudson together with ant or maven as an continuous integration server. Testing your code at specific times and after each checkin. You can combinte Hudson with JUnit, Emma, FindBugs, Pmd and checkstyle to measure the quality of the code in your repository. If you are doing this I recommend installing the continuous integration game giving your developer a high score for fixing tests and warnigns, and negative points for breaking them.

The best tool for Java development is great Java programmers.
If you manage to hire a few that are really good, the rest will take care of itself :)

I'm not convinced that any one set of tools/methodologies/processes will guarantee you get maintaniable code at the end of it. So much of this comes down to the programmers who develop the project. Are they craftsmen/women committed to producing excellent code or just code-cutters aiming to get the job done. Looking at it another way, it's possible to have great processes in place and still produce poor code. And great programmers can produce maintainable code despite poor processess/tools or the lack of them.
That said, I'd still insist on the basics: source code control, branching for each change with regular check-ins to the main branch, automated build and test, lots of test code, basic static analysis, bug tracking and so on. That's on the tool side. On the coding side, regular design and code reviews, n-tiered architecture, loose coupling, etc. Most of this is language independent. So what's been working for you in C# should translate to Java.
For Java, I've found JUnit very good for test code and Checkstyle pretty good for maintaining a coding style.

Making life better by not using Java web frameworks? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm so tired of having to learn yet another Java web framework every other day.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC to name just a few - all this countless frameworks out there try to address the same issues. However, none of them really solves the fundamental problems - that's why there are still coming up more and more new ones all the time.
Most do look very bright and shiny on the first impression because they simplify doing simple things.
But as soon as it comes to the implementation of a real world use case one is running into problems.
Often the frameworks don't provide any help but are hindering one and limiting the options by forcing things to be implemented according to the frameworks own logic and environment.
In short, I see the following disadvantages when using a framework:
There mostly is a steep learning curve and you first need to understand sometimes quite academic concepts and know meaning and location of a bunch of configuration files before you can get started.
The documentation usually is more or less awful, either missing a public accessible online reference, is helpless outdated, confuses different incompatible versions or all of this together and often doesn't provide any helpful examples.
The framework consist of zillions of classes which makes it practically impossible to understand the intended use only by browsing the sources.
Therefore you need to buy some "XYZ in action for dummies in 21 days" kind of books which have a bad user interface because they are missing a full text search and are heavy to carry around.
To really use one of this frameworks you need to learn by heart how things can be done the way the framework requires it by remembering the adequate classes and method names until your head is full of stupid and useless information you can't use for anything else.
There is a big overhead, slowing down your applications performance and making your brain feeling numb when try to understand what really is going on.
In the real world there is usually no time to get well familiar with something new because of the pressure of being productive. As a consequence of this learning by doing approach one always looks only for the fastest way to get the next task done rather than really understanding the new tool and it's possibilities.
The argument that following a standard would allow people who are new to a project to quickly get started is not valid in my view because every project uses a different framework even within the same company (at least in my case).
It seems to me that the following quote from Albert Einstein fits here very well:
“We can't solve problems by using the same kind of thinking we used when we created them.”
Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next.
This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules.
This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.
While perfectly adjusted to the requirements of the current project, it also was easy expandable and had a very high performance due to zero overhead.
So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
What should I say to my boss when we're starting tomorrow the next project with a new framework again?
Or are there maybe frameworks which really make a difference?
Or some hidden advantages I have ignored?

Back in my good old PHP coding days
when coding still was fun and
productive, I used to write my own
frameworks for most things and just
copy-pasted and adopted them from one
project to the next. This approach
paid out very well, resulting in fast
development, no overhead at all and a
framework which actually was mightier
than most Java frameworks out there
Forgive me for believing that not one second.
but with only a few hundred lines of
code in a single file plus some simple
mod_rewrite rules. This certainly
wasn't solving all problems of web
development, but it was simple, fast
and straight to the point.
So basically you developed your own framework over the course of months or years, tailored to your own needs, and could work very fast with it because you knew it intimately.
And yet you can't understand why others do the same and then try to turn the result into something useable by everyone?
Where's this great framework you developed? If it's so powerful and easy to use, where are the dedicated communities, thousands of users and hundreds of sites developed with it?
every project uses a different
framework even within the same company
(at least in my case)
Well, that's your problem right there. Why would you throw away the expertise gained with each framework after each project?
The idea is to choose one framework and stick with it over multiple projects so that you get proficient in it. You have to invest some time to learn the framework, and then it saves you time by allowing you to work on a higher level.

The problem with coming up with your own framework is that you will make all of the same mistakes that all of the established frameworks have already stumbled on and addressed. This is true particularly when it comes to security.
Just ask Jeff and the guys about what they had to consider when implementing the WMD in stack overflow. I'd rather use what they have produced in a project rather than implement it from scratch. That is just one example.

Here is a quote from Kev from the thread What’s your most controversial programming opinion? which fit's in here really well:
I think that the whole "Enterprise" frameworks thing is smoke and mirrors. J2EE, .NET, the majority of the Apache frameworks and most abstractions to manage such things create far more complexity than they solve.
Take any regular Java or .NET OMR, or any supposedly modern MVC framework for either which does "magic" to solve tedious, simple tasks. You end up writing huge amounts of ugly XML boilerplate that is difficult to validate and write quickly. You have massive APIs where half of those are just to integrate the work of the other APIs, interfaces that are impossible to recycle, and abstract classes that are needed only to overcome the inflexibility of Java and C#. We simply don't need most of that.
How about all the different application servers with their own darned descriptor syntax, the overly complex database and groupware products?
The point of this is not that complexity==bad, it's that unnecessary complexity==bad. I've worked in massive enterprise installations where some of it was necessary, but even in most cases a few home-grown scripts and a simple web frontend is all that's needed to solve most use cases.
I'd try to replace all of these enterprisey apps with simple web frameworks, open source DBs, and trivial programming constructs.

The problem is of course not just with Java frameworks. I've lost count of the number of C++ MFC projects I've seen floundering around trying to shoe-horn their requirements into the Document/View model (which really only workks for text and graphic editors - database applications are particularly difficult to shoehorn).
The secret of succesful framework use is to change your application to match the framework, not the other way around. If you can't do that, don't even think of using the framework - it will end up being more work than if you had written the app from scratch with the help of some good, reliable and well-documented utility libraries.

So are you saying we should deal in sockets and HTTP every time we want to build a web application!
The servlet container itself can be considered a framework, since it handles all these messy details, and leaves you to write much simpler Servlets/Filters/Listeners (ie: 'extensions' of the framework specific to your application).
All any framework tries to do is separate mundane, repeatable, error-prone, legwork code from the fun application-specific code.
However, for a small application, you can get away with simply having a Model 2 MVC approach which uses only JSPs and Servlets.
Example:
class MyController extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
MyBean model = // do something
request.setAttribute("model", model);
request.getRequestDispatcher("/view.jsp").forward(request, response);
}
}
Then as your app becomes more sophisticated, you could look at using Spring MVC to provide looser coupling (and hence more flexible) of controllers, view resolvers etc..

I share your pain when confronted with yet another framework that doesn't do the trick.
Having survived ten years of jsp, struts, EJB, EJB2, struts2, jsf and now more recently all the new web services framworks, the xslt horrors and wsdl-first nightmares, I am definitely fed up.
There is a number of problems with frameworks. They leak so you have to learn more -not less, inhouse frameworks have huge costs, using external frameworks costs too (but much less), as they seldom deliver, and then you end up writing enourmus chunks of xml-configuration and spend days correcting case and spelling errors that you had seen immediately in your favorite content helping code editor.
Maybe the answer is to find less pompous toolkits that tries to solve a problem but not redefine the world, but that is hard too as the fundamental application model (html over http) is awkward - at best.
Add the fact that there seems to be a lot of complicators around, people that seems to be obsessed of trading boring simple problems to complex (but hard) interresting problems ( maybe a variant of Eric Sink’s Axiom of Software Development mentioned above.)
Add the hubris of developers that knows it all and do not hesitate to write a new framework to solve all the hard problems for you, Only that they can't, leaving 10% left, only much harder to fix now.
I have no .NET experience, but the .NET world seems to be less crowded with theorists and complicators, and maybe the lingering stink of VB is scaring them off, but everytime I hear someone telling me that they have spent 1500 hours on their maven config (hello?), I am seriously considering deleting "java" from my resume.
...what was the question again? Are there any frameworks that make a difference?
EDIT - added Stripes and QueryDSL.
I would try Stripes or GWT with QueryDSL + Hibernate or OpenJPA (with annotations) just for the fact that you actually develop in Java, and try to limit the use of wsdl-first web-services, xml-centric frameworks, EJB and ESBs (not the beer) as much as possible.

I once had to work on a project trying to implement it in JSF. It was a nightmare.
Most of the working time was spent to just making things compile. The fact that no less than half of what was compiled didn't work was another story. Almost no tutorials. Documentation is basically an automated source code export with no human comments. How can one be expected to work like this?
Of several frameworks we'd seen only Sun's was able to create a new project that is compilable at all! The other could only produce bunch of stuff it took many days to ring to a compilable state.
The web was almost silent. To any search there we no more than 20 pages of search results, with useful first 1-3. In that relevant what was found, a half of people was crying for help, the other half declared they had cried for help, noone came, they lost time and interest and dropped that technology.
So we spent times and only made something simple that could have been done in a few weeks with ASP.NET for example.
Then we looked at alternative JSF frameworks. To our surprise we found them all quite incompatible.
With not surprise at all, we joined the ranks of those who dropped JSF as well.

Consider the counter point. I am working at a shop right now that doesn't use any frameworks beyond the JSP standard. Everyone has a different way of doing things and we are very lax about concepts like de-coupling and security concerns like validation.
While I don't think use of frameworks automatically makes you a better coder, I do think by using a standard design pattern implemented by most frameworks and by having easy access to utility functions like validation, I think the chances are you are going to be forced to code up to a certain standard.
In web application design you aren't inventing the wheel every time, so you either end up rolling your own solution to common tasks, or using a framework. I make the assumption that by using a commonly used framework rather then roll your own, you are going to get underlying code that is well tested and flexible.
There is nothing wrong with rolling your own solution as an academic pursuit but I accept that there are people out there putting a lot more time into a robust solution then I may be able to spend. Take log4j for example, pretty easy to roll your logger, but log4j is well tested and maintained and they have taken the time to improve on flexibility and performance to a degree that most roll your own loggers can't touch. The end result is a framework that is robust but also simple enough to use in even the most basic applications.

What worked for me is: you shouldn't just learn any web framework you hear about, take a look at it, see if it makes you code comfortably, ask around stackoverflow or forums to see its advantages and disadvantages, then learn it and learn it good and just stick with it until you feel its broken or plain outdated. Any of the webframeworks you wrote about is good by itself and a fun to work with if you "REALLY" know what it does. if you don't you are just wandering in a desert with no compass! I've also found the 21 days book is a sure way for you NOT to master a framework or a technology. Docs is surely something to consider while adopting a f/w it also helps if you look around the code yourself (actually this is what helps me the best when I faced with some behavior that I find wierd.
1-So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
if you go back to the roots you rewrite code that does the same thing again and again + most of these f/ws being open source means they are probably better off with maintenance than you would do alone to your own f/w.
2-What should I say to my boss when we're starting tomorrow the next project with a new framework again?
this is my first time working with this f/w I don't see why should we use this f/w I already know X and I am really good at it. bare in mind the cost of me learning this f/w, the cost of rework that has to be done due to my ignorance of such a f/w. I think we are better off using X, if this is a specific requirement we should fight for it and only do it if we really have to stating the previous notes.
Or are there maybe frameworks which really make a difference?
only those who address the way you think not the way you write code (think struts at its golden age enforcing the MVC pattern).
Or some hidden advantages I have ignored?
can't think of any tbh.

You have the same problem in PHP: more frameworks than you have fingers to count them on, each being the best and greatest (although you have some hints: pure PHP5 design vs. PHP4 compatibility, Rails philosophy (inflexible folder hierarchy, auto-generated code) vs. library approach...) and you spend more time searching and exploring the possibilities than writing your code!
But in PHP it allows to pre-solve common problems, like I18N support, integration of plugins, management of sessions and authentication, database abstraction, templates, Ajax support, etc. Avoiding to re-invent the wheel on each project, and to fall in common traps for newbies.
Of course, there are some hints for Java frameworks too: big or small? well documented or not? widely used or confidential? for XML fans or not? Etc.
I suppose most frameworks aim at large projects, where learning time isn't a big problem, scalability and ease of deployment are important, etc. They are probably overkill for small projects.
There is also a trend in such frameworks to aim at doing a consistent set of loosely coupled libraries rather a monolithic framework. That's the case, in the PHP world, for the Zend framework (some even deny the usage of word 'framework'...).
So it solves the issue of "resolving common problems" without getting in the way.

So you think it's better if we all invent the wheel in every project?
You might see an excess of frameworks as a problem, and it does make it harder to choose your own set. But on the other hand, you don't have to try each one; and even if you do, you'll end up preferring some of them. You will have a favorite framework for ORM, another for web development, IoC, etc.
It does help to read up on some forums to learn which are the most popular ones; they must be popular for a reason, and even if it's not the right reason (like being technically superior, maybe it's popular just among managers because of the buzzword overload or whatever), knowledge of said framework will be helpful because you will be able to participate in several projects that use it.
Plus, using a framework instead of writing your own will save you a lot of problems. Bugs are not always found and solved by the authors; that's often done by users of the framework. You said you ended up with your own private framework in PHP; I bet it wasn't bug-free, but maybe you didn't know it since you were the only user and the only coder.

However I disagree on some points that you have mentioned but I agree with you regarding the boring work.
Yes all web applications are about pages displaying forms, collecting data, making validation, sending the data for storage in Database, and filtering the stored data by search forms and displaying the result in tables and selecting one or more records for manipulation (CRUD, or business actions that all about changing status in database).
however I'm working for just 4 years plus of course my 4 years academic study.
I feel this type of development is boring as you are not inventing algorithms, off course you got happy when you discover new framework and will be happier if you integrated one of the AI engines into your application, but at the end I feel that this work is dummy works, or lets say machine work, so why we don't automate all of this stuff.
yes another framework ;)
MDA Model Driven Architecture, in brief is about transforming from PIM (Platform Independent Model) to PSM (Platform Specific Model), i.e for example from UML to Code.
And this may solves your problem of learning curve and technology changes as you will only need to be good at modeling, as there are some frameworks that implements the MDA specs such as AndroMDA as it have cartridges that take the Class Diagrams, Use cases, Sequence Diagrams, and Activity Diagrams and generate Database creation script, POJOs, hibernate mapping, Spring/EJB, JSF/Struts, .NET code.
Off course such frameworks will not generate 100% of the code but will generate a big percent, and off course you will ask whither this framework will solve complex and tricky scenarios of requirements? today I will say no, tomorrow yes.
so why you and I don't invest in the development of this great framework.

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

Is Grails worth it? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is half rant, half question.
Is it worth using Grails? I'm trying to develop a relatively simple database-driven web application. My expertise is in Java, so naturally Grails seemed like a good choice. At first I thought of using Spring, JPA and Hibernate, but I’ve used that previously and have run into all sorts of tedious configuration and coding work. Grails advertises itself as solving this.
My biggest frustration with Grails is all of the little things that don't work. What I mean is that it doesn't work as one would intuitively think it should. It's very rough around the edges. I run into problems constantly. Sometimes it's my lack of Grails understanding — other times I've discovered legitimate Grails bugs.
One major issue is the lack of good Eclipse integration. There is a Groovy and Grails plugin, but it doesn't do much other than syntax highlighting. Calling Groovy from Java and vice versa is very painful to configure. Not having good IDE support is a major bummer.
What happens is I sit down trying to develop my web application. At the end of the day I realize that I've spent about 85% of the day debugging Grails-related issues. If it isn't Eclipse problems then it's eager loading, fetching in the view, one-to-many relationships, weird empty file bug behavior, a weird property/getter bug — it just goes on and on. This is just a sample of the issues I ran into today. My last sit-down with Grails yielded a whole bunch of different issues.
I sometimes wonder if it's worth it. I'm curious if others have experienced this. Are there people actually using Grails to productively crank out a web application? Are there other frameworks for rapid web development that I should be considering?

We had a team of 12 people all seasoned senior Java devs who learnt Grails from 0.6B and we are all still working on projects based on Grails. I wouldn't go back to Java willingly, and we are all relieved to have broken the back of how to get somewhere quick with a Grails app.
It was a struggle, it was not easy and there was/is frustration.
Nevertheless we delivered something very quickly given our ongoing efforts.. There are bugs, many which have workarounds.
I have heard of several instances of developers who are good at Java trying to dive into deep, complex incantations of Grails projects. We eschewed all Java and went pure-Grails and Groovy. We made sure we started simple, built up the complexity as manageably and as practically as possible.. We dared not dive in the deepest end and hope that our Java knowledge was enough to carry us.
We had eventually created something huge and complex that worked fabulously and did so far faster than writing pure Java/Spring/Hibernate version; and thats without decent IDE support and a far worse situation in terms of bugs than today.
As regards Eclipse support, the only real IDE to use for Grails/Groovy is Intellij - the Eclipse support is way behind, sadly: I was an Eclipse lover and am far from being an Intellij convert - the Grails/Groovy support blow everything else away though.
Yes, Grails is immature compared to Spring perhaps. Or Hibernate. And I would wager that in the first 1.5 years of their existence they were equally as fraught with issue.
That being as it is, places the onus on you, to take care that you keep complexity to the absolute minimum, to carefully test-first (in our opinion) and build up to complexity gradually and with care.
There is no fast code solution with Java once you involve Spring/Hibernate in the stack. The complexity Grails embodies is a reflection of Spring's / Hibernate's own complexity. If you feel that you time is better spent doing it with pure Java, I wouldn't argue otherwise.. I still have my WTFs but now that the steep learning curve is behind me I think I will stick w Grails some more.

I very much enjoy writing grails application for two reasons:
I don't have to use Java
I can use Java
I think after having become familiar with grails one gets his things done very quickly and elegantly.
So much for the plus side. The minus side is performance, which hits me on two aspects: deployment and testdriven development.
I haven't managed to run more than 3 grails applications on a single (rented) server, because I quickly hit the memory and performance limits. There are simply too much frameworks included.
Plus, the testrunner of grails isn't worth that name. When I run unit tests, they should be done in an instant, not in 10 to 20s. So I find myself all the time writing business logic in plain java, because I can test it much faster. But I guess that this can be addressed with a better integration into the IDE (eclipse).

I think Spring's support of Grails is going to be a big boost. If anybody can move it past CRUD on the web, it's those guys.
I also think it's reaching a critical mass. There are several new books that will be hitting the market in 2009. I think those will help the adoption rate.

I fully agree with the original posters sentiments.
We are a Java + Spring shop and took the opportunity to try out Grails.
We first created a very small test application which turned out to be pretty simple to do and it worked pretty well. The main issues we had here were due to our lack of knowledge with Groovy and Grails.
Following this success (confidence boost) we decided we would attempt a slightly larger project. This has been a much more painful experience. As mentioned by others, we have uncovered all sorts of bugs and issues which were not immediately apparent on the surface. The app restart cycles get extremely painful and unless you have really good test coverage its a nightmare to do any sort of re-factoring.
Really frustrating is having code fail without a single error message! It just does not work and you don't know why?
I like the ease of use of plugins for JMS, Quartz and Remoting to name a few. Does away with a lot of tedious XML.
I almost like GORM for its simplicity though we have had several issues as well.
I don't like the loosely typed nature of Groovy and the fact that you have to run your application just to be able to catch a bunch of errors, reminds me too much of PHP or Rails.
At the end of the day we are asking ourselves if its possible to write a complex piece of manageable software using Grails...
We have a Grails application about to go into production....so we will see.

We are using grails + on the web layer + java with hibernate and spring on the service layer. It's the classic three layers (web, logic, data) where the web is grails and the logic is implemented in java. As is usual in java, we use bean objects that represents the data between different layers.
It works pretty well and it was the best solution for our case as the bean objects were already there, as well as the database structure. From our experience, I think grails has a great value as the web presentation layer, but I would stick with java to write the business rules and to persist the application data - as grails "is" java, all the grails-java integration is pretty straight-forward.
We use eclipse to develop the grails application and it's poor integration, as people said in here. But, as a suggestion from other developer, we run the grails application from the command-line and only use eclipse to save the source files, and it works pretty well, as the application is updated on the fly.
I yet don't feel comfortable for using grails in other places than in the presentation layer.

I have a lot more experience with Ruby on Rails than I do with anything in the Java world, so I'm coming in from a different perspective. Overall, Grails is much more rough-around-the-edges than Rails is, partially due to its immaturity, and partially because it relies on two insanely complex frameworks under-the-covers (Spring and Hibernate). Rails also has a much bigger community.
But, Groovy as a language has made huge strides, and is a pleasure to work with. Thanks to the improvements made in Groovy 1.6, Grails is quite a bit snappier than JRuby on Rails, and you get amazingly good XML support via GPath. There's a lot of nice features you get by being on the JVM (like concurrency and tons of threadsafe code), but without having to muck about with Java (a language I don't much care for), so I'm having a really hard time of convincing myself to use anything on MRI.
Python is looking tempting, though, I must admit.
As for your Eclipse problems, I can't help. I use Vim and Emacs, mostly because I can't stand using IDEs. For dynamic languages like Groovy, Ruby, and Python, though, I don't think IDEs really introduce any real benefit, as there isn't really any place for code generation, or a need to compile. Maybe try working sans IDE for awhile and see if things are smoother?
So, yeah, I think Grails is worth it. They've done a helluva job in getting things working as quickly as they have, and the Grails and Groovy teams are both really, really dedicated.

I am totally with you! Grails still feels so rough around the edges that it's almost a joke to compare it with Rails. If at least the error reporting was a little bit better. But I guess that's probably also due to the huge amount of libraries that it uses under the covers. One word: stacktrace! I am also not a big fan of the model->db approach (Rails has db->model). The scaffolding also leaves much room for improvements. Then "no restart required" also does not work as advertised. (I am not sure what's worse - having to restart all the time or sometimes finding weird behaviors that go away when you do restart) And don't get me started on GORM. (When it takes hours to find a way what would have been a simple SQL you start to wonder whether this whole ORM really saves you time) Maybe as long as it is simple.
I mean: it's still one of the better choices of a framework when you are coming from the java world. (So much useless crap out there that calls itself a web framework) ...it has potential. I just wish it wouldn't have build on top of so much other complex stuff.
Anyway - let's hope these things get sorted. At the moment I am lurking at playframework.org which also looks very slick and promising.

It will be worth it when they finish the eclipse plugin. The sooner the better I say. Trying to sell groovy to my boss isn't going to be simple until that happens.

I find that the biggest advantage of Grails is that I don't have to care about the database anymore - the schema is automatically created / updated, and the persistence is largely done for me (no more writing SQL queries). This is a huge relief. The other thing that is rather nice is that once you settled on the templates for controllers and views, adding new domain objects is pretty fast. Although I suspect that you will do ongoing changes for your views at least, back-fitting them to the existing ones.
As for the IDE - it seems that IntelliJ is the best option, but I'm happy using Netbeans 6.5. I use MyEclipse for all other development, but Netbeans just has better Grails support now.

I was an Eclipse user before I started using Grails. It was quickly apparent that wasn't going to cut it. So I tried Intellij and NetBeans. At the time Intellij was better as far as Groovy and Grails were concerned. However, NetBeans was free and that made it good enough for me. Since then all three have had new versions or new plugins released. I am still using NetBeans because of the cost of Intellij. With the acquisition of G2One by Spring Source one of the expectations is more support for Groovy and Grails in Eclipse. This will be necessary for increased adoption.
Using Grails for a new project is wonderful. So much of the Enterprise Java baggage is no longer necessary. I can imagine trying to port something would be difficult because until you understand where a framework strength's and weaknesses are it is hard to utilize it efficiently. It is promised that JSP support will come easier in Grails 1.1, I don't know if using a beta version while trying to grok a new framework is a good idea. The testing has also gone through a major revision for the new version. If time allows you may consider waiting as the 1.1 release should be very soon.
If you have an opportunity to give Grails a try in a different IDE when starting a project from scratch I think you will see it in a different light.

I have just started using grails on a new project...not having to write ANY xml files yet still have the power of Spring and Hibernate is truly amazing.
Use IntellijIDEA for the IDE though, I actually discovered Grails through the IDE (I might be biased though, I hate eclipse).

Totally. There are so many Java frameworks that the bar is set quite high for newcomers, and it's a testament to Grails that it was able to rise above in such a crowded space.
It still has a few edges that are sharp, but those are just a matter of time before they're matted down, the underlying project is VERY much worth it.

Grails might be to big for your type of application (based on the numerous files it created on the first initialization and the resources it takes). If you're looking for something simple, Grails might not be what you're looking for. If you are looking for something simple and works, so far I reckon django can do your job well. Take a look at how simple (how many files it requires) to create a CRUD apps from its tutorial. From here, your apps can (relatively) easy to scale as your needs and requirements grows.

I'm not sure they will ever be able to make Grails right you know. And by right I mean address all the details (small and big ones) which in the end makes it feel brittle and fragile. I'm not even sure that there is a real development team (meaning more than 2 people) behind it.
Every single time I iterate over a feature of my Grails projects, trying to improve something, it is the same workflow: everything falls apart, then it's a hundred of 'google' test cycles, then you find out the reason you can't do what you want and you do something else.
In the end, you're frustrated because you don't even want to touch anything that runs. And things that don't well, you drop them!
I'm considering a switch to Rails via JRuby. That may be the best of both worlds: a capable web framework with an active and large community, a dedicated team of developers, a platform which is not based on questionable and complex frameworks like Spring or Hibernate, a quick and ambitious release cycle. And JRuby because frankly, so many Java assets in my backpack, I can't just throw them away.

If your expertise is in Java as you say. You should have a look at Play Framework - it's a web framework inspired by Ruby on Rails with a very short development cycle - just save your Java source file and update your web browser. And if you want to try another language, Play Framework has a module that let you use Scala instead.
I like Play Framework since it's easy to understand and has good performance. You can also use JPA and Hibernate for the ORM-layer if you want.