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.
Related
We are looking at reworking a java business management web service that has been in use for over 4 years now. The software's internal architecture has been all custom built and with a bad separation of of the presentation layer and business logic. As well the overall model layer has proven it can't effectively keep up with changing business logic and needs refactored. As I am planning out this task I have been looking at available frameworks that I could leverage to make the application more friendly to new developers hired on and changing business logic. I have never used struts or JSF before but read up on them in a somewhat brief and overview method and at first glance am not overly impressed by either, however I find JSF more intriguing.
First Both Frameworks seem to focus on the Controller and View portions of the MVC pattern. Leaving you to do whatever on the model/business layer. (am I correct?)
With the rework we want to be able to employ outside contractors to help expedite the rework so finding a unified development methodology is important to insure quality of code and decrease inconsistencies and ramp-up times.
So what recommendation would you have on frameworks, practices, etc that might help this effort. I really don't want to reinvent the wheel with a custom framework and find us in a similar situation later.
There are a couple of things you should think about when undertaking this approach:
Your specific needs vs. the focus
of a particular framework
Availability of coders who know the
framework (in-house and on the
market)
Learning curve for the
framework, and the level of its acceptance & support in the broader community of developers.
Many people speak highly of Spring MVC, though if IOC is new to you (or you don't buy the concept) this may be a bit more than you want to bite off "all at once."
Another well established option is Struts (though I'd strongly suggest Struts 2 for new development).
One thing to be wary of is the size & scope of a "framework transplant" operation. If your app is in dire need of serious structural reorganization, it's quite likely you could end up basically starting from scratch and hanging chunks of your existing business logic off of a skeleton built upon framework. The time/money/resources (and opportunity cost!) should not be underestimated, and you should be certain management really buys off so you don't get the plug pulled on you halfway through. It's really really important to "measure thrice and cut once" here, and make sure you're biting off a chunk of work you can chew -- going from "legacy app" to "brand new state of the art app using all new technologies" is frankly best done in stages, rather than all at once.
It would be helpful to understand the size & relative complexity of the application as well as it's basic nature (is it a very web-UI intensive app, or a back office system which does lots of jobs?) in order to make better suggestions about particular frameworks: though you could certainly build most webapps on any given framework, some are slanted more heavily in one direction than another (e.g., Struts and Wicket have a pretty different focus)
Additionally, there's nothing wrong with trying a couple candidate platforms alongside your existing application. Though I know nothing about your current app's technology backplane, unless you've done something really strange it's likely quite possible to install one or more frameworks and experiment with them alongside your existing app (e.g., write new features against them, or rewrite portions of existing code using them, then hook that code into the backend). This will let you experiment and "try before you buy". I'd suggest having your team give this a whirl on one or more "short list" framework candidates to get the feel for how it'll work in practice. This is, incidentally, not a terrible way to approach refactoring: gradually replace old functionality with your new framework.
Final (I think) piece of advice: look long & hard at your datamodel and the interfaces thereto. That's typically going to be where the real gremlins are, and regardless of framework you want to get that right. I'd strongly consider making that your #1 refactoring target, rather than the adoption of a particular framework. A strong datamodel is going to make implementing ANY framework (and handling upgrades) much easier...and should your management change directions on you and end up delaying the framework upgrade for whatever reason, time spent refactoring the data model will pay off.
EDIT:
Given your comments about the shape of the product, I'd double-down on the "be very, very careful" advice. The spot you're in now is very common (and notorious) and has eaten many teams (and careers) alive. You need strong understanding & support from stakeholders up the chain and on the business side as this is going to be a hugh undertaking which will, by nature, take longer & cost more than you imagine. The technical team's ability to be clear-eyed and realistic about the cost + scope of the changes here is CRUCIAL to success -- if you underestimate significantly you're jeopardizing budget, careers, and potentially the business itself. If you overestimate, you may never get to start :)
One approach, once you have strong buy-in and support from management, is to really treat this as a whole new product -- put the old stuff on maintenance, roll up your sleeves, and start designing the replacement system with all the knowledge you've gained in the previous implementation. In that case, I'd work out the component and data interactions sans-framework, then look at how a given set of candidate frameworks would support that implementation. Starting with the framework may lead you to unnatural places, and could land you back in a similar spot down the road.
Some well-known popular frameworks to check out:
Struts2 - MVC /w AJAX support
Wicket - AJAX heavy
Struts1 - Granddaddy of pretty much all Java frameworks; worth a look
Spring MVC - Spring's IOC webframework
If you liked JSF and want to use it, I would recommend the use of JBoss Seam. You can also use Spring, but I think that using JBoss Seam makes the use of JSF much easier. I am using it for almost 1 year now with good results. And if you want to modelate your process as a business process you can try JBPM (along with Seam).
If you want to know more about agile methodologies so you can improve both your methodologies and practices, take a look first on the agile manifesto http://agilemanifesto.org/ . And then start trying established methodologies like XP or Scrum.
But take your time, start trying one change than another not to confuse yourself
JSF allows you to focus on components, while JSP based solutions don't as well, or as much. You'll still find yourself coding a lot of jsp'ized html stuff, while with JSF solutions, you really don't need to.
Look at RichFaces or IceFaces as libs. RichFaces makes it trivially easy to do AJAX type stuff. Just add the tag <a4j:support event="onkeyup" reRender="output"/> to your standard JSF control. In the example above, on the keyup event for the control, it will rerender an area <a4j:region, or another JSF, Richfaces tag. Nothing simpler.
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
I'm relatively new to Java programming (About 2 years) but not to web development. I started out with HTML and ASP (pre .NET), and have recently started messing with J2EE. I feel like I have a good grasp of JSP/Servlets (I find them to be similar to ASP) and have recently begun working with JSF and Facelets. Although I can see why people would like JSF, I find it to be a huge burden and it's actually slowing my development times down. I imagine this is due to the learning curve, but I often find myself thinking that I would be finished with a page/task if I were just using JSP/Servlets.
Is this common to those of you who have taken the time to learn a framework? Have you ever invested time into learning a framework and once you were proficient in it, just decided to go back to a method that wasn't as sophisticated but you felt comfortable with?
I'm also questioning whether I've chosen the right framework. I was really hoping to find something that didn't interfere with adding AJAX capabilities.
JSF can be tricky to get started with, and is harder to learn than many Java web frameworks. You might find it easier to use JSF with Seam, which simplifies much of how you work with JSF, and replaces JSP with Facelets, which is a great improvement.
Alternatively, you could try SpringMVC, which lots of people find easier to use.
I've been using facelets for a little over a year. One of the main advantages I see in Java web frameworks is that it helps to keep the code clean and promotes re-use. For instance, in facelets, you don't get any scriptlets in your pages like you do in JSP. I've seen ASP files in production that are over 3000 lines long. There's nothing inherently wrong with ASP or JSP, but it does make it quite easy to lump some business logic in the page. No harm, right? Until someone else has to maintain it.
Most frameworks try to 'help' you keep a more strict separation of MVC or whatever model they favor, which in turn leads to cleaner templates ( jsp, facelets, whatever ) and business and domain code that is automatically unit testable. Using many of the frameworks can take a bit more time up front, but save you many times that when it comes to maintenance and refactoring.
I think the easy answer is - how will you test it and verify it works when you make changes?
This is where the easy solutions breaks down, and you end up in maintainance hell. Unfortunately :(
I think this depends on whether the framework genuinely solves a "difficult problem" for you, and solves it easily. People always find this a terribly controversial thing to say for some reason, but most of the frameworks I've considered using I've ending up ditching halfway through because it's just easier to Write Some Code to do exactly what I want.
Later, when I have a problem in my code, I can just go to where the problem is and add a line of code to fix it, rather than wading through pages of documentation to find the magic configuration parameter. If I have a problem with (insert favourite framework), I generally find I'm p*ssing around for ages when the underlying problem that the framework is supposed to be solving was never that complicated in the first place.
My favourite useless frameworks are ones that require lots of configuration and clumsy boilerplate code to do basic tasks such as sending some bytes down a socket or stuffing some parameters into a prepared statement and firing it off to a database. Another of my favourites are the whole raft of "XML technologies", especially ones that are "pluggable" or "configurable". (Why do I want a "pluggable parser framework" rather than just one parser that always works...?) Call me Victor Meldrew, but it's amazing how people can turn a 10-minute regular expression problem into a 2-day how-do-you-make-this-framework-with-X-in-the-title-do-it problem.
Now that said, there are people who absolutely thrive on Spring, Hibernate, JSF, MVCJammer, Joomajamaventilate, things with 'X' in them etc etc. So clearly for some people in some situations, they're a miracle, and I'm just missing out in life.
Possibly it depends on whether you or your organisation primarily have "configuration" and "plugging things together" expertese or "programming" expertese? I suppose I have more of the latter.
My advice: get comfortable with lots of different frameworks, and know how to get your hands dirty and write it yourself, too. You'll develop some favorite ways to work, but you'll get a good understanding for what the tools can do, and what they can't. And you'll also develop an eye for when is the right time to use a framework, and when is the right time not to.
I've found that JSF and Facelets are definitely worth the hassle, if you can survive the learning curve. It's pretty steep, but when you figure it out, it's very easy to work with. They make managing session and application scope objects much easier to deal with than just raw JSP and servlets, and I've found that I can write cleaner Java when I don't have to think about the web in the business logic. In general, I find that the frameworks help me to organize my thoughts (and by extension, my code) in a consistent, easy to understand way.
Facelets, in particular, is my favorite web template engine. I love the fact that my pages are valid XML, and that I don't have scriptlets all over the place. It makes the code much cleaner and easier to follow if you know the framework. There's that learning curve again.
By the way, adding AJAX to Facelets is easy if you use something like RichFaces or IceFaces. They have pre-built ajax components that you can easily add to your application.
That said, it's not the best for all projects, YMMV, and so on. At the end of the day, using any framework is a judgment call. If it's not helping you solve your problem, then it's not worth it. Don't fight with your tools, use them correctly. If the tool is in your way, use a different tool. JSF and facelets are really not very good choices on a very small application. They don't really come into their own until you have a fairly complex domain model and complex business logic. Basically, you need the project to be complicated enough to overcome the amount of boilerplate code you need to write to get going.
I second SpringMVC. It's very easy to comprehend, and the code is very semantic if you use annotations. Like those Budweiser commercials...Servlets is too light...Struts is too heavy.
I wish Java had Scaffolding. It can with Grails, but that's another framework to embed within a framework.
SpringMVC is worth the hassle. J2EE is not.
I want to move a legacy Java web application (J2EE) to a scripting language - any scripting language - in order to improve programming efficiency.
What is the easiest way to do this? Are there any automated tools that can convert the bulk of the business logic?
Here's what you have to do.
First, be sure you can walk before you run. Build something simple, possibly tangentially related to your main project.
DO NOT build a piece of the final project and hope it will "evolve" into the final project. This never works out well. Why? You'll make dumb mistakes. But you can't delete or rework them because you're supposed to evolve that mistake into the final project.
Next, pick a a framework. What? Second? Yes. Second. Until you actually do something with some scripting languages and frameworks, you have no real useful concept of what you're doing. Once you've built something, you now have an informed opinion.
"Wait," you say. "To do step 1 I had to pick a framework." True. Step 1, however, contains decisions you're allowed to revoke. Pick the wrong framework for step 1 has no long-term bad effects. It was just learning.
Third, with your strategic framework, and some experience, break down your existing site into pieces you can build with your new framework. Prioritize those pieces from most important to least important.
DO NOT plan the entire conversion as one massive project. It never works. It makes a big job more complex than necessary.
We'll use Django as the example framework. You'll have templates, view functions, model definitions, URL mapping and other details.
For each build, do the following:
Convert your existing model to a Django model. This won't ever fit your legacy SQL. You'll have to rethink your model, fix old mistakes, correct old bugs that you've always wanted to correct.
Write unit tests.
Build a conversion utility to export old data and import into the new model.
Build Django admin pages to touch and feel the new data.
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
Plan your URL's and view functions. Sometimes, these view functions will leverage legacy action classes. Don't "convert". Rewrite from scratch. Use your new language and framework.
The only thing that's worth preserving is the data and the operational concept. Don't try to preserve or convert the code. It's misleading. You might convert unittests from JUnit to Python unittest.
I gave this advice a few months ago. I had to do some coaching and review during the processing. The revised site is up and running. No conversion from the old technology; they did the suggested rewrite from scratch. Developer happy. Site works well.
If you already have a large amount of business logic implemented in Java, then I see two possibilities for you.
The first is to use a high level language that runs within the JVM and has a web framework, such as Groovy/Grails or JRuby and Rails. This allows you to directly leverage all of the business logic you've implemented in Java without having to re-architect the entire site. You should be able to take advantage of the framework's improved productivity with respect to the web development and still leverage your existing business logic.
An alternative approach is to turn your business logic layer into a set of services available over a standard RPC mechanisim - REST, SOAP, XML-RPC or some other simple XML (YAML or JSON) over HTTP protocol (see also DWR) so that the front end can make these RPC calls to your business logic.
The first approach, using a high level language on the JVM is probably less re-architecture than the second.
If your goal is a complete migration off of Java, then either of these approaches allow you to do so in smaller steps - you may find that this kind of hybrid is better than whole sale deprecation - the JVM has a lot of libraries and integrates well into a lot of other systems.
Using an automated tool to "port" the web application will almost certainly guarantee that future programming efficiency will be minimised -- not improved.
A good scripting language can help programming efficiency when used by good programmers who understand good coding practices in that language. Automated tools are usually not designed to output code that is elegent or well-written, only code that works.
You'll only get an improvement in programming efficiency after you've put in the effort to re-implement the web app -- which, due to the time required for the reimplementation, may or may not result in an improvement overall.
A lot of the recommendations being given here are assuming you -- and just you -- are doing a full rewrite of the application. This is probably not the case, and it changes the answer quite a bit
If you've already got J2EE kicking around, the correct answer is Grails. It simply is: you probably already have Hibernate and Spring kicking around, and you're going to want the ability to flip back and forth between your old code and your new with a minimum amount of pain. That's exactly Groovy's forte, and it is even smoother than JRuby in this regards.
Also, if you've already got a J2EE app kicking around, you've already got Java developers kicking around. In that case, learning Groovy is like falling off a ladder -- literally. With the exception of anonymous inner classes, Groovy is a pure superset of Java, which means that you can write Java code, call it Groovy, and be done with it. As you become increasingly comfortable with the nicities of Groovy, you can integrate them into your Java-ish Groovy code. Before too long, you'll be writing very Groovy code, and not even really have realized the transition.
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