Java development in a Perl shop: How to select the right tool?

Question

My group is a Perl shop in an organization that is very heterogenous. Although we support the odd Java, PHP, or Python installation, we're using Perl for nearly all of our web applications and systems/data marshalling tasks. All of our boxes are Linux, although we interface with IIS systems as well.

We're coming under some pressure from management to move to Java for at least some of our work. I'd like to use the right tool for the right task, but for our work, and due to our collective experience, Perl seems like the right tool for everything.

My initial thought is to use Java for applications that are open to the organization at large, since there is more Java mindshare out there than Perl.

Does anyone have similar experience? If I'm given the choice, what kinds of tasks should we start with applying Java? What kinds of tasks should we insist on sticking with Perl? Does it make any difference? Why or why not?

Answer 1

If your team is going to be supporting the applications, then stick with what you know.

If another team is supporting your apps then you may need to consider Java as it definetly has a greater penetration in today's corporate world.

Management are told that Java is the only way, or "real enterprises use Java", and therefore they think they have to use Java. I know where I work they think that Java is the only language out there, and things like C# are just for 'tactical' projects and not 'strategic' - whatever that means.

You should use the best tool for the job.

Answer 2

Is there a specific technical reason for switching to Java? Is there something you can do in Java but not Perl? Is there a performance difference? Is some other group/person all about Java and doesn't want to learn Perl?

My experience has been that you should stick with what you know. Your group knows Perl really well. You've had your share of teeth gnashing and some of you have probably attained uber Perl guru status.

So I'd say stick with what you know unless you can think of some good reasons.

Answer 3

I ran into the same scenario with my former company. A little different in the fact that we wanted to go Java and move away from Perl. Our Perl was having performance issues and not scaling very well. Also our user management was a mess. We moved to Java and used some of the Single Sign On features and we were quite pleased with the results. This may have been more of a case of moving out of legacy code that was written very long ago.

Answer 4

If you'd be allowed to move to something Java compatible, yet has a syntax that's at least closer to Perl than Java, check out Groovy. Groovy is a dynamic language that compiles to Java byte-code.

You can code in either Java-ish class and functions, or Perl/Ruby's dynamic "scripts"... or both.

Answer 5

I would suggest that if the reason you're being pulled away from Perl is because of performance issues, then I would push to just rewrite in C as Perl XS modules the parts of your application that would benefit from it most, rather than move wholesale to a new development environment. I work in a mostly-Perl environment, but key parts of our system were rewritten in C and C++ to satisfy performance requirements.

Answer 6

I've been through this where I work, It can be a very painful process.

If you have a good Perl team, then I'd recommend resisting. There is very little that decent java can do that decent Perl can't. The only valid reason I can see for switching is if you are having difficulty hiring decent Perl coders.

At the end of the day, if management are pushing it, then there isn't a lot you can do, except try to find out why they are pushing it. The amount of acceptance/push back from your team should depend on the reasons.

If you do move to java, I suggest you make sure you hire someone who knows what they are doing in java (not just knows the language, but knows the frameworks and application servers). Its not magic, and its just as easy to make crap applications in java as any other language, it will just take you longer.

Answer 7

Management :-(

Give them a cost/benefit analysis of switching to Java. Explain that the WHOLE development team feels this way.

Answer 8

The benefits to Java aren't in the language per-se but in the supporting infrastructure around it. The class libraries are one thing but then you look at the application servers, messaging infrastructure, open source libraries and frameworks, the list goes on.

So, pick an area and do some research. Have a look at source forge, apache, codehaus, java.net and Google. Find the libraries and frameworks that suit the problem and see if they are going to reduce your development costs. Have a look at Spring, Hibernate and Struts2. Have a look at the IDE options and see if they will make you more productive (Eclipse, NetBeans and IntelliJ IDEA are the frontrunners). Listen to podcasts like the Java Posse to get ideas and read sites like Java World, InfoQ and The Server Side.

Sooner or later you will come up with something that you can see is going to save you time and money and when that happens dip your toe in and give it a go. If it doesn't go as planned figure out why and do better next time.

If you have a candidate and are bewildered by the array of library, product and framework choices there are plenty of experienced Java developers on stack overflow who are willing to provide guidance.

I hope that this helps.