Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Java's Continuing Evolution
|
Posted: Oct 1, 2002 12:28 AM
|
|
I'm not sure what message the author wanted to convey in this article. He first claims that Java's progress mirrors the emerging need for dynamic systems, but then concludes by saying that "creeping featurism may drive programmers away from Java to use newer languages that come along." When discussing the evolution of any system, it is often helpful to start off by defining that system. In the case of Java, the system consists of (1) the virtual machine, (2) the bytecode format, (3) the programming language, and (4) a set of class libraries.
In terms of evolution, (4) has been making the biggest progress, if measured by JSRs submitted to the JCP process. However, that may not be the category that has the most impact: An API helps make things easier, but it does not make otherwise impossible things possible.
On the other hand, evolutions in (1) and (3) do yield gains in term of capabilities that were not otherwise possible. I'm not a VM expert, but it's pretty clear to me as a Java user that VMs have evolved tremendously over the past 2-3 years to the point where Java programs are the equal of applications written for many other systems from the viewpoint of performance, and continue to surpass other systems in terms of security, dynamic behavior, and extensibility. My understanding of some of the changes proposed for JDK1.5 is that they relate to VMs being able to more dynamic by revealing some of their capabilities to Java programs.
As for (2), the continued capability of Java bytecode is absolutely fascinating for me -- it is that capability that allows all sorts of programs written for Java to interoperate. The author of this article mentions Web services and JXTA protocols as technologies that foster interoperability. Yet, SOAP implementations (a key Web services technology) already experience interoperability problems.
Relying on protocols to foster interoperability might work for technologies that provide plumbing for low-level functionalities (e.g., TCP/IP, HTTP, FTP, etc.), but programmers almost always deal with programming constructs that abstract out protocol behavior into a progamming API (or some other programming construct). For instance TCP sockets abstract out the behavior of TCP communications, allowing a programmer to pass around bits of data without having to know how that passing actually works on the level of TCP.
With Web services, you might have, say, a weather service protocol that lets you pass a zip code, and it then returns to you the current temperature for that area. That's fine and dandy, but most programmers will write a little wrapper around it in, say, Java (e.g., int getTemperature(int zip)), and then as good as forget about the SOAP protocol. In fact, many JSRs explicitly address that sort of wrapping functionality (e.g., JAX/RPC).
Given that 99% of programmers will never have to (or want to) know about protocols, Jini explicitly acknowledges the programming model of protocol wrapping, and does not talk about protocols at all. (The same way the Servlet API acknowledges that progammers prefer not dealing with raw HTTP messages, and prefer instead a wrapper API around the HTTP or socket communication protocols.)
In the JXTA community, too, most progammers implement applications using a JXTA language binding (such as JXTA's J2SE binding), i.e., an API wrapper around those protocols. So they don't have to deal with the JXTA protocols, but rather with the progamming model outlined by those language bindings. So Jini makes that explicit, and gives APIs to programmers to work with from the beginning.
I don't understand why the author makes a big deal out of Jini depending so much on Java - Jini depends a strong type system defined in Java bytecodes (2), and that proved to be a good choice as a medium of interoperability, since it has thus far remained a stable type system. You can write your code (i.e., define your type) in the Java language, or any language for which a compiler exists that can generate Java bytecode. Jini relies on Java types for service identification, because until recently there was no other universally agreed-upon type system that provided "strong" typing support for a distributed system. With the emergence of XML schema, there is a possiblity to use XML schema as well - or, more likely, one could automatically wrap XML schemas into Java types and vice versa (which is what Java/XML language binding JSRs propose). So, that way, Jini will easily be used for services defined via XML interfaces. More likely, you'd compile interface from XML definitions to Java bytecode on the fly for that kind of interoperation.
What the author does not mention is the difference between code mobility and object mobility, and the emerging need for the latter. Folks (users of computers) want to have their stuff done, i.e., want to access their data, or solve their problems, etc., regardless of the computing infrastructure at hand. If one machine fails, or one network route fails, you'd want a system to survive failure. We're pretty good in routing packets around network failure, but we still need figure out how to better route chunks of computation. An object represents a (state) machine (as we're reminded many places on Artima.com), and thus is a good unit for computation chunks. I think in terms of Java's evolution, we should focus increasing efforts on improving "object jumpability" -- the ability of a computation to move about on the network, to take advantage of whatever resources are available, in support of a goal. Given a goal, e.g., a function, such as f(x), how can we automatically split the execution of that function into N number of chunks such that execution of that function takes advantage of all the computing resources, and such as that execution meets certain quality of service guarantees? For instance, you might want to say that f(x) should return with a 99.99999% probability, and should take 0.1 seconds, and perhaps that it should cost 0.0001 currency units to perform. Specifying those sorts of constraints are where some of the interesting research challenges lie, and that's where a lot of Java's future will also be determined. But then, again, predications about the future always sound foulish when read the morning after the predictions were made.....
|
|
Previous Topic
