[[ In MSWord97 format || In PDF format ]]

Panel Session - "Is 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 (, 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 .

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 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 ++ 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 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.