My biggest problem with java is not the language itself. Just as perl, it serves a market, and the language is grown-up enough to be useful.

What makes me hate java to the bone has nothing to do with the end product: what the customer will see, but is all about developer time.

• (Big) java projects seem to need an IDE (Eclipse or NetBeans mostly). These have their own quircks and shortcomings (a lot). They also have their own key bindings that most likely are very different of those of your favorite editor. I'm currently forced to use Eclipse for java development, and I don't know if the designers of the UI ever programmed themselves. I use more time searching for functions and features than being able to actually produce code. Netbeans works much better for me, but neither has good integration with git and Eclipse integration with svn is much better than NetBeans' (but still sucks big time).
• CPAN might cause some administrators headaches, but java libraries (.jar files) and version requirements are even worse. Some people do not care about compatibility at all. Neither forward not backward. To make a big project work, it seems to be necessary to use maven, which is another reason to use Eclipse, which seems to have better maven integration than NetBeans (or my colleages refuse to make it work for NetBeans).
• The resulting applications (.jar, .war) are huge compared to perl scripts.
• You cannot edit a jar that is broken at a customers site when dialing in. A perl script is often easy to fix.
• It eats developer time. I can write something in perl in 30 minutes what will take me a day in java. And when I hit a problem in one of the used modules, I can fix that myself, submit a RT ticket with the fix, and be happy to see a new moduyles released soon. Fixing a jar error is close to impossible.

Performance-wise, java seems to be able to match perl in many aspects nowadays. You'll probably be requiring java6 and a lot of memory, but database access is well supported from java's point of view.

I agree that client that want java over perl for no reason are stupid. There are however enough reasons for some client to choose java. There is a perfect tool for every problem, and that tool is not always perl (but it quite often is).

For some odd reason client wants to switch to Java.

Maybe you should try to talk to the customer, find out why she wants to switch, and maybe explain that since you know Perl better than Java, development in Java will take longer.

There are reasons why some people don't like java, but most of them are rather technical (for example that you need much more code to express something than in Perl, and some oddities like type erasure), but they are typpically not what a client is interested.

Typically clients want to have a product implemented in a way that's fast, cheap, reliable, finished early, easy to maintain, easy to find maintainers for (that's probably easier for Java than Perl, given the shear amount of Java programmers) etc.

You can use the knowledge for your own ends, and argue that you have better Perl expertise and than Java; however that might backfire if the client doesn't want to make a compromise, and rather choses a different consultant.

Reasons to prefer Java over Perl:

• You want to use a fancy library which is available in Java, but not in Perl
• Your client pays for Java, but not for Perl, and you need the money
• You want to run your application on many platforms without requiring the user to install Perl (assuming that most people have installed jvm anyway)

• You don't depend on the money and your client doesn't want to loose you as a programmer
• You tell the client that in order to switch to Java, it costs so much more money to recode everything, that he could for the same amount spend three months in a whirlpool in the Emirates Hotel in Dubai

Perl is very fast and uncomparable

"Uncomparable" definitely, but "very fast"? ;)

we have faced no issues what so ever

This must be the first project in the world without issues!

We know that but client doesn't understand it

What have you tried to make the client understand it? I would like to know the reason behind changing to Java.

You mention nothing about the size of the project. A database, SQL queries and file validation doesn't sound too complex. What type of client are you looking for? Will it be a web-based system or are you aiming for a rich/fat-client? How many (concurrent) users? How complex is validation of the flat files. etc. etc. In other words it is impossible to make a proper judgement wether it is justified or not to change to Java. Depending on the complexity it might be an unrealistic amount of work to rebuild the system, that would be a good argument not to do it.

Can Java match Perl to do the database related tasks as easliy as we can do in Perl

Yes, I'm convinced about that. Database communication is done through JDBC but it doesn't stop there. You can do it the old-fashioned way and write SQL code and execute it, or use the new approach utilizing the JPA (the Java Persistence API) and maybe JTA. You don't have to write any SQL code. The object-relational mapping, generation of the database schema etc. is all handled by Java for you. I especially like the so-called "named queries". You work with tables and records like they were (collections) of objects.

If the project is not too big and you have to change to Java I would simply go for the Apache Tomcat a few JSPs/servlets and mySQL or Javadb. This works for small to medium sized applications. If you want scalability (think thousands of users and many concurrent users) or if you need some of the features that go with it you might consider using an Application Server. As the system gets bigger or more complex using an AS makes sense. I have good experience with Glassfish. But beware, Java EE 6 is a complex beast. 28 specifications for the proverbial everything but the kitchen-sink. It's a very powerful environment but has a learning curve. Although it has been simplified recently it's still complex (IMO).

Cheers

Harry

Bean envy?