Subject: C438 JGSI Review Resent-Date: Thu, 30 Sep 1999 22:47:48 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Fri, 10 Sep 1999 07:50:43 +0200 From: Michael Philippsen To: Geoffrey Fox CC: phlipp@ira.uka.de Title: JCArray - the jCrunch Java Array Classes Author: David S. Dixon a)Overall Recommendation ------------------------ REJECT b)Words suitable for authors ---------------------------- The paper describes JCArrays that store Java array data in Fortran fashion. Hence, these arrays can easily be passed to native routines written in Fortran. The paper has several significant problems: 1.) The paper claims to discuss a robust framework for high-performance methods. However, there are no performance measurements in the paper at all. Performance measurements and benchmarks are necessary. 2.) The paper does not discuss how the array data is stored internally. There is only one hint that there is some one-dimensional data[] array that seems to store all the elements. In a technical journal paper there should be some technical information, not just a discussion of an API. 3.) Since JCArrays are targeted towards use in native methods, the author should discuss JNI issues. How expensive is a JNI call that passes a JCArray? Is it possible to make a Fortran array available to a Java program as a JCArray? Since the author discusses the NOCOPY-routines within Java he should be aware of the fact that the JVM might try to copy array data into C-arrays. What is done to solve this problem? Can the programmer influence the copying-behavior of the JVM in the JNI-interface? How does JCArray solve the cooperation with the garbage collector? Is it a problem to pin huge arrays (or copies thereof) for the duration of a native method? 4.) The paper does not discuss how a Java programmer would access individual array elements. Are there any set- and get- routines? Only constructor methods are presented. Their presentation however requires in depth knowledge of gOffset, indexOffset and gStep. Unfortunately, most Java programmers are probably unfamiliar with these terms. 5.) Section 3 discusses "Special Matrix Forms". It is probably premature to talk about these because the reader is informed in the end of the section that nothing has been implemented by now. Section 4 discusses the future as well. 6.) The discussion of the related work is weak. It is hard to find out what the specific contribution of JCArrays is. It is my impression that these problems are too severe to be fixed in a short period of time. I therefore suggest to REJECT the paper. The author should fix the problems and re-submit it as a full paper to a conference. Some minor bugs: - the abstract mentions "persistence" although this issue is missing in the rest of the paper. - please explain why shape is of type int[] when it first appears in JCxVector. - Why did you chose to have indexOffset=1 and gStep=1 in the JCDVector example? What does that mean? - Java offers an elaborate mechanism to format numbers for output (see class NumberFormat for example). Why do you provide a low-level print method instead? - In the JCFMatrix example the first argument of the constructor should be an f instead of an m. - There are two almost identical paragraphs on the copy/nocopy issue. Please avoid cut&paste. - At the very end of section 5: "...but not for enough ..."