Pietro has posted 4 posts at DZone. View Full User Profile

Why Java is Just Fine for Your Online Service Development

12.20.2009
| 7050 views |
  • submit to reddit
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
or
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:

Conclusions

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.

 

 

Published at DZone with permission of its author, Pietro Polsinelli.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Martin Wildam replied on Mon, 2009/12/21 - 6:28am

You are somehow confirming my own thoughts - I am still quite new to Java (because of a lot of legacy projects my switch to Java is slowly proceeding), but I already noticed, that you don't need a full application server stack (or even more with Spring or templating frameworks). There is even a simple webserver included in the standard edition (Java SE), so you could even completely omit the application server.

It seems to me that Java historically was used first of all in big companies with heavy data load and high importance of stability and reliability. But this does not mean necessarily that for "smaller" solutions the same massive software infrastructure must be used.

The only problem I see sometimes is that many automatically think of the full stack when thinking of Java.

I also think that Swing can still make much sense - the run to web applications for any type of app somehow seems a hype to me. On my Linux box installing applications like Freemind is just a search in the repository and then one click away to install. Why doing this over the web? - But there are web apps for mind mapping also - even for rental. That simply does not make sense - not everything must be a web app!

Luciano Vernaschi replied on Tue, 2009/12/22 - 5:18am

Couldn't agree more. I work in a company that uses .NET only, and Java keeps being my tool for free time development. It's perfectly enjoyable, I like other languages too (especially JavaScript), but I use Java since 1.0 and I keep feeling at home with it, even of the smallest project. The only real drawback is the lack of cheap hosting choices.

Stefan De replied on Tue, 2009/12/22 - 7:59am

i agree to some extent, but you didn't mention the cost of hosting Java based apps. let's look at these comparable web frameworks: Grails (Java) and Django (Python). Django will run on 30MB, while Grails will need the double. and this comes with a price. and there are more reasons why Java hosting is more expensive.

also, when it comes down to development, for sure, you can use class reloading so you don't have to restart all the time (i used it in Tapestry 5). but restarting itself, which is sometimes necessary still takes a while. compare this to Django, it is started in a second.

so, in general, you are right, you could do it in Java. I like Java a lot (because i knw it better), more than Python, so I would love to use Java for these kind of apps. but when it comes down to business and money, you should be pragmatic. if both frameworks offer the same functionality, then the most sensible seems to pick the solution which is the cheapest in the end.

btw, i write tests so a complete regression test by my users is not necessary and so they can focus on what testing stuff that is better done by humans. again, this saves time and money.

Pietro Polsinelli replied on Wed, 2009/12/23 - 3:25am

@mwildam: You are probably right for the historical point. For the run to web apps, I would think twice before creating a new application in Swing. It is not that there is a run to web apps; the run is already completed.

 @Luciano Vernaschi and @kodrbee: For the point about hosting, I agree that it is harder to find cheap hosting. But if you offering an online service, you have a single server (or set of servers) to maintain, and the point about memory is not relevant: in the whole, the cost of memory is practically zero. Patapage is on a Debian server on Rimu hosting, and there has been quite some traffic on it, but the memory usage of the 2 GB available is below 8%. The cost you should worry in this cases is bandwidth, not memory.

Thank you all for the interesting remarks.

 

 

Martin Wildam replied on Mon, 2009/12/28 - 3:54am

@ppolsinelli: In the link, you posted, a big reason mentioned is that on the web your app has easiest deployment. Please keep in mind, that not all OSes have a crappy application management. On my Ubuntu desktop a locally installed application is just a few clicks away. And I can decide when automatic updates to run. If I am on mobile with slower bandwith I am really happy for just getting data transmitted and if I can postpone updates in that case (BTW: There are countries, where a pretty big amount of users surf the web mobile). And with limited bandwith you can see the difference between just loading data or a complete application over the web.

But even on crappy OSes, a Java desktop application is just copying a single jar or a single folder. This is easy installationas it was a long time ago and the kids from today even don't remember that it could be so easy.

And there is Webstart. So deployment should not be the main reason for deciding between web-app or not.

Apart from this it seems clear that in times where social networking applications boom (or let's say, the boom is already over), those are written as web apps because a web app is best fitting in that case. (On the other hand, nearly nobody has problems installing Skype -  also a desktop application - and what is with all those file sharing clients...)

And I also completely disagree with the "least power" rule and Atwood's Law - these are just statements as anybody can mention taking a look into the glass sphere and guessing.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.