Articles / Linux Needs Java, and Vice …

Linux Needs Java, and Vice Versa

In October, I wrote an editorial on why VB should not be brought to Linux. One of the key points I touched upon was that VB's strengths lie in its IDE and its ties to ADO, MTS, and now .NET. I said that good replacements for VB were Python and Java. Now I would like to delve deeper into the importance of Java on Linux, and the importance of Linux to Java.

Linux has been used extensively and very successfully as a Web server, but the face of the Web is constantly changing. In its current form, Linux can't compete with Windows without Java on the enterprise level. Many Linux Web servers serve either static content or dynamic content generated via CGI or the popular PHP. Neither of these systems have built-in enterprise functionality. While almost any language can use XML (and in turn use SOAP or XMLRPC to make remote method calls), there is more to enterprise functionality than remote method calls. Enterprise functionality includes remote method calls, load balancing, fail-over, transactions, and a myriad of other stability and scalability functions.

Enter Java. Java already provides this functionality on Linux, without the high price tag of Windows-based solutions or high-end Java Application Server solutions. There is already JBoss, a powerful Open Source EJB server, available for free and completely community supported. Couple this with Jakarta, the Apache Foundation's Java Servlet Engine, and you have an extremely powerful enterprise server. For those who want the safety blanket of commercial support, there is always the Enhydra application server at a very low cost (I believe $99 + support costs). All this on Linux at no or low cost.

There are other advantages to pushing Java on Linux, such as name recognition. When CEOs hear Linux, they might shrug, but when they hear Linux and Java together in the same sentence, they'll start to listen. In the current economic downturn, all companies, small to large, are going to look for ways to save money on IT. Linux can present enterprise-level functionality for pennies compared to the cost of proprietary solutions, which will make any CFO happy.

There is one problem with all of this: Java is not an easy language to learn for beginners. Luckily, no one said you need to know Java to use Java! There are two separations between Java the language and Java the platform. The first is the myriad of languages that will run on Java, the most popular of which is JPython. These languages run directly on the Java platform, and have all functionality of Java. The second is the JNI (Java Native Interface). The JNI allows Java to call native code in C/C++, Python, Perl, or any other language with a JNI binding.

By using a combination of these systems, complex business logic can be built in Java, C, or C++, with interfaces and frontends built in Python, Java, or Perl. This integration allows Web sites and applications to be built quickly and easily in the same component architecture that has served Microsoft so well.

There is a major fault to this whole plan: performance. Java is not exactly known as the fastest system in existence, but the future is bright on this front as well. GCJ, the GCC compiler for Java, is making huge strides. It already supports most of the Java SDK APIs and JNI. It is missing support for RMI and other functionality needed by EJB. Another major problem is that it will only compile programs into a single executable, thus eliminating Java's component architecture.

This is where Sun should come in. Sun now owns Cobalt. Cobalt's servers run Linux. If GCJ can be completed and brought up to speed with Java2, Sun can have high-performance, low-cost Java application servers that can be pitted against Microsoft's upcoming blade offerings. Couple this with Sun's upcoming Peer2Peer services, and you have a software offering that matches and beats anything offered by Microsoft.

There is another reason Sun should work with the community to finish GCJ: C#. Microsoft is basically re-inventing Java on its own .NET platform. Their popular J++ is being geared to be a jumping platform from Java to C#. Sun needs to fortify its position by increasing Java's power and availability.

Finally, there is a reason for Sun to help increase Java's integration with languages such as Python and Perl. VB.NET is incompatible with VB6. VB's terrible OO support has finally caught up with it, and Microsoft had to retool it to be fully object oriented, thus breaking backward compatibility. This is a perfect time to bring VB programmers to Python and Perl, interfacing to the Java platform. It gives VB programmers a simple language to use while also giving them the enterprise functionality they expect with the tools they crave.

All of these pieces fit together to allow a beautiful friendship between Sun and Linux. Once a company is ready to move from small server appliances to enterprise servers, who are they going to call? You guessed it: Sun.

Sun, Linux, and the Open Source Community could make a great team to help extend the causes of everyone involved. Linux finds its way into Microsoft space in the server room as an application server, J2EE extends its position in the face of .NET, Python and Perl find their way into VB's rapid application development space, and Sun increases its revenue and name recognition. Everyone wins. Except Microsoft, of course.

Recent comments

19 Sep 2001 12:42 Avatar fazio

Re: Amusement

> There also potential sucess stories
> brewing with
> the smaller end of spectrum

Right... That's exactly what you all have been saying for 6 years. I'm still waiting.

14 Aug 2001 10:44 Avatar coder111

Re: Java's way of preventing extra costs
% Also, do you have any experience with
> how gcc-java executables performs
> compared to running in a JVM?

I don't have any experience with gcc-java. I planned to test it as soon as I find time, now when gcc-3.0 was added to debian/unstable.

So far speed of java language was good enough for me, so I wasn't looking for improving JVM. Usually some optimizations in application improve speed more. I am writing web applications, and the biggest speed problem here is Apache-Tomcat. F.e. resin is much faster, but it costs money...

12 Aug 2001 16:00 Avatar olsner

Re: Java's way of preventing extra costs
Couldn't agree more!

I have also come to the conclusion that development time and maintainability is often more important than running performance.

Development speed and maintainability are Java's great strengths. This (I think) outweights Java being so slow.

I would like to know what you think:
Is Java so much better developing in than it is slower?

Also, do you have any experience with how gcc-java executables performs compared to running in a JVM?

10 Aug 2001 15:45 Avatar coder111

Re: Java's way of preventing extra costs
I agree.

***Think "Extensibility, Maintainability, Stability" when choosing programming language***

Java is simplified version of C++, and that pissed me off when I started coding in Java, but it has some advantages. First, it is EASIER (read- CHEAPER) to code in Java than in C++ (I don't know about perl or PHP, I don't think anyone has done any studies on the subject). Managers used to say that it takes 1-2 years to become a Java programmer, and it takes 3-6 years of practice to code in C++ well. And so code written in Java is 2-3 times cheaper than that written in C++. Also, Java code is much more easy to read than perl or C++, that means it is good for large projects that must be maintained a long period of time.

Second- speed. Java might be slower than C++ (maybe slower than PHP or perl in some cases), but usually the slow part is the JVM startup. Also- Swing is quite slow and uses a lot of memory. But making web applications with Java where it does JDBC and some String crunching is fast enough for most situations. But the biggest problem is not speed anymore- it is about how fast you can CODE it and.

Third- OOP & OOD. The reason I dumped perl and PHP (I use it for some quick & dirty scripts, but not more) is because of poor support for object oriented programming. Try implementing a few Design Patterns and you will see what I mean. And I have already given up writing bigger projects without OOD. Java is BASED on objects, and it encourages strong OO Design even if you sometimes don't want it.

Fourth- class libraries. Java has strong API. Well, perl has good support here too. C++ is different matter. Most of libraries are C, and quite a lot of C++ libraries are broken or offer not sufficient features. Java libraries are usually enough to do the job. And writing web applications in C++ ://// Tell me if you know any frameworks for this.

Well, I think that should be enough.

07 Aug 2001 18:42 Avatar liver

Re: Enterprise?

> Well, I did not want to *insult* anyone;
> that's why I enclosed the text in
> Pascal-style plus wink-n-smile-in/out
> comments.

Oh, i thought they were little guru-with-turban
emoticons :)


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.