"Is Java Ready for Large Scale Applications" at Pajava 2000
Total Page：16
File Type：pdf, Size：1020Kb
[[ In MSWord97 format || In PDF format ]] 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.