Panel Session Is Java Ready for Large Scale Applications at Pajava 2000

Panel Session – “Is Java Ready for Large Scale Applications” at PAJava 2000

Crowne Plaza Hotel – Manchester, April 12—14, 2000

Panel Chair: Professor Geoffrey Fox (Florida State University, USA)

Panel Members:

Ken Arnold (Sun Microsystems, USA)

Jose Moreira (IBM T.J. Watson, USA)

Sam Midkiff (IBM T.J. Watson, USA)

Vladimir Getov (University of Westminster, UK)

Recorded by: Omer F. Rana (University of Wales, Cardiff, UK)

Other participants:

Jesus Arturo Perez Diaz (University of Oviedo, Spain)

Peter van der Linden (Sun Microsystems, USA)

Fabio Rinaldi (University of Zurich, Switzerland)

Jalal Sabzvari (Trinity Mirror, UK)

Malcolm Harding (Trinity Mirror, UK)

Markus Reinsch (Bertelsmann, Germany)

Alberto Faro (Universita di Catania, Italy)

Tony Kakoudakis (Centre for Agents Research and Development,

Manchester Metropolitan University, UK)

Javier Torner (California State University, San Bernardino, USA)

Neeraj Singh (MASTECH Corporation, New Jersey, USA)

Amruth Kumar (Ramapo College, New Jersey, USA)

Emma Batch (Wrox Press, UK)

Julien Vayssiere (INRIA, France)

Chris Douce (Information Technology Research Institute, UK)

George S. Almasi (IBM T.J. Watson, USA)

Giacomo Cabri (Universita’ di Modena e Reggio Emilia, Italy)

Stefano Sanna (CRS4, Italy)

Davide Carboni (CRS4, Italy)

Craig Berry (Wrox Press, UK)

Eleanor Baylis (Wrox Press, UK)

Chandy Nethsinghe (Wrox Press, UK)

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.