Why Java is Just Fine for Your Online Service Development

DZone 's Guide to

Why Java is Just Fine for Your Online Service Development

· Java Zone ·
Free Resource
There is a discussion going around according to which Java/J2EE is not an appropriate development platform for startups creating online services. This argument is repeated again and again - for example on answers.onstartups.com How to pick a platform for a startup web 2.0 app?
stay away from J2EE. J2EE is too heavyweight. Takes too long to develop. Its great for consultants because it means more billable hours but not good for nimble startups
Java is too expensive. Higher initial investment for hardware, human resources, and too much code to write to do just simple thing. A startup can't afford it.
I hope to show in the following that this is simply false.

The origins of the commonplace

As with most commonplaces, they are simply the repetition out of context of something true in context. All those who have followed Java and its evolution over the last ten years, have seen the coming and going of many architecture astronautic – inspired frameworks and fashions. There has been no lack of context where Java has been and is used in absurdly convoluted ways; but this is history - boring, and by now not very interesting.

Of course the point is that there is nothing in the nature of the language and tools that forces you to use complex solutions. My point is the opposite of the commonplace: if you have Java expertise, you are in an advantageous position to start developing an online service. Using Java for your online service will lead you to a change of focus from corporate development, together with a complete revolution in marketing strategy. It is likely that the business logic involved will be relatively simple, you won't need to redistribute your code, you won't need say to certify it for some complex pharmaceutical software standard; other different, complex problems will come to the surface. But this will happen whatever language / framework you are using.

A pragmatic attitude

The quoted common places assume that being a Java programmer simply means the lack of pragmatic sense; but why should that be? Surely there is no entailment there. Lets tell a few simple facts that most experienced developers are perfectly aware of, but don't say in conferences: you can write excellent applications and never ever write a single line of unit testing and Javadoc. And put all the time you saved from writing and fixing bugs in the unit tests ( :-D ) in having human testers try your application, and in this way get feedback worth a million times what your own self-test would tell you (assuming optimistically that the code-based tests are bug free).

Also human users will tell you about interface bugs that no code test will ever do, like about the dark gray buttons on a black background, or the unpredictable series of clicks ad which users find so intuitive and code tests will never cover. You can be self-satisfied with your unit tested and JavaDoc-umented code (remembered to update it all by hand after the last refactorings and fixes?), and release a totally unusable program filled with what look like serious bugs for the user, though you didn't perceive them as so.

Having a firm pragmatic and user oriented attitude is not at all in contrast with using Java for development: you can be a talented duct-tape programmer, and indeed use Java. We should all be grateful to the dynamic language communities, that with their repeated successes have shown that the "king is naked" and self-referential practices of formal code quality or blind following of methodologies valid for over-ruled corporations are useless advice in many environments, and that a more socially oriented testing and user interface design is what wins for creating online services.

But I believe the development language involved is accidental. There are all sorts of tricks you can use in Java to avoid complications: as class reloading may cause the web server to drop sessions, you may simply publish some experimental business logic in an included JSP file – yes, as simple as that. Having "duct tape" capacities is not language-dependant, and if on top of your pragmatic skills you use Java, you'll be perfectly fine. Note that I am not saying that the development language choice is a crucial step in you startup path (hear the end of this podcast for some wise considerations): I'm just saying that if you have Java expertise, use it, and you'll be fine.

Online in three months

As a concrete example, working in Java, having a considerable experience in Java web development (we develop Teamwork), and using the simplest solutions and the best tools available, we developed two online services from scratch and put them online in three months, with 2 people working for each service and one person shared between them. The services are:

Some of the work done for development and marketing is presented here. Anyway in this post the focus is on whether Java helped in the process, or it was a hindrance. Notice also that the server side development is more and more a fraction of the total development needed; as you can see in the example services above, the design and UI/JavaScript part is getting more and more important.

Java's comfortable world

If you are a Java developer and are thinking of dropping it, think carefully before you do so. There are many features that you may assume as "obvious" which are not at all available in other environments. A few examples:

Choices. In the Java world we are happily used to having choices; that is, for a well defined common problem, not only will you often find a solution, you most often find more than one. This is in stark contrast with "canned" environments.

Refactoring. You take Java's clear syntax for granted, and all the advantages of its static typing. If you are fascinated by dynamic injection, consider for example that you'd simply have to drop your trust in refactorings to work, which with Java (and Intellij :-) ) is close to certainty. And this may mean a shift of focus from the core of your problems to… find-and-replace by hand, a reversion to stone age code writing - sounds silly enough. Java core is stable, and basic signatures can't be overwritten: in many case, this is a quality. Listen to this very interesting Java Posse podcast for competent discussion of Static vs. Dynamic Typing, which will help you get a clear picture about the myths of dynamic language productivity. The largest server side development community you can get. That's a simple fact. See this and this, for example.

Good producer support. Server side Java really runs well everywhere, and also is fast everywhere (see e.g. Twitter: Service vs. Platform), and keeps getting faster; with today's servers that is not that relevant. Anyway, it feels good to know. Being fast, no great hardware support is required, which is the opposite of the commonplace quoted in the beginning. If you are using a relational database, all the components scale, with well known and documented practices.

A real virtual machine. Virtual machines should run on all main OS out there, and with identical functional coverage. Otherwise its cheating. All this makes Java a great platform for almost any kind of development; but lets see some specific needs for online services.

Some positive examples

Lets see how the Java platform, available APIs and some tools developed by us along the way can help you in several concrete cases. While developing your new online service you will probably need to meet these or similar problems along the way, which you will hardly have met doing say intranet corporate development:

  • Cross-site scripting See a definition here. Examining these kinds of problems, we put together a quite complete Java HTML sanitizer here, which everybody can freely use. The development process is described here
  • Cross-site request forgery See a definition here. - Filtering spam For this there are many solutions, see this one for example: http://www.theserverside.com/tt/articles/article.tss?l=UsingCI-Bayes We are experimenting using an online service; the nice thing about using Java is that because it is so widespread, everybody provides the Java stub for their services, ready to use. 
  • Exposing a (RESTful?) API Here our solution is under development (but almost there), in our experiments we are using JSON-lib.
  • Configuring/scripting your service A (great) example where we used the power and openness of Java to "talk" with a wider audience is in BugsVoice rule scripting language, which is simply JavaScript; given the large and cross server-platform competence in JavaScript, it is the ideal language for letting a wide audience script your application. See here for details. 
  • Integrating Open Id We use openid4java, but of course here too there are plenty of choices.
  • Talking with Google applications, Twitter, ... . Here too the fact that everybody is exposing stubs for Java is just great, and saves a lot of time. 
  • Full-text and even smarter searching Lucene here is the framework to mention. Actually there are many cases, in particular in online services, where full-text search is not enough; never tried Google? So we did some work on this theme too. Here is a quote from Smarter search and recent object functionality :
Here we examine a technique to improve usability in complex applications by introducing smarter search and “recent objects” functionalities. As usability becomes more and more a crucial feature of applications, helping users with full-text search and recent object lists may still prove insufficient. You may need to go beyond these features, by having a way to keep track of “most used” objects, which will help to: - guess what you are looking for - find what you are searching for

(Some links on this problem:


The basic question is: does the Java environment help solving your real problems, apart from any architecture astronautic fad? I hope that the examples above.

From:  http://pietro.open-lab.com/2009/12/05/java-is-just-fine-for-your-online-service-startup-development/ . It was also discussed here.




Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}