I started web programming with raw PHP, gradually moving on to its various frameworks, then to Django and Rails. In every framework I've used, pretty much everything I need to do with a database (even involving relatively complex things like many-to-many relationships) could be taken care of by the automatically generated database API without much work. Those few operations that were more complex could be done with straight SQL or by tying together multiple API calls.
Now I'm starting to learn Java, and it's confusing me that the language celebrated for being so robust for back-end infrastructure requires so much more code (doesn't that mean harder to maintain?) to do simple things. Example from a tutorial: say you want to search by last name. You write the method in the DAO using Hibernate query language, then you write a method in the Service to call it (couldn't that be automated?), then you call the Service method from the controller. Whereas in any other framework I've worked with, you could call something to the effect of
Person.find_by_last_name(request.POST['last_name'])
Straight out of the controller - you don't have to write anything custom to do something like that.
Is there some kind of code generation I haven't found yet? Something in Eclipse? Just doesn't seem right to me that the language regraded as one of the best choices for complex back-ends is so much harder to work with. Is there something I'm missing?
Grails for the win. Groovy is very similar to Java but with a lot of nice dynamic language additions/simplifications. Grails has GORM, which is exactly what you're looking for.
In the example you mention, it looks like they are using more of a tiered architecture than you are used to.
Controller -> Service -> DAO
This provides for separation within the app. This is also completely dependent on the architecture of your application, not really Java as a language. Technically there is nothing in Java that would stop you from calling a Hibernate query in your controller. It just wouldn't constitute good design.
Another thing to consider is that the 'Service' could be something like an EJB, which may have the role of Transaction management, so that multiple calls to the DAO/Hibernate can be wrappered in a single transaction that will automatically commit or rollback on success / exception.
Again though, this is all in the architecture / framework that you are using, not Java as a language.
I would suggest that you look at the Spring framework for Java.
I haven't personally used it, but I've heard good things about it. From what I understand it provides the same sort of functionality that you would get Django and Rails.
I'd suggest you use Seam. It is a very good controller, that does not force you to have fully multitiered ap. It is fully integrated with JPA (Java Persistence Api) that does ORM.
Features
Has very nice scoping - you can have objects scoped to Session, pageload, conversation (conversation is an unit of work from user perispective).
Does not require much XML.
Does not require much boilerplate code!
Is easy to learn (you may even generate framework project from entity classes or db schema; it will still require much of work, but it will at least cut down boilerplate code)
Very nice security (you may either use role based security, or use rules framework)
When writing webpage you use beans (normal java objects).
You may write:
#{PersonHome.instance.name}
which will evaluate to the value of name of a person. If in request parameter there was person id it will be passed to PersonHome component (if it was annotated properly), and person bean will be loaded transparently from the db.
And you may even write:
<h:commandLink action="#{PersonHome.delete(person}">
Where controllerBean is java bean, and delete takes person object. It will be transparently translated to link that will have person id parameter, that will transparently be translated to bean before action method will be fired.
The only caveat for now is that it somewhat limits your choice of view framework: it works only with RichFaces, GWT, and something else that I cant remember now ;).
PS.
Yes I'm a huge fan of seam :).
Get iBatis for Java. It isn't as robust as Django's ORM (nothing is), but it's a big, big step above JDBC.
Well yeah, but it's not separation that's the concern for me. With these other database APIs, concerns are separated - it's not that custom DB logic is written in the controller (which I know is bad form) but that it's automatically generated. The call looks exactly the same from the controller, the difference is that with Java/Hibernate I had to write it myself and with Django/Rails/Symfony/Cake it was already there for me.
Grails looks very interesting. The main reason I'm learning Java, though, is because I want to at least be able to work with something I can use professionally. I'm not sure Grails fits that bill, though because it is Java perhaps the Enterprise will warm up to it moreso than Rails.
Django is the most beautiful piece of code I have ever worked with, but it's not trusted by the kind of businesses who can afford custom web apps, which is the market I think I want to be in.
iBATIS looks very promising - looking through the JPetStore code it appears it does a bit more automatically. But did all that SQL have to be hand-coded? Because then I'd be back where I started.
Spring has a great and reasonably easy to work with interface layer (MVC), and it ties components together pretty nicely. Though it can be used to integrate an ORM into an app, as far as I know it's not one.
Part of the the reason that you don't get automatically generated database APIs in Java is that as a compiled language without macros (like Lisp) it cannot do runtime code generation. Dynamically typed script languages like Ruby have that capability.
Another part of the reason is cultural: the J2EE world has tended to prefer configuration over convention for the last decade. The major reason for this preference is that enterprisey apps often have to work with lots of crufty assumptions that bring with it all sorts of "weird" edge cases. It is what it is. These assumptions stand in stark contrast to what the newer frameworks like Rails assume.
That said, I don't think there's anything to prevent a Java ORM API from generating database APIs at compile time. My guess is that Naked Objects is more up your alley.
Just doesn't seem right to me that the language regraded as one of the best choices for complex back-ends is so much harder to work with. Is there something I'm missing?
The reason for this is the amount of time Java has been deployed in the Enterprise.
It's not that Java is more mature than, say, Ruby, it's just that Java has been used for longer and has been proven by risk averse IT departments.
One recommended way in is therefore via JRuby (+Rails), as that runs on the Java VM, and the IT department don't need to install or reconfigure anything...
Related
Well, I've taken help of Google, Stackoverflow and whatever else I could find, did as much as I could, but it seems that I am unable to find out an exact answer! I have multiple queries, and I would love to have answers from the database-people as well as from the programmers and framework users.
From the programming languages, I know C/C++, Java and Python. I have undertaken a CMS project that would require frequent C's & R's of the CRUD. The project would have 50k users atleast. The head-to-toe of the project has been all figured out, and now I need to code it and make it live online.
Well, I want to use Neo4j as my database as its data representation model (nodes and relationships) is closest to the real project model. Now, neo4j has bindings for various languages, and one of them is Python (whose python bindings are very oldish, the jpype hasn't been updated since ages). I am thinking of going for some Java based framework, but then I leave this idea as I personally haven't heard much of java frameworks. But one of my partner tells me to go for Zend (PHP) as it has some kind of functionality that lets us execute Java code. Won't this slow the code? I mean executing one language's code in another language...
So, it all comes to this:
1) Database: I would want to go for Neo4j. But does it goes well off when the scalability factor kicks in? (From what I could gather from google, there are no scalability issues).
2) What framework to use in case of Neo4j? I would require a framework that is able to handle tonnes of requests and large data as the users of the project would be Creating and Reading data a lot.
P.S.: I know it is a long question, but couldn't jot it down in lesser words!
I can't speak about the scalability or suitability of Neo4J for your particular project.
However, I'd strongly advise you against trying to mix and match languages like Java and PHP. It's so much easier to stick to the best one for your particular task. I'd also strongly advise you against using JNI for anything unless you have no other option. Java is fast enough that you should almost never need JNI for performance.
That said, it's OK to run Neo4j in its "full server" mode and then have your PHP or Python application access it using some driver over the network. I just wouldn't recommend making an ugly hybrid of PHP and Java at your application layer.
Some decent Java frameworks you could check out include:
Spring
Google Guice with Sitebricks
Apache Struts 2
They're pretty standard in the industry and there are tons of good resources available on all of them.
In regards to the mini-question about language interoperability, Java provides the JNI interface, which allows the JVM and user code to make calls into other languages and vice versa. When the native code (e.g. C code called by Java, or Java called from C) runs, it is actually running in its natural environment, so there's no performance loss in terms of actual execution.
Neo4j as a standalone server has also REST API: http://docs.neo4j.org/chunked/milestone/rest-api.html, if you can embedded your requests in single REST queries, there is no need to use native embedded neo4j. If there is no need to use the embedded neo4j, you can take any language of your choice.
Regarding the scalability, recently neo4j can be used on Azure, so it must be quite easy to scale. To learn more how to scale neo4j, go to this page on neo4j.org.
UPDATE: in the newest version of Neo4j, there is added the support for a new query language - http://blog.neo4j.org/2011/06/kiruna-stol-14-milestone-4.html.
I work in a medium to small team ( 10 people ) developing and supporting several web enterprise applications.
We have a dozen of them built with a house-made framework with asp-classic working against ms-sql server.
We are evaluating the migration to a new development stack.
We'd like it to be open (free) and simple.
I've been looking around the java web frameworks, but all of them seem to be extremely overbloated for our needs (with the possible exception of http://www.playframework.org/, which I couldn't study yet...)
We are thinking about porting our own framework to this new stack, rather than adopting a whole new stack that we are unaware of ...
so far now, we though about the following possibilities
plain java - jsp - jsf
groovy - gsp (no grails at all)
jruby (no rails at all)
we feel really comfortable working with dynamic languages (well, as dynamic as classic asp can be) and with a lean and understandable framework...
I see no small and simple web frameworks for java, like there are for php or ruby...
I really like groovy, but I see no web implementations outside of grails... Besides the language documentation doesn't seem to be quite complete (I might be looking in the wrong place, perhaps)
php could be an option, but I think it would be hard to advocate for it in my current work...
any other option, advice, pros and cons?
thanks a lot
--
edit
some related link Can anyone recommend a simple Java web-app framework?
I'd suggest you take another look at Grails. It does use hibernate and spring under the covers, but for most situations, you don't need to know the details of those frameworks. There's a large community and lots of documentation/blogs/mailing lists for support, as well as a thriving plugin community with over 300 plugins solving pretty much any need.
If you're still put off by grails, you could look into the play framework. I don't have any experience with it, but there has been some traffic recently around it on hacker news and the like. I know it uses groovy for the templating language.
I cannot recommend anything, but strongly recommend that you consider these things:
Rapid development. Basically you want to save a page file, and reload it in the browser. Instantly! It can be done, do not settle for long deployment times.
Plain, readable text files!
Convention coding instead of explicit coding - big XML files will eventually drive one or more developers insane. The less, the better.
Good tool support (just having syntax coloring may be a big help)
Consider the long term support of your choice. You are basically remarrying with your software - will it still be maintained in 10 years? By whom? Will you have alternatives (JSR's are great - look at the amount of servlet engines)?
And WHEN you choose - get the source code for it, and ensure that it builds correctly. It will never be easier than now, and some day you WILL need to fix something inside. On short notice! (You may even consider allocating resources for donating documentation/patches/time to the open source project you are building your business on).
EDIT: A few more things:
You want to be able to verify things at compile time. One of the things that make it possible to build cathedrals in Java is that the static typechecking prevents a lot of nasty runtime errors. "Oh, THAT method? Well, it's not here, sorry. Boom!"
You want good error reporting. Built in! Try throwing a NullPointerException deep, deep down and see what 1) the user and 2) the developer is told about it. Anything that requires going to a log file to get the details WILL cause calls at 3 AM eventually.
Look into scalability from the start. Any non-trivial customer will need to and the world goes to multicores, so you might as well think about it already now. What will you do when all the magic pixie performance dust has been used and it just isn't enough: The application requires more than a single box.
And read this: http://www.pragprog.com/titles/mnee/release-it
You're forgetting about the other major player in this field: the LAMP stack (linux, Apache, MySQL and mod_perl). All components are free, there are many books available on LAMP development and each of these components, and there are vast numbers of libraries and components already available.
Apache: the Definitive Guide
Learning Perl: by SO's brian d foy
Practical mod_perl
If you are afraid of Grails and need Java, try Stripes and read the excellent Stripes book (http://www.stripesbook.com/blog/). You can buy the eBook pdf for $23. The book covers the framework in amazing detail. Stripes is a very strong, lightweight MVC framework that deals with all the common problems of web development (templates, url mapping, form validation, security, internationalization, testing) but it won't automagically create the database layer for you unless you want it to by using Stripernate. You can also use Groovy with it. You can use it standalone or with Spring.
I've had great success in simple web projects using Spring MVC with JSTL JSPs. Spring MVC is a framework that can be kept pretty darn simple (1 additional XML file used for configuration). You can eschew all the fancy options and just specify a set of JSPs that you want to associate with view names, then forward to those views by specifying their names in the controller.
Spring MVC can also easily scale up and be as complex as you need, letting you switch from JSTL to JSTL with Tiles, or Struts, or JSF, or Wicket. It can also handle complex web flows using the Spring Web Flow project. But for most projects I just keep it simple -- build a JSTL JSP, create a controller that provides the objects that JSP needs, and associate them by having the controller return that view. Once you get the project set up and you're familiar with the configuration, it takes maybe a couple minutes to wire a new page into place.
If you like Groovy but don't like Grails you could try Gaelyk, which is a lightweight Groovy framework. However, AFAIK you can only use Gaelyk if you're hosting the app on the Google App Engine
If your apps won't be hosted on GAE, and you really don't want to use Grails, another option is to use Groovlets, Groovy template servlet, GSPs.
However, personally I think it's a big mistake to dismiss Grails. It really is a great framework, and you can go a long way without knowing much about Spring and Hibernate. One of your complaints is a lack of Grails documentation. I think you must have been looking in the wrong place, because in addition to all the books available, there's a very extensive reference document and a lot of other documentation available on the website. Finally, there's a very active mailing list.
My platform of choice is JRuby - Rails (3) because of its very rich and powerful ecosystem, but mainly because:
* very easy to use
* many MANY libraries
* fast support via IRC
* deep documentation
You can also check out Scala + Lift Web Framework ( imho best static typed language, nice framework )
So I have taken over a Java Web project. The application was written by another developer who now works for another company. Generally speaking, the application is straightforward, well designed and the code is documented enough. The only issue is that the previous developer decided to built his own database access library instead of using a popular framework. Over the years of his programming career he has build an impressive framework to access any database (something similar to a lightweight Hiberbate).
Now, I have no reason to throw away his code and replace the data layer with a more conventional JPA layer since the current code work just fine (although it is tempting!). But I was wondering if I should use a more conventional framework with new features. The application stack is straightforward and I could easily plug Hibernate or JPA. So old pages (with new bugfixes) would use the old framework, and the new page would use the new framework.
One of the drawback of this approach however is that it can get confusing to new developer. However, I can also continue to use the old framework, expanding/fixing it as necessary. Like I said, it works!
You certainly don't want to add frameworks at a whim, but the opposite is also bad, writing your own psuedo-framework when an acceptable alternative exists. In my job, we had to a do a conversion from JPA to a more JDBC style using Spring. During the conversion, I didn't delete or modify any of the JPA code, I simply re-wrote it in JDBC. Once I was comfortable that particular method worked, I would swap out the implementation. This allowed me to piece-meal the conversion over, without pulling the rug out from under the service layer, so to speak. So to fully answer your question, it is okay to have 2 frameworks as long as the plan is to migrate to one or the other.
Eldimo,
You should balance the decision to incorporate a new framework based on the return of investment of such change. The longevity of the current project is one way to look at it.
If the project is stable and on maintenance phase then you shouldn't make drastic changes.
But if the project will continue to incorporate new features and continue to grow, then you should consider adopting a supported framework if it increases the return of investment.If you foresee changes in the current home grow framework in order to support new requirements and if those requirements are supported by other existing frameworks, then you have a strong reason to adopt them.
However, the adoption of a new persistence framework will destabilize the current project for a short period of time, increasing the volume of bugs due to the lack of team experience with the framework and can also affect the velocity of the development team.
"it works" - don't touch!
It might be worthwhile building up a case for doing this work - performance tests, scalability investigations, etc. If you find no good reason, leave it be for projects that are currently using it. If enough bugs are raised that boil down to the DB, then there is a case there for migration to a well supported backend. If performance is low for both, then maybe raw JDBC is the way to go rather than switching abstraction frameworks.
In this case, I think the answer is "yes"....if you truly can make use of the features Hibernate or JPA possess that the legacy library does not and if you're certain you won't be breaking anything that currently exists.
By incorporating either Hibernate or JPA not only are you offloading some of the maintenance responsibility on those development teams, but it sounds like you'll be happier in terms of moving forward.
Just document all your changes and your reasoning behind them, for the sake of the developer who follows you.
If it works and is impressive, why give in to the temptation to switch to another framework for no reason? Unless the current framework has some negatives (hard to maintain, hard to understand, impossible to debug etc), I say leave it alone.
The real drawback to doing something like this is the risk that one framework will make changes to the database that the other framework will not pick up immediately. I've run into this before using a combination of NHibernate + ADO.NET: if NHibernate has cached something, it may ignore ADO.NET changes.
If you can mitigate that, there's nothing technically wrong with doing this.
I've done lots of java web development using jsps and servlets, and I have found this approach to be straightforward and flexible. Some of the groundwork involved though - such as managing database connections - is rather tedious, and it takes a fair amount of work just to get a new web app off the ground.
I'm therefore considering using a framework for the first time, but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration. What I'm looking for is something simple that (after the initial learning curve) will enable me to get up and running with a new web app as quickly as possible.
So my question is - does it make sense to use a framework for a simple java web app?
Note that I'm not asking which framework to use (if indeed a framework is recommended), as it has already been asked here.
If you don't use a web framework you'll usually end up writing one - poorly.
It makes a lot of sense. My team has spent the better part of five years with our open source stack and no matter and we have a "seed" project (works like appfuse) that we use to create all new web apps. Even the simple two pagers from the pov of maintaining the app, it looks like every other app, just smaller.
The short is you won't get any return on the investment right now, but you will as the project evolves and you maintain it.
Yes, I would use a web framework for the following reasons:
Increased navigation capabilities and controls. Even though you may not need them, they are there for you to use should you require them at any time
As others have indicated, apps grow over time and you will feel the need for the framework at some point in time in the future. When you need to add additional pages and navigation
Features that allow you to plug into other frameworks such as security and DB access frameworks. Spring is a prime example in the Java world. You never have to use Spring but it plugs in so well with Struts, Spring MVC, Hibernate, Acegi etc. It ends up saving you the hassle of doing all of the plumbing on your own.
Support!!! Good frameworks almost always have a vibrant community to support them and ask and answer questions.
It may seem like too much hassle initially but definitely saves you much time in the future
I'd say it actually matters quite a lot which framework you go for. Something like Spring MVC is fairly unobtrusive in your code and allows you existing stuff to run quite a lot as-is. Other frameworks have much more specific ideas about how you should do things.
Yes it does make sense. Apps can grow and change and might require something a framework can provide easily in the future.
For example at my workplace we have simple jsp / servlet app. It needs to be rewritten just because of what I explained above. If someone would have taken the time to just get the framework setup we would be in better shape today.
Yes it makes sense. However implicit in your question is that the wrong (for you) framework can be more pain than it's worth - and that's true. There is a world of difference between some heavy J2EE framework and something light and cheerful like grails.
What's the alternative? Rolling your own? Embedding all the navigation and logic in the JSPs?
I agree with those who say that a web framework is worth it. There are literally hundreds now (e.g., Struts, JSF, Spring, Wicket, etc.). Pick one that suits you.
There are two kinds of applications:
1) the kind that you throw away and never use again, and therefore should not worry about modularity, maintainability and clarity.
2) the real kind.
It may sometimes seem that your app may never have to grow, scale, or service a larger feature set / user base than you currently are planning for....I assure you, that perception is always wrong.
Frameworks, specifically things like Struts for MVC in Java, Spring for MVC and Dependency Injection, Hibernate for Object-Relational Modeling are all extremely valuable tools that lead to modularity, maintainability and clarity in your code. So, to answer your original question.... Yes, emphatically.
No it doesn't unless:
you don't have any java experience
in your team
you are doing just a prototype that
must be ready in hours
you don't trust your developers
enough to let them write your
application
you don't plan to let your
developers learn and improve
Danger in using frameworks include but not limited to:
you'll get all framework defects on
top on your own
you'll be unable to do realistic estimates until you
know perfectly the framework
your team won't learn how to program a
web server
you'll find your team passing more
and more time on google instead that
solving problems by writing code.
The only thing that is worst that choosing a open source framework is having a separate R&D team in the company who should create the "big complete ultimate company framework".
but my impression of frameworks is that they're mostly used for large J2EE applications and involve a lot of complex configuration
Not necessarily true. The good frameworks are built to scale well so that they will take you from small apps to very large apps. Many of the frameworks today are moving towards zero configuration so you will find them easier and easier to use.
You are right that it does take an initial effort to learn the framework itself but that investment pays for itself in the very first application you build. And meta frameworks like AppFuse makes it even easier to get started since it pre-configures the frameworks for you.
Frameworks make sense for most applications. It may be necessary for you to build your own or adopt some other framework. The most important questions is the granularity of your data structures. What I mean by this is do you need to just enter data or do you need to parse, compile and execute dynamic code?
If you think of a frame works as a gauge and to the left is an all ready existing frame work open source or closed and to the right is all custom framework then super impose your code on top of that frame work where the level of complexity increases to the right. The farther right you go the more of a stuggle you will have with the frame work (IMO).
However, you can also slowly migrate from existing to custom framework.
There is also the question about your business. If you work for a business that does not look at software as it's core compentency such as a bank or hospital then you need to way that into how much of a frame work you want to build.
Bottom line a framework of some type will always be useful.
Using a framework may add some overhead to your web-app development due to the learning curve. However, depending on the framework you choose, you may be able to realize the following benefits:
Scalability
Maintainability
Clear Division of your model (e.g. MVC)
Out-of-the-box components(SessionManagement,authentication,etc )
Third party plugins
Modularity inherited from the framework
Many others.
Besides, the learning curve is a variable factor. Some frameworks may be easier to learn than others depending on your skills.
It definitely makes sense to look into using a framework even if for no other reason than it'll give you a new area of knowledge. If you've got the time to invest in learning a framework then you may well find in time that it's easier and faster to use that for new projects no matter how simple they are.
Also, if I could vote for SamBeran's post then I would. Getting started with a framework will involve several moments of "oh great! I don't need to write all that boilerplate again!".
I'd say use one - like you said, it's rather tedious to get stuff up and running for even a simple java web app. If the framework helps you get the job done faster and provides the services you need, I'd say it makes sense.
I have a rather large (80k loc) java desktop app that talks to a database. We're now looking at exposing some parts of the database via a web application, using the existing codebase and preferably not having to modify it.
I have good separation between the data access, business logic and presentation layers, but we haven't used enterprise java beans or anything like that (if that's important).
What's the best way forward? Which of the java web frameworks will be best suited to the problem? Learning curve isn't terribly important, since I haven't done any java development on the web...
To be true, it depends what you already have, and how well is the design of your current desktop application. You might not be able to use any or may be minimal of your existing code without modifying it, if its designed badly, and everything is tightly coupled.
Assuming that you are having a system with a good design, everything is de-coupled well enough. You can look into Stripes to make your presentation for the web, and use your existing data access and business code. I wish you all the luck.
Few other goodies to look into are, Groovy on Grail, Wicket.
I don't recommend anything like Seam and Spring they are more of a container and sophisticated large frameworks, which give you almost everything, solution for almost all of your problems. As you mentioned that you already have a complete system, and you just need to make a web interface to publish it for the web, these are not recommended, IMO.
JSF, is a good framework, but it might drive you nuts and has a big learning curve, according to few folks.
The two frameworks I would recommend would be Grails and Struts 2.
Grails comes with a whole bunch of stuff that it configures under the covers including Hibernate and Spring. It makes generating dynamic pages to send to the browser ridiculously easy. What you are probably going to need to do is set up controllers that call Grails services which reference your existing code as you probably don't want Grails managing your database interactions. The disadvantage with Grails is not so much that it is written in Groovy, which is easy to learn for Java programmers, but that the IDE support for Groovy is still maturing. Still if you want quick productivity this is the route to go down.
Struts 2 offers a clean command pattern framework implementation that talks to JSPs (or velocity or FreeMarker templates) on the front end. To use this you would configure actions to call your existing code. You may want to investigate adding Spring to the mix depending on what you need to do.
There are other choices but these are two that I have had some success with.