Panel Session – “Is Java Ready for Large Scale Applications” at PAJava 2000
Crowne Plaza Hotel – Manchester, April 12—14, 2000
Panel Chair:
Panel Members:
Recorded by:
Professor Geoffrey Fox
(Florida State University, USA)
Ken Arnold
Jose Moreira
Sam Midkiff
Vladimir Getov
(Sun Microsystems, USA)
(IBM T.J. Watson, USA)
(IBM T.J. Watson, USA)
(University of Westminster, UK)
Omer F. Rana
(University of Wales, Cardiff, UK)
Jesus Arturo Perez Diaz
Peter van der Linden
Fabio Rinaldi
Jalal Sabzvari
Malcolm Harding
Markus Reinsch
Alberto Faro
Tony Kakoudakis
(University of Oviedo, Spain)
(Sun Microsystems, USA)
(University of Zurich, Switzerland)
(Trinity Mirror, UK)
(Trinity Mirror, UK)
(Bertelsmann, Germany)
(Universita di Catania, Italy)
(Centre for Agents Research and Development,
Manchester Metropolitan University, UK)
(California State University, San Bernardino, USA)
(MASTECH Corporation, New Jersey, USA)
(Ramapo College, New Jersey, USA)
(Wrox Press, UK)
(INRIA, France)
(Information Technology Research Institute, UK)
(IBM T.J. Watson, USA)
(Universita’ di Modena e Reggio Emilia, Italy)
(CRS4, Italy)
(CRS4, Italy)
(Wrox Press, UK)
(Wrox Press, UK)
(Wrox Press, UK)
Other participants:
Javier Torner
Neeraj Singh
Amruth Kumar
Emma Batch
Julien Vayssiere
Chris Douce
George S. Almasi
Giacomo Cabri
Stefano Sanna
Davide Carboni
Craig Berry
Eleanor Baylis
Chandy Nethsinghe
Overview:
Each panel member was asked to comment on issues of interest in using Java for large scale applications. What
constitutes a “large scale application” was left intentionally vague – although some members of the panel had
experience of using Java in scientific computing applications on supercomputing platforms.
Ken Arnold indicated that he was not directly interested in “large scale” but rather in the wider issues of developing
distributed computing infrastructure. He suggested that Java had increased in speed by over sixteen times compared to
the first implementation, and as processor speeds were increasing, issues in execution speed would automatically be
addressed – we just had to wait.
KA suggested that “large scale” should include a number of issues – such as accessing a large number of Web pages,
connecting a large number of mobile phones etc. However, he indicated that certain problems had theoretical upper
limits – such as creating a strategy in a game of Chess. He also commented on an earlier talk in the day, comparing
Java performance to Fortran, where speedups comparable to Fortran were observed on certain specialised platforms.
Vladimir Getov mentioned that there were many dimensions of scalability, and it was important to consider all of these
aspects, rather than just the execution speed. He pointed to an article in the “Communications of the ACM” (January
1997, Vol 40, No 1), where an anology from the Far Side Cartoon was used to show how the research community was
responding to the use of Java and Internet. He suggested that it was important to identify reasons why certain
communities considered Java to be a “buzz word”, rather than a serious programming language. He suggested that it
was important to bridge the gap between those employing Java in large scale applications, and those who considered
Java to be a “fad”. VG indicated that it was also important to bring together the emerging Java community with
researchers in other areas of computer science.
Comments from participants in the audience:
It was indicated that Java books were getting larger every day, and it was important not to expand and add more APIs
to Java. KA commented on this that he was surprised that this was considered to be a “problem” – as users were being
offered a range of libraries that they could employ in a wider range of applications. KA commented on the role of
academic research vs. industrial research in Java, suggesting that academics should use their independence to explore
Java functionality – often where such undertakings were considered to be “commercially risky” within a commercial
setting. KA encouraged academics to work with SUN Microsystems, and help improve Java in areas where they
considered it to be deficient.
Sam Midkiff mentioned that for the last 2 to 3 years, people had been concentrating on the easy optimisations in Java
performance, and had managed to achieve these. Further optimisations were likely to be harder, and not as clear cut as
before. SM and Jose Moreira re-iterated the point that IBM had managed to show Java performance comparable to
Fortran, in certain numerical applications. Whereas a few years ago, industry gurus had indicated that this was not
possible! SM and JM therefore felt that most technical barriers in making Java usable in large scale applications could
be overcome, and most had already been overcome in the last few years. The remaining hurdles were related to creating
a suitable business case, and in overcoming the `standards’ barriers.
SM also mentioned that it was very likely that large business framework may be possible with Java, and many
prototype were already been developed to identify the limits in scalability. It was also felt that the sale of components
would increase if Java was deployed more widely. SM and JM also identified that the industry for scientific
applications was not really large enough, and it was therefore important to consider how lessons learned from scientific
computing could feed into business computing. JM felt that it was now hard for universities to compete with
commercial companies, and may be universities should aim for applications where they can achieve dominance, such
as in distance learning and education.
Comments from participants in the audience:
What is going to come after Java -- 6 or 7 years from now? What comes next?
It was mentioned that the complexity of Java class libraries could become a hindrance in achieving adoption. It was
recognised that understanding how class libraries were composed, and which ones could be more usefully deployed
was becoming a concern. KA mentioned that this could be a rich field for academics, to see how a greater degree of
functionality, as offered in Java, could be managed efficiently.
JM mentioned the impact of students learning Java in university, and how IBM was already seeing the effect of this
from customers. He indicated that finding Fortran programmers for scientific computing codes was difficult, and it was
necessary to consider the move from Fortran to Java, both from a customer point of view, and from a practical
recruitment point of view.
JM suggested that the impact made by people coming out of university will drive the change towards Java. Further,
there were many things that IBM could do in Java which were not possible in Fortran. He therefore indicated that if
IBM used Java, it was good for many other reasons, and he was certain that with performance improvements, Java
could be the next programming language for the scientific community. JM suggested that universities have contributed
by training people – for instance, a particular university could contribute by developing a new scientific code in Java.
He felt that it was therefore easy to push universities in the right direction focusing on new technology -- such as Java
for scientific codes.
JM also suggested that one should evaluate the importance of language performance, as this was clearly not the ONLY
factor. Some of the data mining people at IBM, for instance, would not even consider the use of an alternative
language (such as C++ or Fortran). Whereas, other people may want to think a bit more about performance.
Question from the audience:
In the areas of large scale scientific codes -- Fortran seems to be the main language, although some codes have been
converted to C. The question was – how long would it take to convert these legacy codes into Java?
KA and JM suggested that “If it ain't broke -- don't fix it”. It was very hard to get the stability of the original code when
it was being translated to another language. Hence, old codes should be kept the same, and integrated using sockets or
JNI. The question should be rather what language should newer codes be developed in.
Members of the panel were in general agreement that some of the old language proved to be the best in a particular
application domain. Whereas the advantages of Java needed to be analysed -- for researching and continuing in the
new language. It was suggested that a university can take more risk – and hedge the risk by publication. University is
more likely to be the next place for evaluating areas where Java can be successful -- students are also more interested
in doing projects in Java, rather than in languages like Fortran or C.
However, being able to call other languages in Java was important.
Question from audience:
Are people still working on improving compilers in Fortran?
Most computer companies have componentised compilers. IBM makes improvements not necessarily
for Fortran but for all compilers. C++ path has probably been tested more rigorously.
Question from audience:
Hope/Ambition that Java will kill C++?
KA indicated that when in 1996 James Gosling was asked this question, he laughed at it. There are still people using
old, and in some cases, proprietary languages – such as SNOBOL! There are also languages which have different
mental models, such as LISP. Hence, certain languages are effective within a given context, and it was important to
continue using these languages in their particular areas of speciality.
C++ does not significantly have a different mental model, and it was likely that many aspects of this language would be
overtaken by Java. KA indicated that the growth in job openings for C++ was either constant or declining, whereas
demand for Java was continuing to grow geometrically. It was therefore to evaluate where growth was likely to occur
in the future, and one should consider new things happening and what impact this is likely to have in the way
developers use a language. KA mentioned the importance of device interconnectivity and mobile computing as
important growth areas.
Question from audience:
Lots of problems with security model in Java 2. Started to have a lot of problems -the documentation is different from the actual behaviour. What should the users do? And what is
SUN expecting to do with Java. Extend the technology with so many different aspects of technology.
You want to manage everything? More difficult to control -- and fix the bugs.
KA indicated that the larger the development effort -- the more difficult it is to change. The security model for Java is
still being modified and updated. The people who really understand the security model in Java are being handled in a
different group. Security policy in Java was either code based or static. The default is to be static. An issue that needs to
be addressed. As JINI and other systems become more widely used -- this could be the next place to fix
this bug. JINI security would then be the next step. KA also encouraged members of the audience to join the Java
Developers Connection to find out about new bug fixes – and suggested that they should advertise new bugs that they
encounter via this site. Need to go to the Java developer connection -- and file bugs.
As more people do that -- more likely to get the problem fixed.
Question from the audience:
How does Sun make money on Java.
Lots of interaction with other people. Make money on JINI -- in the same way as Java. The idea was to enable people
to make use of Java in other products, from which Sun could benefit.
Question from the audience:
What about mobile and pervasive computing?
JM mentioned that there was a Pervasive computing group within IBM, and Java is probably the
best language for this.
George Almasy from the audience mentoned that there was a rather large Java system -- Safeway UK -- Palmpilot code
is not in Java. Server code is in Java. Safeways is considering expanding this to all their stores. Experimental system -WABA -- personal product recommender. Big Java system already running out there.
KA mentioned that he has some reservations about mobile computing -- there are serious bandwidth problems to be
addressed. Reasons why the palm pilot has been successful. Meets the right size of shape, complexity.
He was also not sure that we are reaching the limits of the communications bandwidth. Need a new kind of device.
May be we need to get some prototype that we really need to prove that.
KA mentioned that we should also consider the dimension of time in the context of “large scale”. For instance, when
one starts a Java system -- they stay up for a long time. What happens when you want to upgrade systems partially -Object Versioning a major problem for large scale software. Systems that cannot be brought down partially. When you
do object APIs this is a slightly different problem. SUN and HP -- embedded stuff. Take Java source and convert this
into native code. HP has already developed systems that enables this to happen. Java is portable. Well defined API -so that you do not get locking. Java can enable download of new software onto a mobile device. But must be in
bytecode.
The central servers and the cell networks -- do not want to download random stuff. Able to download
code that interacts with services on the cell network. Much rather download Java bytecode. Do a quick
JIT translation to the local machine code.
Geoffrey Fox mentioned that he was interested in looking at some kind of core functionality, which involved a mixture
of synchronous and asynchronous learning. Event service for education -- but could also be used for mobile devices.
Concerns about working in University -- lack of business case. An approach -- based on distributed computing -valuable in this area.
It looks like the distributed environments are getting so complex. Some will say to use iPlanet from Sun or E-Speak
from HP. GF felt that this was a vaguely defined area, and he was not able to get a clear answer from vendors. To him
it was not clear what type of functions should be supported on the application server. He was also not sure about the
kinds of event services that could be deployed in a wide range of different applications, and on a large scale. He
indicated that these seemed interesting issues to try to do research on -- but tangential to these new emerging
areas such as mobile computing.
Focusing resources where there are big profits. There are only so many directions in which people
actually have "big profits". If I solve this problem-- and I was a company -- I could make so much
money -- but this is not what research should be about. The deeper thing -- depends on an engineering approach and not
a research approach.
It was felt by the panel that we were facing higher and higher complexity -- and the number of levels -modules/interfaces/dimensions of possible solutions. As a community spending more and more time and efforts and
money (man months) on building on final systems and managing them. Some of the solutions to undertake this -- we
need something clever that could solve part.
When you have large systems -- more administrative complexity. In the next 2 years -- 2 to 3 levels
of magnitude than people. Made JINI simple -- need to have dynamic systems that adapt to the environment.
People are secondary -- need to consider how systems talk to systems. Need to find how systems respond
to events from other systems. Need to consider that when you have distributed systems, they break a
number of times.
Question from the audience:
Going into the Gigabit realm (network) – is TCP/IP going to survive or will we be moving to another protocol?
KA mentioned the Gilders' estimate -- increase by factor of 10. Inertia will keep TCP/IP here. Losing a little
inefficiency in TCP/IP will not matter any more. The solution is to add a new protocol. Pay the "TCP" tax.
People are good at predicting things beyond their lifetime.
JINI is the Java layer on the network stack. If TCP is the wrong thing – then give you Java object that does what you
want, and talk to TCP/IP transparently. One of the things Java does well is isolate things well. If one of the things you
want -- the libraries is more likely to be there. Taking things out of a language is not the answer. When you teach
people Java -- not need to teach all the stuff in Java. According to KA, the solution was to provide all that you would
need, so that more people could make selective use of services.
Sometimes the bulk of the Java could be an impediment. Example of OS/390. Danger in the long run of the
same thing happening with Java. DO distributed computing in Java -- distributed computing, object oriented
programming and Java. Hire someone who is smart -- someone who can learn new stuff. KA was the firm believer that
one must Smart train vs. train smart.
Want an abstraction for distributed computing in Java -- integration between different frameworks. People who are
most likely to come up with the next level of abstraction will be academics.