Forces in tension: why we chose Java
The decision to implement JIVA applications in Java came down to one simple point: at this point in time, only Java byte code meets all of our requirements.
We knew at the start that the implementation depended on several forces, all in tension:
Performance: Since the object of this exercise was to do brute force computing, the applications clearly could not be butt-draggingly slow. At the very least we need to demonstrate that the system would run at some reasonable level (i.e., at least half as fast as optimized C code). It was decided that a reasonable performance hit (as much as 50%) would be acceptable, because this hit would be the trade off in exchange for the other features listed above.
Mutability: The clients needed to be able to run different applications, and this needed to be done in a way that was friendly to the local administrator. This meant that we needed a way to easily transfer new applications out the screensavers in order to switch out the type of problem that we were trying to solve.
Backwards compatibility: This point addresses the desire of customers to use their old legacy applications with their new framework. Unfortunately, this is very difficult to do in a way that is completely secure. To my mind, this is the single largest shortcoming of JIVA. Most legacy applications are written in native code and for JIVA this is just Right Out (see security).
Developer acceptance: JIVA is useless without applications. Many of our customers will be faced with writing their own applications, and a lot of the developers employed by those organizations are probably not going to be Java developers. Most of them have found something that works for them, be it FORTRAN, MATLAB, C, or C++, and many of them are going to be resistent to the idea of having to learn a new language. Also, to my mind, there is a tendancy in scientific and engineering circles to look down one’s nose at Java, placing it somewhere slightly above Visual Basic in sophistication and suitability for scientific programming.
Customer acceptance: Note that this group is not the same as the developers that write the applications or the technical staff that might use the application result sets. This is the group of people that run the organization as a whole: Chief Executive Officers, Chief Information Officers, Chief Financial Officers, etc. These are the people that actually have to weigh the trade offs of cost, benefits, and shortcomings and decide what is best for their organization as a whole.
It should be fairly clear that developers have some say in these matters, but that it is the CxOs that really make the decisions. Anyone that doubts this should look at the outsourcing trends of the last several years. Outsourcing development to India is not an idea the average engineer would tend to champion.
Security: For us, security is king. The idea of installing an application that subverts the use of a computer and continuously downloads and executes new software can be pretty hard to swallow, particularly if you are deploying it to your entire network. A malfunction could result in a massive loss of data, disruption of the network, or actual damage to the entire IT infrastructure. Suffice it to say that we feel compelled to assure prospective customers that the only thing safer than running JIVA is unplugging your computers. So we needed a solution that made heavy use of run time security checks.
Platform Independence: We wanted people to be able to squeeze every ounce of power out of their network. We ourselves have a few aging SGI machines in the office. The idea of them dumping out as much heat as they do without actually doing anything useful was simply to galling to bear.
The solution that best balances out these forces is Java: we have yet to find a widely-used language that provides such good performance (91% as fast a optimized C) and run time security checks. The number of Java-based applications and libraries is on the rise, and we ourselves are highly qualified to port existing applications to Java in order to further support JIVA.
The engineers in our company are well versed in C, C++, and FORTRAN. If comprehensive run time security checking used with these languages we would have seriously considered it as an option. As it stands, only Java provides the degree of security we felt was mandatory for this kind of application.
Filed under: JIVA, JIVA (Technical) by Daniel
Leave a Reply
You must be logged in to post a comment.