NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
I read an article this morning titled
Use Java to Improve Drupal's Scalability
. Geert Bevin was experiencing problems with Drupal scalability because of the fact that Drupal uses the database for caching, and PHP is incapable of preserving object state across requests. So he decided to experiment with clustering Drupal using Terracotta under Caucho's Quercus, which is a Java implementation of PHP that runs under Resin. Although he did run into a few snags, he was able to resolve them and now is using Ehcache as a Quercus module along with Terracotta to cluster Drupal cache entries.
This is the latest interesting example I have seen of applications written using technologies other than Java, ultimately being run under Java to improve their scalability and performance. And it seems the interest in running applications not written in Java under the JVM is growing very rapidly. It wasn't that long ago (three or four years maybe?) when one of the biggest complaints I had about Java, and one of the things I thought was holding it back, was that you only had one real option for writing your application. And that was Java itself. There didn't seem to be a lot of interest in running applications written in other languages under the JVM.
Today, however, this seems to be all the rage. It's possible now to run everything from PHP applications, to Ruby on Rails applications, and even .NET applications under Java. And in all three of these cases, the applications generally perform better running under the JVM than they do in their own native environment.
Whether for performance or scalability, or to take advantage of the huge number of Java libraries available, interest in running non-Java applications under the JVM is higher than ever. Is Java quickly becoming the one platform to rule them all?
There is a cross compiler that converts CLR bytecode into Java bytecode, and reportedly this makes applications run faster than of .NET (where they are developed).
There are at least 2 Java operating systems (which are toys like Linux used to be once): JX and JNode. The other day I read IBM was trying to do the same. And BEA has its LiquidVM which does not need an OS, but runs on top of VMWare.
Also there is JPC an x86 emulator written in Java: http://www.physics.ox.ac.uk/jpc/Demo2.html This means you can run your favorite operating system on top of Java or even in a web browser.
This TerraCotta/Resin/PHP is so exotic, it's impressive and concerning at the same time. The JVM may be "THE" platform, but I couldn't imagine successfully selling this to the IT higher ups where I work.
This is an interesting question and imo points to the fact the JVM is pretty damn good,
but java the language or more precisely some of it's frameworks are not as productive as some of its competitors.
Hopefully, the community will continue to move toward productive frameworks, tools and libraries and not just's
the ones that are popular(ie struts - please stop using struts).
The fact that now it's easier to develop a web app in a language other than java and them move that application to a java app server, clearly
points to the a failing somewhere. I don't mind learning new languages, but php, ruby, C#/.net, java and now flex/actionscript when none
do what java can't - again points to a problem.
But this Resin/Terracotta/PHP setup is a big impressive plus for the capabilities of the java VM and the developers at TerraCotta and Caucho.
Stories like this show Java taking place as a sort of higher-level OS - an additional layer that provides services that have become important for many modern apps and frameworks, but are not properly supported by OS technology. For example, all modern OSes offer:
- Memory management
- Threads, processes, basic IPC and synchronization
- Execution of native programs or interpreted shell scripts
but no modern OS offers
- Garbage Collected heaps for easy, safe management of memory in apps with complex allocation behavior
- High-level concurrency facilities with powerful application-oriented features, like java.util.concurrent's
- JIT execution that favors portable and/or dynamic code
As result of the increasing gap between what OSs offer and what modern apps needs, there is an increasing amount of middle-layer code that good software development environments must implement in additional (and custom) libraries / frameworks. The first machine I programmed, a Z80-powered ZX Spectrum (1982 technology) had no real OS to talk of and I'd just write to the video memory, use IN and OUT instructions to reach peripherals, etc. A few years later I was reading Petzold and writing Win16 apps that would call the Win16 C APIs plus a minimalist number of ANSI C/C++ libs. And OS technology went that far, and stopped at that point: a very thin layer of basic app-oriented APIs (Win16, Win32, POSIX etc. are not the real kernel APIs, they're one layer above the kernel and the mapping is often 1-to-1 and exists mostly for memory protection reasons.)
For years since the development of this "client/server" OS model, each language/compiler/IDE/etc would have its own high-level APIs and runtimes. So we saw a proliferation of these, like glibc/MSVC, OWL/MFC, VBRUNxx, Smalltalk VMs+classlibs, and many, many others.
The problem is that software development just keeps getting more and more complex, and the amount of support libs and runtimes that every single language/SDK must offer today is HUGE, remarkably if one wants to go all way up to "enterprise-class" applications - that must be efficient, interoperable, scalable, offer good RAS capabilities, come with productive tools and libs for every need etc. People entering the market today with novel languages (or even old ones now in fashion, like PHP and other dynamic languages) face an incredible investment before they're considered serious when compared with industrial-strength platforms like JavaEE.
The barrier-to-entry, in short, is too high, because OS's didn't evolve toward offering these higher-level services "for free". But givemn the kitchen-sink design of most current OSes, this only didn't happen because such services are hard to implement in a neutral way so they serve to multiple languages, programming paradigms and toolchains (hey, last time I used C++ seriously - not too many years ago - we still had basic difficulties like linking OBJs/LIBs/DLLs emitted by different compilers, and that's for the same language, OS and arch!).
Virtual Machines present a good solution for this problem, especially if the VMs are friendly to multiple languages and other development traits. Compile your PHP or Ruby into Java bytecodes and suddenly you can run you app in a rich application server that works in cluster; connects to everything from RDBMS to CICS to web services; scales to machines with a hundred CPUs; supports distributed transactions; implements a mind-boggling number of open standards... and if you want, is supported by some huge vendor X (where X satisfies "nobody is fired for buying X").
Both Java and .NET are fighting to fill this space of a higher-level OS. .NET is friendlier to a wider range of languages (even though it's still far from ideal as a really language-neutral VM), and it's being merged to the Windows OS (.NET/Vista already contains new APIs that are only available as .NET APIs). But Sun recently started to pay attention to this trend, so Java SE 7 will have be a much better VM for a wider number of languages; and OpenJDK will eventually make it highly available (and perhaps integrated) at many free OSes in addition to Solaris (and let's not forget devices, where Java ME leads easily...). In the end, I think the two platforms will be equivalent in most technical merits, and it will boil down to some issues that put Java in advantage, like maturity, openness and portability - and one single but important issue in favor of .NET, which is Microsoft's capability to explore the Windows+Office+IE monopoly to push virtually any other product.
Scalability is a good reason to run php on java. Security is another good reason. Simply running it on Java eliminates security problem #1: buffer overflows. Many php exploits rely on buffer overflows. These exploits simply don't work in a Java environment.
My company is working on a heavily modified MediaWiki and Quercus/Resin has frankly been a godsend, not just from a performance standpoint, but the fact that we can leverage mature J2EE components from inside MW, like JNDI resources, Hibernate/JPA, Java caches (like JBoss or Coherence), not to mention high performance compilation, trivial mechanisms to extension PHP's runtime.
Granted, Quercus is still kinda buggy, but it's getting there.
As the speed of computer progresses,Java will get more market,especially for C++.But the PHP/Ruby and etc program language for internet will get more market too beacuse they specfic featrue.
The fact that now it's easier to develop a web app in a language other than java and them move that application to a java app server, clearly points to the a failing somewhere.
Quoted because I agree 100%. Php is the perfect language for the web, imo. But it lacks security and scalability. Java has security and scalability. So php in Java is pure genious (again, imo).
Terracotta's approach to parallelization is really remarkable. By clustering at the jvm level it removes two big parts of the parallelization problem: writing parallel code, and compiling parallel code. Anyone who's used OpenMP or MPI knows what a pain those can be. I've not used JPPF, so it may be a lot more developer friendly.
If you've not seen the google tech talk on Terracotta, I recommend it strongly.
Java: One Platform To Rule Them All?
At 8:15 AM on Aug 6, 2007, Michael Urban wrote:
Fresh Jobs for Developers Post a job opportunity
This is the latest interesting example I have seen of applications written using technologies other than Java, ultimately being run under Java to improve their scalability and performance. And it seems the interest in running applications not written in Java under the JVM is growing very rapidly. It wasn't that long ago (three or four years maybe?) when one of the biggest complaints I had about Java, and one of the things I thought was holding it back, was that you only had one real option for writing your application. And that was Java itself. There didn't seem to be a lot of interest in running applications written in other languages under the JVM.
Today, however, this seems to be all the rage. It's possible now to run everything from PHP applications, to Ruby on Rails applications, and even .NET applications under Java. And in all three of these cases, the applications generally perform better running under the JVM than they do in their own native environment.
Whether for performance or scalability, or to take advantage of the huge number of Java libraries available, interest in running non-Java applications under the JVM is higher than ever. Is Java quickly becoming the one platform to rule them all?
7 replies so far (
Post your own)
Re: Java: One Platform To Rule Them All?
There is a cross compiler that converts CLR bytecode into Java bytecode, and reportedly this makes applications run faster than of .NET (where they are developed).There are at least 2 Java operating systems (which are toys like Linux used to be once): JX and JNode. The other day I read IBM was trying to do the same. And BEA has its LiquidVM which does not need an OS, but runs on top of VMWare.
Also there is JPC an x86 emulator written in Java: http://www.physics.ox.ac.uk/jpc/Demo2.html This means you can run your favorite operating system on top of Java or even in a web browser.
So I would say, yes, Java is *THE* platform.
Re: Java: One Platform To Rule Them All?
This TerraCotta/Resin/PHP is so exotic, it's impressive and concerning at the same time. The JVM may be "THE" platform, but I couldn't imagine successfully selling this to the IT higher ups where I work.This is an interesting question and imo points to the fact the JVM is pretty damn good,
but java the language or more precisely some of it's frameworks are not as productive as some of its competitors.
Hopefully, the community will continue to move toward productive frameworks, tools and libraries and not just's
the ones that are popular(ie struts - please stop using struts).
The fact that now it's easier to develop a web app in a language other than java and them move that application to a java app server, clearly
points to the a failing somewhere. I don't mind learning new languages, but php, ruby, C#/.net, java and now flex/actionscript when none
do what java can't - again points to a problem.
But this Resin/Terracotta/PHP setup is a big impressive plus for the capabilities of the java VM and the developers at TerraCotta and Caucho.
The JVM as a higher-level OS
Stories like this show Java taking place as a sort of higher-level OS - an additional layer that provides services that have become important for many modern apps and frameworks, but are not properly supported by OS technology. For example, all modern OSes offer:- Memory management
- Threads, processes, basic IPC and synchronization
- Execution of native programs or interpreted shell scripts
but no modern OS offers
- Garbage Collected heaps for easy, safe management of memory in apps with complex allocation behavior - High-level concurrency facilities with powerful application-oriented features, like java.util.concurrent's - JIT execution that favors portable and/or dynamic code
As result of the increasing gap between what OSs offer and what modern apps needs, there is an increasing amount of middle-layer code that good software development environments must implement in additional (and custom) libraries / frameworks. The first machine I programmed, a Z80-powered ZX Spectrum (1982 technology) had no real OS to talk of and I'd just write to the video memory, use IN and OUT instructions to reach peripherals, etc. A few years later I was reading Petzold and writing Win16 apps that would call the Win16 C APIs plus a minimalist number of ANSI C/C++ libs. And OS technology went that far, and stopped at that point: a very thin layer of basic app-oriented APIs (Win16, Win32, POSIX etc. are not the real kernel APIs, they're one layer above the kernel and the mapping is often 1-to-1 and exists mostly for memory protection reasons.)
For years since the development of this "client/server" OS model, each language/compiler/IDE/etc would have its own high-level APIs and runtimes. So we saw a proliferation of these, like glibc/MSVC, OWL/MFC, VBRUNxx, Smalltalk VMs+classlibs, and many, many others.
The problem is that software development just keeps getting more and more complex, and the amount of support libs and runtimes that every single language/SDK must offer today is HUGE, remarkably if one wants to go all way up to "enterprise-class" applications - that must be efficient, interoperable, scalable, offer good RAS capabilities, come with productive tools and libs for every need etc. People entering the market today with novel languages (or even old ones now in fashion, like PHP and other dynamic languages) face an incredible investment before they're considered serious when compared with industrial-strength platforms like JavaEE.
The barrier-to-entry, in short, is too high, because OS's didn't evolve toward offering these higher-level services "for free". But givemn the kitchen-sink design of most current OSes, this only didn't happen because such services are hard to implement in a neutral way so they serve to multiple languages, programming paradigms and toolchains (hey, last time I used C++ seriously - not too many years ago - we still had basic difficulties like linking OBJs/LIBs/DLLs emitted by different compilers, and that's for the same language, OS and arch!).
Virtual Machines present a good solution for this problem, especially if the VMs are friendly to multiple languages and other development traits. Compile your PHP or Ruby into Java bytecodes and suddenly you can run you app in a rich application server that works in cluster; connects to everything from RDBMS to CICS to web services; scales to machines with a hundred CPUs; supports distributed transactions; implements a mind-boggling number of open standards... and if you want, is supported by some huge vendor X (where X satisfies "nobody is fired for buying X").
Both Java and .NET are fighting to fill this space of a higher-level OS. .NET is friendlier to a wider range of languages (even though it's still far from ideal as a really language-neutral VM), and it's being merged to the Windows OS (.NET/Vista already contains new APIs that are only available as .NET APIs). But Sun recently started to pay attention to this trend, so Java SE 7 will have be a much better VM for a wider number of languages; and OpenJDK will eventually make it highly available (and perhaps integrated) at many free OSes in addition to Solaris (and let's not forget devices, where Java ME leads easily...). In the end, I think the two platforms will be equivalent in most technical merits, and it will boil down to some issues that put Java in advantage, like maturity, openness and portability - and one single but important issue in favor of .NET, which is Microsoft's capability to explore the Windows+Office+IE monopoly to push virtually any other product.
Re: Java: One Platform To Rule Them All?
Scalability is a good reason to run php on java. Security is another good reason. Simply running it on Java eliminates security problem #1: buffer overflows. Many php exploits rely on buffer overflows. These exploits simply don't work in a Java environment.A nice overview of other security benefits is provided here: http://www.caucho.com/resin-3.1/doc/quercus-security.xtp
Re: Java: One Platform To Rule Them All?
My company is working on a heavily modified MediaWiki and Quercus/Resin has frankly been a godsend, not just from a performance standpoint, but the fact that we can leverage mature J2EE components from inside MW, like JNDI resources, Hibernate/JPA, Java caches (like JBoss or Coherence), not to mention high performance compilation, trivial mechanisms to extension PHP's runtime.Granted, Quercus is still kinda buggy, but it's getting there.
-Ray
Re: Java: One Platform To Rule Them All?
As the speed of computer progresses,Java will get more market,especially for C++.But the PHP/Ruby and etc program language for internet will get more market too beacuse they specfic featrue.Re: Java: One Platform To Rule Them All?
The fact that now it's easier to develop a web app in a language other than java and them move that application to a java app server, clearly points to the a failing somewhere.Quoted because I agree 100%. Php is the perfect language for the web, imo. But it lacks security and scalability. Java has security and scalability. So php in Java is pure genious (again, imo).
Terracotta's approach to parallelization is really remarkable. By clustering at the jvm level it removes two big parts of the parallelization problem: writing parallel code, and compiling parallel code. Anyone who's used OpenMP or MPI knows what a pain those can be. I've not used JPPF, so it may be a lot more developer friendly.
If you've not seen the google tech talk on Terracotta, I recommend it strongly.