What are the differences using spring boot with Kotlin and with Java?
Kotlin is among the three languages you could choose to start your app with https://start.spring.io. So it's supported by the spring boot team. I used it to develop some microservices and as far as I know everything went fine at the end but I would like to have some feedback from other developers because I try to convince my new team to start our new microservices in Kotlin.
Pros:
Null safety
Clearer code
Val over var
Cons:
Mockito not Kotlin friendly (I switched to mockk)
Code coverage was not out of the box (we had to develop our own plugin)
Risk to have Java moving faster than Kotlin
Since Kotlin is simply a dependency and plugin for Maven (that's it!). It's such a nice, compact, easy-to-grok language that removes all the syntactic fat (opposed to syntactic sugar) that Java provides.
From 5.0.0 onward Kotlin has first-class support from Spring, which effectively means it has all the same guarantees as Java in terms of code working correctly.
Kotlin itself has a ton of interoperability features to smoothly integrate with any already existing Java library, which means you have the same freedom of choice.
Kotlin's Java interop is amazing, and was by no means an afterthought by Jet Brains. Thus Kotlin works nicely with Spring, which provides a lot of the boilerplate functionality for web applications, especially Spring Boot.
These are some points which You already mentioned but I will still have a say about it. Kotlin has a much more compact syntax and its type system allows for much more robust code through null-safety, sealed classes, and immutable/mutable collection distinction, which together significantly reduce development time on any project.
The main difference is: with Kotlin, you're programming in Kotlin...with Java, you're programming in Java. Spring makes use of some languages features exclusive to Kotlin to streamline certain operations, but I wouldn't think you'd want to choose one language over the other just because of those few additional benefits. For the most part, there is no difference. Spring supports both languages well.
UPDATE: I guess I should add that Kotlin does introduce a few minor problems into the whole Spring thing, just because Spring is actually written in Java and was originally designed to be utilized via Java. But just like the pros you get with Spring and Kotlin, these minor negatives should likewise not dictate your choice as to which language to use.
I think what you should be asking is "which language should I use leaving Spring out of it?". My company is coding new modules in Kotlin because we consider it a significantly better language than Java. But we have lots of legacy Java code, and we've chosen to for the most part not mix languages within a single module, so we still code in Java too. You have to make your own decision. Decide what language you want to program in based on the language itself, and on your existing codebase, but not on how Spring works with it. Spring will work great with either.
There are many articles and blogs out there comparing the two languages, listing their relative pros and cons. I'd suggest that you read everything you can. There's no "right" answer here. (...which is why I know this question is going to be closed as being opinion-based). Try Kotlin. Heck, try Groovy and Scala too. "live" the pros and cons for yourself, and then decide what will work best for you.
BTW, you list "Risk to have Java moving faster than Kotlin" as a Con of Kotlin. I think the risk is in the other direction. Java moves very slowly compared to Kotlin and other alternative languages. That's why you see it playing catch-up...finally introducing features into the language that have been in the alternative languages for many years.
In web development we use java .net or php5 .
All are OO. and have all the OO features.
But in real time websites do these OO features play any major role other than inheritance.?
Can anybody list some with real time examples.
In application development there may be a vast use of OO.
But in case of websites, does OO playing a major role?
How?
Back in 1995 the book Design Patterns managed to produce this phenomenal insight on page 20:
Favor object composition over class inheritance
Since then, proper object-orientation has been about that instead of inheritance. Particularly, the SOLID principles describe a set of principles for object-orientation that are applicable for any code base where maintainability is important. Polymorphism is important, but inheritance is irrelevant.
That applies to web applications as well as any other type of application.
I make heavy use of encapsulation and polymorphism. Specifically I use the Strategy Pattern (among others) pretty heavily to compartmentalize a great deal of my functionality. When combined with dependency injection, it makes it really easy for me to separate functionality of say, my persistence layer, from my business logic or presentation layer.
For instance, it's trivial to swap out a hibernate implementation with a JDBC implementation, etc. Actually, recently, I just switched from an e-mail service that operates synchronously with the web request to one that uses a message queue to asynchronously send mail. All I had to do once I'd implemented the new layer was change which class was injected into my beans that use it.
Edit: To address your comment, #zod, I don't use it so with with regards to the pages that are executed although that does happen from time to time (for instance, I have different classes for HTML email and plain text email depending on what the user has requested) but I primarily make use of the OO principals in the configuration of the application. Does that make sense?
As a start, the main principles of OO come in handy.Take for example data encapsulation in an MVC pattern; The fact that you can have a User model that does all the user stuff means that everything that has to do with users is encapsulated in that one model. This makes it easier to add and modify features later on. The extensibility also comes in handy when you want to extend your program with the code other people have written. As long as you know the public interface of their classes, you can use them.
TO give a simple example we as a company heavily use it for security. We have plugins for various frameworks that controls who tries to reach which class and method. In addition to that we can avoid user to reach that class and method without adding extra lines to class.
Other than that we are using them to clarify the code as well.
Beside all of those doing OOP is good way to create a big project with a big team.
I am investigating the use of web frameworks with my Java web-app. My basic requirements are pretty much easy maintainability, testability and no repetition.
I have explored writing my own MVC-type app using some sort of front controller pattern and JSP's for the views. The benefit of this is that I have complete control of all aspects of my web-app and if I design it properly it should not be hard to move it over to a more tested framework in the future if I so choose. However, the con is that I have to reinvent the wheel so to speak.
I hear good things about the currently available web frameworks. Some technologies that I have been looking at are Spring, Wicket, Struts, Guice, Hibernate and Tapestry.
I am a bit wary of Tapestry and Wicket. I dont know TOO much about them but they seem to deviate from the servlet->model jsp->view formula. I am not sure if I am comfortable with that. Although, I hear that Wicket is actually the best fit with Guice and is extremely testable.
Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?
I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package.
I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs.
I also have never really used Guice but people really seem to like it, and I am a fan of DI in general even though I am not sure how it is used in an actual application.
Basically, I am only really confident with writing Servlets / JSP's. I am not opposed to learning alternate technologies but I am looking for advice as to which ones would REALLY benefit me.
If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring? Or should I just use Servlets / JSP's and incorporate a DI engine like Guice?
I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex. All I am really looking for is a way to map my POJO's to a database, so if there is something better/easier to use I am willing to look it up.
I am feeling lost and am looking for a bit of direction from people knowledgable in the area, any opinions on any of these issues would be hugely appreciated. Thanks!
"Spring seems like it could be a nice fit, but I am very wary of frameworks which attempt to do everything. I would love to use spring-MVC, but can I swap in other components? Can I for example use Guice as my DI engine while using Spring-MVC as my framework?"
Agreed Spring provides a lot of stuff, but it's totally modular. You can use DI with or without AOP and so forth. And yes you can use Spring MVC and Guice for DI together.
"I have briefly looked at Struts but it seems overly complex for my needs and again seems to be a complete package."
I have used Struts for quite some time now, but even when I started using it, I found it easy as a breeze. The controller might seem overwhelming at first, but you will have real fun when you get the hang of it. The best way would be taking a look at some real world examples using Struts.
"I've never used Hibernate, but it seems to be the standard for ORM and if it's anything like ActiveRecord (which I have only been exposed to a little bit) I am sure it fits my needs."
Oh then if you found Struts to tough, Hibernate is huge. It requires a big learning curve. It pays at the end, but if you know ActiveRecord, I will suggest you to stick to it before you get a good amount of knowledge of Hibernate.
"I am pretty sure I would like to use Hibernate for ORM, but I hear it can be pretty complex."
IMHO, very true...at least for beginners. (Anyone suggesting a change here?)
"If I can make an MVC app using Servlets and JSP's is it worth it to incorporate Spring?"
You mean without Struts or any other framework? How?
Seems like you are trying to take on too much too fast. Try considering one thing at a time. DI itself is a tricky thing to implement in real world. Oh yes conceptually it's great, but what I mean is you need to first get a hang of things one by one.
Very simply, if you are comfortable with JSPs and Servlets, then if you want to save some of the drudgery of web programming, I would look at Stripes or Struts 2.
I am very familiar with Stripes, and only am aware that Struts 2 is similar, so I will focus this entry on Stripes.
As an aside, Struts 1 is worthless. It offers no value (frankly).
Stripes has several features, but I will focus on only a few.
The primary value of Stripes, and if this were it's only feature it would still be very valuable, is its binding framework.
Binding is the process of converting the requests string values in to the actions values. Stripes does this amazingly well. Specifically, Stripes binding does very well on nested and indexed parameters, as well as type conversions. You can easily have a form field named "currentDate" and then have a "Date currentDate" in your Action, and Stripes will "do the right thing".
If you have a form field named "mainMap['bob'].listOfThings[3].customer.birthDate", Stripes will make the map, create the list, create the customer, convert the string to a date, populate the birthDate, put the customer in the 3 slot of the list, and put that list in the 'bob' spot of the map. (I do stuff like this all the time.)
The binding of requests to Action variables is just wonderful.
On top of that you get, if you use their form tags, you get nice behaviors when, for example, they put "Fred" in your date field. You easily get the form back, with Fred in the field, and a nice error message.
Finally, I really like their Resolutions as a result from their Actions. For example, a ForwardResolution to forward to a page, RedirectResolution to redirect to a page, StreamingResolution if you want to pump data down the socket, etc. It's a very elegant feature.
Stripes has all sorts of power and does all sorts of things, but those 3 pieces are what make it best for me, and what I use 99% of the time.
Simply, it really stays out of the way and readily handles the "plumbing" without completely obscuring the HTTP request nature of the system.
For someone who is content with JSP/Servlets, Stripes I think is an excellent step up as it adds good, solid value with very little cost (it's simple to set up) and without having to toss out everything you already know, since it works just great with JSPs and JSTL. Learn the simple mechanism it uses to map Actions to URLs, and how simple it is to map requests to your actions, and you'll be flying in no time.
Works great with Ajax and the like as well.
The question illustrates some confusion. I think the definitive answer is "no, it is not possible to use a web framework but not be dependent on it".
But your instinct is good. You want to maximize the general benefit a framework provides by helping to properly layer and modularize your code and minimize its invasiveness.
With that said, I think Spring is the winner on both counts.
If you follow the Spring idiom, the structure of your code will be better by the use of interfaces, layering, and aspects. Some of the attention they pay to design is bound to rub off on you. That's as helpful as the good plumbing code they provide.
Your code base does not have to be 100% Spring. I've seen Spring used in enhancements to legacy Java apps that weren't rewritten from front to back.
Struts tends to not be a good choice because it is JUST a web framework. It encourages you to put all your processing in Action subclasses, never to come out. Spring injects the idea of a service interface that decouples the web tier from the back end. It's easier to swap out web tiers and expose the service as SOAP, RMI, EJB, or remote HTTP call.
Hibernate is far more complex than Struts. If you choose Spring, use persistence interfaces and start with Spring JDBC. When you're ready for Hibernate, you can always write a new implementation and simply inject it into the place where your JDBC version used to be.
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
CherryPy and Cerise are two small frameworks that implement nothing but the barebones of a web-framework and I love their simplicity: in fact I reckon that if Classic ASP was implemented that way (and didn't pretty much require VBScript) I could have settled for it and lived happily ever after.
But now I'm living at the borders of the Java world and would like to know if there's something similar to these 2 frameworks and that doesn't try to take control away from you. My requrements would be that they have an:
a dispatcher that maps urls to methods (like CherryPy, Django, Cerise, Rails, etc...)
bonus points if it has a simple, yet powerful templating language (a la JSP/ASP) that is not too religious in separation of concerns
bonus points if it has some sort of library that helps in validating forms
Thanks
--
Stripes
URLs to methods, check, form validation, check. Powerful but stays out of your way unless you need it.
OOWeb, essentially a port of CherryPy.
Groovy and Grails. If you like MVC or even have a existing library written in Java/JVM, that are the tools you're looking for!
Grails aims to bring the "coding by
convention" paradigm to Groovy. It's
an open-source web application
framework that leverages the Groovy
language and complements Java Web
development. You can use Grails as a
standalone development environment
that hides all configuration details
or integrate your Java business logic.
Grails aims to make development as
simple as possible and hence should
appeal to a wide range of developers
not just those from the Java
community.