I want to start using guice in an existing application that has legacy code. Are there any pointers and BKM's on how to start doing that?
I found one approach here, and looking to get some further information and details.
Thanks!
EDIT: some more details about my app: it is a server app, that is running in a home-built server application, so there is no gui involved. It has a lot of legacy code that I have doubts if/how to migrate it.
Your strategy depends on how your application is built today. If you are using singletons excessively or some other framework. I've done a lot of porting applications from no framework into something like Spring or Guice. It's not an easy task, and how successful you are at it depends a lot on how much code, how many people are on your team, and how well the team accepts new ways of building the application. If you don't have buy in from your team then I'd start there before trying to code it. Convince people on your vision for the app, answer their questions, allow them to design a little in their heads, and welcome their input. If they have big concerns allow them to voice them, and if you don't have a solution acknowledge it, and go back and design one, then present it. Repeat it until you have everyone on board.
Now porting the code. It depends on the type of app you have: web based, desktop, etc. But, generally when I'm porting this stuff I create an empty project, and set that up the way you designed it with your team. Then start to pull over the long lived objects into the container. Singletons are good places to start because they typically live the entire time of the application. Start instantiating them in the container instead of their getInstance() methods. You might have to break the singleton pattern and expose their constructors, but eventually you want to rid yourself of singletons. You can keep the static ref. As you pull objects over refactor them from using getInstance() to using a reference that they are given through an instance variable/getter/setter.
Slowly you should be able to get to a point where you can execute your application from the Guice container. Maybe you've only ported a portion of the application at this point. Keep porting portions one by one and testing them in the container. At this point you've got enough of a base you can enlist help from other team members. Eventually you'll have the whole app ported over, and you can now start to refactor parts of it to work the Guice way. Go back and eliminate your static refs and calls to getInstance() where you can.
I've always found setting up a skeleton and porting over rather than refactoring in place to be much more efficient way of handling these types of conversions. Calling an all stop on new work is also critical, and it will save you lots of heartache in the end. I've tried not stopping new work, and these types of conversions can drag out over many releases because the team continues to new code in the legacy way. Sometimes starting after a new release during the lull period before real work starts on the next release can give you an extra boost so you can get to the point where other members can help you port because you have the skeleton laid down.
Remember management too. If they demand only new features you're going to have a hard time controlling the team. If they don't buy in to your effort they can make it very hard to finish.
Expect to be confused for a while. I was anyways. I love the video on the Guice home page.
I think incorporating Guice, or any dependency injection framework, into your application was accurately described to me as like pulling on a thread in a sweater and never really finding the end. What I mean by that, is that it could change your approach in several areas of your applications. Like, from servlets, to jdbc frameworks (we use mybatis-guice), to unit tests (check out jukito).
The Guice user group is a good resource.
Don't expect to do it all at once. It can take some time to get fully into developing the Guice way.
Related
I'm involved in a project at the institute where I study that consists in build an thematic online dictionary. I'm thinking in make it from zero, constructing an MySQL database and using it with servlets and jsps. I'm not professional and that's my first experience with a real project, so I'm afraid that this way may, in the future, cause problems such as difficulties in maintenance, for example. I know that there are many CMSs, but I would to use this experience to put all my theorical abilities in practical. Yes, I've time to waste. What I need to know is: the fact that I don't know things like Struts or Spring precludes that I make a functional system?
Thank you.
If you are willing to learn new technologies and break you head for a few hours in the beginning learning and applying it, then no, not knowing spring or struts does not preclude you from creating a functional system. Maintenance is a whole new ballgame/discussion. Even the best programmers in the world cannot create a zero maintenance system. The only thing you can do is learn the system well enough (and be prepared to make the learning on going) so that you can put in the best guard rails around it and also be able to debug issues. Now, if this system that you are planning on building needs to be a professional grade system, then I would recommend hiring/getting someone who has built web applications in the past and can maintain it. That person can help carry you until you can take over. If this is a smallish project which can live with a few initial issues/downtimes (which you can work on to improve), then I say go for it.
The best way (IMO) to learn is to take a sample application, deploy it and start reading code. See if you can trace the request from the browser (I am assuming your application is a web applications) into the framework, to your controller/models and back to the view. Grab a sample spring mvc application (for e.g. http://static.springsource.org/docs/Spring-MVC-step-by-step/) and see if you can make sense of it.
I have a project whose core domain is dramatically changing. It's possible to use 50% of the core functionality from this site and just add the 50% new functionality, but I am starting to consider that maybe it might be faster to simply redo the product in Rails. Development speed is very important.
There are some things I really like about java - the performance and scalability are very good. I am not a crappy Java developer, so my apps tend to run very well - better than the Rails sites I've seen. I've always accepted the idea that people probably just throw a little more money at the problem when it comes to using Rails, which probably works itself out in the end because of the insane productivity benefits.
I am actually quite agile with Java. I know it will still take me longer to add a basic entity to the system, but I am quick at it and I don't mind it that much. At least it's easy and straight-forward to do.
What I do mind is:
having to start/stop the server just to fix a route, lazy load exception, controller is going to wrong view, etc.
putting up with the fact that unit/integration tests sometimes have different results than the production environment (because annotations on controllers can't be tested, or lazy-loading exceptions occur during asynchronous service calls, or things like that). Knowing if your Jackson is marshaling your data properly is another Tomcat-only thing because it's handled by Spring. There are lots of things that go wrong after you have tested all that you can, and this frankly annoys the crap out of me.
putting up with the occasional maven/classloader problem that doesn't rear its ugly head until you deploy into tomcat. It gives the false impression that everything is "a-okay" when you are in your IDE.
having to put more effort to do database migrations than the ruby people ever have to.
putting up with framework bugs in Spring that block (it's happened about 5 times on this project since 2009) or Hibernate. I also don't like upgrading Spring Security and having them constantly change the configuration, apis and tag libraries over and over again. This is annoying.
wasting so much time uploading 58 MB war files to the server! These take me 12 minutes to upload whenever I need to deploy changes. If I forgot to do 'mvn clean' before I upload, Spring might complain that 2 beans exist with the same name because I moved one to a new package... and then I have to re-upload the whole stupid war file again. Why isn't "clean" run by default whenever you do 'mvn package' for?!?! Sometimes these frameworks and tools use the stupidest default settings. This is just so common in the Java world.
Having to spend hour(s) to figure out where a framework wants to plug-in your own custom implementation for something. This is very annoying. You can spend 2 hours sifting through Google and crappy documentation trying to figure out how to override Spring Security's authentication mechanism for example... and then spend only 5 minutes writing the actual implementation. Of course, they wrote paragraphs upon paragraphs explaining the architecture and how awesome it is, but nobody cares. For something so common, why not just give example source code and be done with it?
Waiting 10-15 seconds for Spring to start up whenever you want to run your integration tests. This is a drag.
There are a few things I like about Java though. Role-based access is very easy to do with Spring Security. Authentication is never that big of a gain, but I like the implementation inside of Spring.
I also like Spring's form-backing objects and #ModelAttribute. These are huge wins when it comes to controllers, and I don't know if Rails can do these things. I honestly never liked passing request parameters around in every action - Spring MVC is actually a lot easier to use when it comes to this common bloat.
Being able to cache really massive structures in memory and have them stay in memory when you start the application is also highly desirable, especially for this application actually. I have an in-memory thesaurus and grammar checker that needs to get called hundreds of times per request, so in memory is pretty much the fastest option for me.
Even still, I think I could rebuild what I have in 2-3 weeks, and then add all of the new features in a few weeks using rails.
On the bright side, all of the really well-designed css, html and javascript could be ported over with very little problems.
I'd appreciate some advice on the subject before I continue.
PS: I could also go to Spring-ROO... but that would also be a considerable rework. I was never using JPA - I was using Hibernate directly. I am also not using JSP's - I am using Freemarker.
It takes more time to get good at Ruby, and Rails. I worked as an independent contractor as Spring and Hibernate expert myself, but I felt strangled by java and it's web frameworks so I decided to learn Ruby on Rails.
I would advice you to learn Ruby, from what I read you would probably master it, although get pretty frustrated with the very different way the use the ORM. I had issues with it, used to working on aggregate roots in Hibernate to the ActiveRecord one class one table kind of pattern. But hey, you could easily try out MongoDB to have some real fun.
Ruby is
less code
it's fast and scalable (slower than java on the specific tasks, but you get rid of stacks of layers.)
the problems are more often; which gem should I use. Luxorious!
a unique, big, sharing and caring open source community
nice frameworks, as Rails and Sinatra
powerful.
fun!
Would I advice you to do the project you describe in Ruby.
NO.
Not if speed of development matters. You will be slower, trust me. There's a lot to learn, it's conventions are not familiar to a java programmer and when you get stuck, lots of hours fly by.
The best option would be to hire a senior ruby developer to pair up with you and teach you. Be a good apprentice and you'll learn fast. Faster than me, I had to learn most by myself, which is really inefficient.
Good luck!
Check out Playframework. Its fun to develop, and you can use your Java experience to develop features way quicker (given than you have 2 weeks) than any other Java-based frameworks out there.
You do not have to start/stop a server. You fix the code in Eclipse and hit refresh on the browser. No dealing with WAR files till you have to actually deploy in production. Do everything from within Eclipse. Easily perform TDD process if thats what you want as you develop code. From an architecture standpoint, it is a fully stateless, RESTful framework from the get-go. Fully JPA compliant (even for NoSQL like Mongo), so you will not have to write complex JDBC code. On the front-end, it has a full featured templating engine, using Groovy as a templating language.
I can go on and on, but I'd recommend going through the site and take a look.
You should take a look at Grails.
You can continue to leverage a lot of your Java code but use a scripting language (Groovy) and many of the paradigms of Rails. E.g. lots of time saved by using convention rather than configuration.
Grails is used by some pretty big web sites E.g. BSkyB the UK satellite broadcaster.
It doesn't really help with some of the startup speed aspects. If you really prize development speed that much - get a faster machine or buy an SSD and fit in your machine. If you work for a big company - sell it to your manager as the cheaper option (E.g. buy a $2000 machine rather than spend 3 weeks rewriting something to save 10 minutes a day).
Java will scale better in the long run than Rails. The Hotspot technology in the JVM is one of the wonders of modern technology.
Also worth checking out is Tapestry5. It allows you to make code changes on the fly (no server restart required) and is easily the fastest & leanest framework to develop with in Java I've used.
I would still give Spring Roo a shot, it will the same rework as with Ruby on Rails or Grails or even less, but you will still stay with something that you are familiar with, which is often the biggest consideration
It has the scaffolding concepts of Ruby on Rails and Grails, but it gives you zero lock in code, just simple, well written (massive use of AOP is matter of taste though) of Spring + Hibernate / JPA (I think you can use Freemarker for the views, Roo has a miriad of plugins, but I'm not 100% sure)
Is it wise to develop a prototype GUI before designing other part of the system?
I am using Java for this small project. It will be a program with GUI and database connection. Say the database has table A and B, the user can choose which table to interact with. The program then display the contents of, say, table A in the GUI, and allows the user to change the content and submit the changes, or delete, or insert.
I think GUI should be developed first before any back-end development starts. There are couple of reason to do this:
You gain clarity on how model objects should interact.
Usability poses lots of restrictions on the way you want to pull data. You will probably want to develop and architect after you're 100% sure what constraints are there.
On business point, managers like to have a dumb function UI before any development start. Many times, the feedback leads in major changes in back-end assumptions. Which is a lot less pain than the case when you get a change request after the back-end development is over.
My personal experience goes that simultaneous development of GUI and back-end is a bit messy. Plus GUI provides solid expectation of behavior from back-end. Moreover, this approach makes sure all the developers, your client and your manager on the same page.
I agree with Joel Spolsky that it is a great idea to write a functional spec before writing code. Part of that spec should include a collection of screen mockups. #O.D. is right, Balsamiq is a great tool. It has saved me a lot of time in the past.
Once you have a functional spec in place that the business users are happy with, you will then have a better idea of how to design your system to meet the requirements. e.g. is high performance a requirement, domain model vs simple crud etc.
Then you should start by taking a single use case and building a vertical slice of your application. Build a GUI, service layer, persistence layer, database schema in one iteration. This will hopefully point out any problems with your design and give you the chance to modify it before you start building out the horizontal functionality.
I'd say yes and no.
No because you should design you application to be modularized enough so that your logic and data do not depend on UI design.
Yes because it is always smart to design everything before you actually start implementing it.
So what I mean is that you should make a concept, but not let your UI concept 'tie your hands' when you implement your logic. So if your managers clients don't like your conceptual UI, you can always change it without actually changing your application logic.
Well showing you GUI brfore starting to program is a very a good Idea, specially that you enable the enduser (Customer) to check if the UI is up to his expectations, which can save you lots of time.
In order to do that you dont necessarily need to develope a "real" prototype, you can use programms which enable you to fast design the UI of your App, including a minimal workflow simulation instead of full funcionality.
i had a very good experience with: Balsamiq can really recommend it
Writing spec before your code is always a good idea, because it makes you think. But most specs I have seen are not that good. And if the spec is too technical, users will at the end sign-off your spec without really understanding what are they going to get.
I have seen best results when either presenting the User Manual to the client, or by discussing mockups of the system one scenario at a time.
Note that half-baked mockups won't do the trick. You need your mockups to be fully populated with relevant data (Ever tried to discuss some screens with accounting while the numbers on the screen don't match? There's no way at all you could explain to them these are only dummy numbers...)
And the caveat of using mockups is that users will more often than not believe the app is "almost finished", whatever you do or say. It must be some subconscious thing, I'm not sure. But to avoid that, most of specialized tools have either only "black&white" look and feel or multiple skins you can switch to and from.
There is a pretty complete list of mockup tools here. Many of them are free:
http://c2.com/cgi/wiki?GuiPrototypingTools
My own tool is pretty popular: http://MockupScreens.com, I created it a long time ago exactly because of my own frustration with above mentioned problems.
I am looking to start work on a brand-new project, something I've been thinking about for a while as my first independent sellable project.
It's broadly speaking a web-based service application, and my first choice, server-language is quite easy... I know Java pretty well from working on Java web-apps in the past.
However my experience doing web-apps involved JSP, Servlets and JSTL... I know the ideas behind newer technologies like Hibernate/Spring but have never used them. So we wrote our own DAOs, handled AJAX by writing special mini-JSP pages that generated XML/JSON pages, etc.
I'm not hugely into the idea that Spring/Hibernate are the 'only' or 'right' way to do any Java web-project, but they are widely used. On the other hand, not only would trying to learn these increase initial development time, but I'd be using my learning attempts to build a production system.
I remember one of Joel's early articles said (I'll paraphrase since I can't find it)
"regardless what's cool, always use
the technologies that the lead
developer (or dev team?) knows best"
I wondered what people thought about that?
ps: should this be CW?
I work as a consultant, and I've seen a lot of projects where the devs started out with servlets+JSP because that's what they knew, and it's pretty simple to get started with. However, it gives the team an opportunity/excuse to write a platform of their own, which is more fun than using someone else's and just writing an application.
As the project grows, the team reinvents more and more wheels, quite a few of which end up square. That's where I enter the picture - adding new stuff to this semi-flexible platform has become so complicated that the devs can't keep up adding features and fixing bugs without calling in reinforcements. Just to add insult to injury, the internal devs are usually the ones who get assigned to do the boring bug fixes because bug fixes require more knowledge of the gory entrails of what has become the team's proprietary persistence-and-web framework, and so those gosh-danged consultants get to do the new, fun stuff.
Now, you shouldn't use a framework just because people have been regurgitating each other's blog posts about the awesomeness of it, but you should also realize that there are very good reasons why those frameworks exist (and why they're used). If you haven't used any web frameworks at all, I'd recommend you to take Spring MVC, Wicket or whatever for a test drive. They don't solve all problems, and they do cause some of their own, but the grand total is usually a productivity increase, especially if you're making advanced user interfaces.
I have been on projects where plain JDBC has been quite sufficient for persistence, and where no more advanced web frameworks than servlets+JSP have been needed, but those projects are a minority. Without having used a framework or two, you'll never whether your project is part of that minority that doesn't need one, or if it is part of the grand majority that does.
Don't try everything all at once - take on one new technology at a time.
Beware the lure of cool new frameworks! I'm currently hacking on a tiny little web app that just has a login, a few mostly static pages, and a few forms to request some information by email. It would have taken me maybe two days to do as traditional Servlet/JSP in MVC style. Instead, since there was slack in the schedule, I decided to use this project to get up to speed in Spring, Spring MVC, and Spring WebFlow. While it's quite possible that I'm just dense, it took me several weeks to get my head around the right way of doing things, I'm still not totally confident that I'm doing everything correctly, and the application is still not done. Fortunately, due to slack, I'm not in danger of the overall project schedule slipping, but I'm always asking myself if I'm going to have to scrap it and start over.
I have learned my lesson, though: next time, I won't be the one pushing a new framework unless its one I've used for production projects before. That said, I'm glad I now understand Spring (or at least I think I do) and will not hesitate to use it again next time.
So how would I learn a new framework next time? If there's a project lead (in this case I'm a project lead of a team of one, no help there) I'd use the framework that they put in place. If there isn't, or if I want to learn a framework that the project lead isn't using, I'd use it for a side project on my own time. Learning is good. Putting company work at risk by throwing untested technology at it is not so good.
I can say for sure that Spring is worth considering. It gives you as much as you can take, but it doesn't bother you with things you don't need.
For example, at the very beginning you probably need dependency injection only. Then you'll need help with database interactions and transaction management. Then you'll decide to apply MVC patter to your web-application. After that may be you'll realize that components of your system are to send JMS to each other. And so on and so forth.
For all this cases Spring has it's own simple, intuitive, light-weight solution.
When starting a new project limit the number of unfamiliar technologies / frameworks to use. Every framework takes time to learn and every framework has issues especially if not implemented correctly.
If you can I would recommend you look into the Play framework. It is a web framework for Java that focuses on developer productivity. You can choose to use Spring / Hibernate if you want but you are not bound by that. It has a very easy to learn implementation and you should be able to get a good idea within a day of playing around with it if it is what you are looking for.
It depends what the customer wants (in the world of consultancy).
You have to learn new technologies. Does the customer wants to pay for that?
Not all the caveats of the new ones are known, whereas the older ones are proven a lot more.
Of course, if everybody thought like this we would all be stuck with VB these days. You have to look for the right balance, and learn a lot yourself too so you can get an objective view on the technologies available, their up and downsides.
i personally would definitely recommend looking into spring, i've found it's saved me countless hours. hibernate is also useful if you need an ORM layer (and spring has nice integrations with hibernate too). they're certainly not the 'only' or even the 'right' way to do things (that's quite subjective) but they have both saved me time and effort, especially spring.
There is one major trap with any unknown technology. You do not know where the dragons are, and you do not know how to rub the new technology "with the hairs".
Learning that will take time, and you need to have that in your estimates. Also your estimates will most likely be too low...
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.