Related
There are plenty of resources available to a Java developer for getting a jump-start into Ruby/Rails development. The reverse doesn't appear to be true.
What resources would you suggest for getting up-to-date on the current state of java technologies? How about learning how to approach DRY (don't repeat yourself) without the use of metaprogramming? Or how to approach various scenarios where a ruby developer is used to passing in a function (proc/lambda/block) as an argument (callbacks, etc)?
You might start out by learning Groovy and Grails, which may seem a bit more familiar to you. Then you can start learning more of the Java side of Groovy to get familiar with what Java can do. Eventually (if you need to) you can move into 100% Java.
Groovy is in many ways similar to Ruby (at least from my Ruby-novice view), but you also have full access to Java libraries and coding.
I guess you might also look into JRuby first rather than Groovy since it is a Java-based implementation of Ruby.
The best thing to do is consider what you would want to do with Java and try to dig deeper into that area. Java as a whole has gotten pretty unwieldy over that last few years.
Good luck and I hope this helps a little.
I wouldn't start with the "current state" of Java. Like #chstehno said, Java is huge, and a bit of a mess. Focus on learning the basics, then delve in the the libraries as they become relevant to what you're working on.
I went from Java (and a bunch of other old school languages) to Ruby, so I can't speak to going the other way, except to say that Java is a lot more "by the book" and you can figure out a lot just by reading and searching through code, whereas that can be tough in Ruby with all of the mixins, lambdas, and convention-based magic in frameworks like Rails.
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.
I've been building web sites off an on for about 10 years. 2 years ago I started using ASP.Net. I'm working on 2 projects right now, one using ASP.Net MVC and the other using Java / JSF / Spring / Hibernate.
I've also used other frameworks (cgi/perl, php, ASP, jsp, jsf).
What do you think is the most productive programming environment for building web applications?
I have not used other frameworks such as Ruby on Rails, Glass Fish, etc. Are there any frameworks that I might be missing and should look at?
I'd really be interested in hearing opinions from someone with Ruby on Rails experience.
I find it's less about the particular language or environment but rather how comfortable you are with it yourself as a programmer - the more time you spend with a language, the more you become efficient.
You can give me a hammer, and I probably couldn't build a house with it. But put the hammer in the hands of someone who knows what they're doing, and they'll make something beautiful with it.
Frankly, it depends on your familiarity with the environment. RoR/Django certainly can improve development time, but if you know ASP very well, it may not be worth the effort (plus, you're giving up the visual designer, if you use it). Lots less boilerplate and more "magic" in Django/Rails.
It's also worth noting that you're going to end up handing off more direct control of the database to an ORM to do things the "Rails Way", assuming you're comfortable with that.
As a long time rails developer it gets my vote. But I think the important factor being the MVC foundation. It really allows the skeleton to be really setup and you just flush out the logic. My clients are constantly impressed how quickly I can add or change things.
The most productive environment is always going to be the one you know the best. I've been doing java development almost exclusively for the past 10ish years, so just about anything I want to write I default to java (unless there is a clear advantage to using something else) and I am very productive with that.
There is another question in there though: What is the best web programing language? Without getting into a techo-ligious debate of language 1 over language 2, it is part and parcel to productivity & efficiency of development. I am a very productive java developer but if the tools aren't right for the job it doesn't really matter. My most productive language may not be the most efficient. If I write 500 lines of java code in 2 hours to solve a problem, that is pretty damn productive. But if I achieve the same result with 5 lines of Wonder-Language++ in 10 minutes, that is efficient.
Look at what you want: the goal.
Look at what you have: your tools
Consider how to get from A-B
If your experience mirrors my own you will realize that while some tools are very versatile there is no one Silver-Bullet of Development, not even on the web.
-Mel
I've used several languages and frameworks as well, from .Net (both MVC and Webforms), Classic ASP, RoR, Merb, and Django. As others stated above, your most productive will be the one you're most familiar with. However, I believe that constantly exploring other frameworks (and languages) will benefit you as a developer. It gives you a clearer picture of the strengths and shortfalls of the framework you may be using at the time and also may provide some insight into how to work better in any given framework.
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.
I'm trying to learn Java but it just seem like there are too many parts to put together.
You have JSP, Java EE, Java SE, Java ME etc....
I can get Netbeans to do basic but just taking a peek at spring framework it seem like a lot of work to get it to run in the ide from the numerous configuration .
I want to get into web programming and maybe mobile.
Any advice?
Another programming language?
Is java this complex or does it get easier?
Java as a language is certainly not too complicated. J2EE in its entirety is only just about feasible for a one-man team - but you rarely need the whole of J2EE.
It's perfectly reasonable for a one-man team to implement a medium-sized web application. I'm not saying one person could write GMail on their own, but you shouldn't be too scared of the technology stack - find the bits you actually need and concentrate on those. On the other hand, that in itself takes a fair amount of experience - I wouldn't really want to be starting off on an enterprise app (even a small one) on my own as a newcomer to Java.
Start small. Learn the core (the language, IO, collections) - and then start with small projects. Work out whether you want to be in mobile, desktop, server or whatever - don't try all of them simultaneously. Gradually you'll build up your experience.
It's not that Java-the-language is complex, it's that vast libraries and frameworks exist that can help you do your work. This is true for many programming languages. Look at CPAN for Perl, for example. What language to use depends in great part on what your goals are.
You can start simple and work your way up to larger and larger projects.
Java is by no means too complex for a one-man operation, but learning any form of full-formed web programming is a lot to learn when it's all new. If you were looking at .NET for the same purpose, there is a lot there too.
Unless you are doing huge-enterprise applications, ignore all of J2EE except for JSP and JMS and a very few other components. The lion's share of J2EE is only useful in the context of an enterprise application that needs to scale, and in fact can be harmful when used in smaller applications.
The frameworks such as Spring, Hibernate, Apache-*, Web Services, and so on help you do your job, but are yet more things to learn to do your job. There is a lot to learn.
Should you use Java? Well, quite a lot of development is done with LAMP (or WAMP): Linux (or Windows) + Apache-HTTPD + MySQL + PHP. With this, you don't need to worry about Java or .NET or any of those frameworks. LAMP/WAMP works very well for a wide class of applications.
Java and .NET on the server are (sort of) more appropriate for larger services, but once you are familiar with them, they work just fine for smaller services as well.
You have to decide what your exact goals are, then look at how people have implemented the kind of thing that you're looking at doing. This will help you figure out what technologies are the most necessary for the niches you're looking at going into.
Java -- the language -- is one of the simplest strongly typed languages in existence. Vastly simpler than C++ or even its close cousin C#, I would argue.
The standard APIs/libraries really are huge, but nobody learns the whole thing. You're suffering from the intimidation all beginners feel when they look at something that big and new, but this will pass as you just do stuff. First, you need to learn the standard utility stuff -- the collections in java.util, mostly -- and then, for basic web dev, probably next the JDBC library and Java Servlets and JSP. And that's it.
As an alternate tact here...
Another problem you will encounter in Java is Choice. You have a LOT of it in terms of frameworks and technologies etc.
My best advice is search around for about a day if you're so inclined to find what technologies attract you, or who's arguments sway you. Then, pick one. ANY one. Really, it doesn't matter, especially for a first project. They all have learning curves, they all have strengths and weaknesses, they all have fans and foes.
The key though, is once you have chosen, STICK WITH IT. You will inevitably stumble upon some problem, you will pose this problem to someone else, someplace else, and they will say "oh, you should have used QED instead of KnifeForkSpoon". And you will second guess yourself, go off and hear about the wonders of QED, and all of the kittens born under it and hungry children fed by it. If you succumb to that siren song of "greener grass", your project will flail. (Not fail, flail.)
Don't be wooed, don't fall for it. Just fix your problem and move on. At the end, and you're on a new project, THEN go and look for the more bestest greatness silver bullet.
As an aside, if I were just getting in to web programming today in Java, I would humbly offer this simple recipe:
JSP 2.0 with JSTL for markup and presentation
Stripes or Struts 2 for logic (note Struts 2 (TWO), Struts 1 is plain evil)
"raw" JDBC with a database pool for persistence
Tomcat or Glassfish for a container (tomcat more popular, GF easier to use out of the box)
Netbeans or Eclipse (NB is easier to use out of the box)
This uses the most fundamental, yet functional facilities for web apps in Java today, lots of applicability, and solves the major issues of a web app without covering them up with thick, impenetrable layers.
You will learn a lot using these "crude" tools.
You need to learn to pick your battles. Covering the whole J2EE is a massive task and, for most, unnecessary to begin with. I think a common mistake for beginner programmers is that they think they need to learn everything. You'll find your time much more productive if you focus on the core language constructs to begin with, and focus on either web or mobile programming.
You'll be extremely surprised (and pleased) at how much you can carry over from one area to the next. Once you know the language, the different libraries for different platforms are just tools...Stick with Java. It is a good language to learn.
Can I take "get into web programming" to mean that you're just learning web programming in general? If that's true, if you have the time you might consider setting Java aside temporarily and giving LAMP/WAMP a closer look as Eddie suggested. (Though I'd personally use Perl instead of PHP. PHP is sexier resume fodder and lets you do some very cool things on the front end, but in my experience, when it comes to writing server-side code Perl simply blows PHP's doors off. And I've heard that the HTML::Mason extension puts Perl on pretty even footing with PHP's front-end niftiness, but I haven't used it myself.)
I've made a living writing writing web apps in Java and web apps in Perl. I'm fond of both languages, but as a learning tool, I'd put Perl well ahead of Java. As you're finding out, Java's a bulky bastich. Part of that is, as others have mentioned, a function of Java being a mature language with a variety of extensions that are unlikely to apply to your immediate needs. But even stripped down, you'll still need to deal with quite a bit of overhead before you can even get your first "Hello World" web app to run. Comparatively, you'll get rolling much quicker with Perl.
(In fact, Java tends to be pretty verbose in general compared with other languages. That's not necessarily a bad thing; my one big complaint with Perl is you often encounter code that leverages various shortcuts and side effects to do an unholy ton of work in just a few lines. This code is often brilliant, elegant, compact, and utterly bloody unintelligible to a non-expert. Terseness is not a virtue for the poor idiot who has to modify code six months after it was written -- especially when you wind up being the poor idiot in question.)
And as a way of learning web programming, Java's sophistication can actually work against it. As a professional, I'm glad Java's web-based tools automagically take care of a lot of grunt work for me, like session management. But I didn't completely understand what it was doing until I was thrown into a Perl-only environment and had to deal with all that stuff myself.
I guess it depends on why you're doing this and how much time you can devote to it. If time is limited and you're looking for something that will appeal to prospective employers, then yeah, Java's an excellent choice, and you've gotten some solid advice in this thread about how to get started using it.
But if you do have the time, I highly recommend giving old-school Perl/CGI programming a sniff. It ain't a particularly marketable skillset anymore, but you'll learn things worth knowing.
You don't have to learn all of Java and its libraries. Just learn what you need for the job at hand. You will find there are plenty of options, but you don't have to get the best option every time.
If your base programming concepts are clear no
language should be difficult for you. I have switched over from vb 6 to java to c# to objective c now. What really makes a coders life easy is the IDE, debugging tools, documentation and lot of blog posts which google can search :-) regarding one man team my personal view is I am at my best when left to code and research alone with the help of google and stack overflow ofcourse :-) so I do think in programming large sized teams often lead to more screw ups than results
Java is not a complex language, altough it looks frightening at first.
I started learning Java from home, not a school, at 15 years of age (yes, yes, I know that's nothing to brag about) trough a book. It's a norwegian book, so I won't link to amazon;)
After reading/hacking trough half the book I found out I was better off ditching the book and looking for more stuff online. Google really IS awesome!
I would often read about all the fancy features of the JVM, frameworks, third-party libraries, JSRs and so on, and how much better my life would be with them all, but I just ignored them all. Yes I tried, but found it too confusing to learn Java and a framework that wasn't really necessary, at the same time.
Some people gave me hell for not using insertRandomLibraryName() or insertFancyFrameworkName(), and told me all about how much time and effort i would save, but I'm glad I didn't listen.
Now times have changed, and I still learn new things, or easier ways to do old things, every day. And I'm glad I took the time to learn the language itself before all the fancy stuff.
Also, don't use a notepad for writing code, use an IDE from the beginning. The only one I've ever really used is NetBeans, so that's the only thing I can recommend, but I sure am really happy with it!
As to Java SE, ME and EE, start with SE, and you'll propably find that it's enough for now. You don't have to use EE to write for the web, SE is fully capable of webernet stuff;D