| Paper ID | 34 | |
|---|---|---|
| Title | DJ: Dynamic Adaptive Programming in Java | |
| Keywords | Programming Methodologies, Metaobject protocols, Separation of Concerns, Implementation Techniques, Programming Languages | |
| Abstract | Following the Law of Demeter, a programming style rule for loose coupling between the structure and behavior concerns, can result in a large number of small methods scattered throughout the program, which can make it hard to understand the high-level picture of what a program does. Adaptive programming with traversal strategies and adaptive visitors in DemeterJ avoids this problem while even better supporting this loose coupling of concerns. DJ is a pure-Java package for adaptive programming that allows traversal strategies to be constructed and interpreted dynamically at run-time. Traversal strategies can be used with adaptive visitors or in a generic programming style by adapting them to the Java Collections framework. The DJ package makes heavy use of Java reflection and we give the highlights of this implementation. | |
| Contribution | 2.8 | 05 = Deserve paper award 04 = Accept 03 = Weak accept 02 = Weak Reject 01 = Reject |
| Significance | 3.0 | 05 = Very high significance 04 = Significant 03 = Marginally significant 02 = Only little significance 01 = Absolutely no relevance |
| Originality | 2.8 | 05 = Excellent 04 = Good 03 = Marginally good 02 = YAPA (yet another paper about...) 01 = It's been said many times before |
| Relevance | 3.8 | 05 = Right on target 04 = Definitely relevant 03 = Close enough 02 = Not really appropriate 01 = Definitely inappropriate |
| Readability | 4.0 | 05 = Very good 04 = Basically well written 03 = Readable 02 = Needs considerable work 01 = Unacceptably bad |
| Overall | 3.0 | 05 = Definitely accept (very high quality) 04 = Accept (good quality) 03 = Accept as SHORT PAPER 02 = Likely reject (low quality) 01 = Definitely reject (has no merit) |
| Date&Time | 2001/05/02, 17:44 |
|---|---|
| Contribution | 3 |
| Significance | 4 |
| Originality | 3 |
| Relevance | 4 |
| Readability | 4 |
| Overall | 4 |
| Familiarity | 4 |
| Author note | ) General comment
This paper shows the interest of reflection to support dynamic adaptive programming. The presentation of DJ is clear and its implementation highlights are welcome. ) Others comments - Where is the outline? - In the Related Work, could you develop the comparison with "reflective visitor" and "Walkabout"? - What is your conclusion about DemeterJ? You give the impression that DJ is a exciting approach and DemeterJ an heavy approach. |
| Summary | This paper presents DJ, a Java library using Java reflection and supporting dynamic adaptive programming. DJ allows traversal strategies to be constructed and interpreted dynamically at run-time.
|
| PC-note | DJ is closely related to DemeterJ, a preprocessing tool developed by the same team. The new design allows the reification of concepts which only exist at compile-time in DemeterJ, as first class objects in DJ. Then, it becomes possible to build and interpret a traversal strategy at run-time, to traverse object structures with adaptive visitors.
This paper is well-constructed with some exceptions (e.g. no outline) and the current work, profiting by past experience, is significant. The presentation of DJ is clear and its implementation highlights are welcome. The paper shows the interest of reflection to support dynamic adaptive programming and discusses open issues raised by its use (e.g. performance). I propose an acceptation even if this paper does not bring something new: DJ remains a "library" of classes making heavy use of Java reflection! Review done by Thomas Ledoux. |
| Date&Time | 2001/04/26, 19:54 |
|---|---|
| Contribution | 1 |
| Significance | 2 |
| Originality | 2 |
| Relevance | 3 |
| Readability | 4 |
| Overall | 1 |
| Familiarity | 4 |
| Author note | I have given a 2 on significance for the basic reason that this paper
adds very little to the existing litterature on Lieberherr`s adaptive programming, an opinion which may be seen as an originality issue. The practical interest of adaptive programming is OK, although not based on very profound or difficult ideas. But this paper sounds to me like just another paper on adaptive programming presenting a `new` tool adding a rather small epsilon to the existing ones. |
| Summary | |
| PC-note | Would better fit a demo session in my opinion.
|
| Date&Time | 2001/05/06, 23:15 |
|---|---|
| Contribution | 4 |
| Significance | 4 |
| Originality | 4 |
| Relevance | 5 |
| Readability | 5 |
| Overall | 4 |
| Familiarity | 5 |
| Author note | This is a very neat approach that seems to me to make
adaptive programming much more accessbile than before to the Java programmer. It also allows for additional flexibility because the traversal strategies can be computed at runtime. The paper is clear and well written, and gives good examples. The main drawback would seem to be performance, and this is addressed briefly in a coupl eof places. It would be good to have some actual numbers, perhaps a comparison on some large traversals between DJ and DemeterJ or DJ and hand-written code. It would also be interesting to see some discussion of integration with JIT compilers. The paper is not really convincing on the practical value of runtime computation of traversal strategies. Offhand, these seem to be so tied to the class structure that they are basically static, unless the program is really evolving at runtime with dynamic creation of classes. A couple of examples described, even if not worked out in the paper, are needed. Fig. 1 does not look like standard UML. |
| Summary | Describes a reflective approach, implemented within a Java
package, that allows adaptive programming in pure Java with the traversal strategies constructed and interpreted at runtime. |
| PC-note | I was positive about this paper, and I still am, but I do agree with the two negative reviewers that there is no big, new, conceptual contribution in this paper beyond the earlier work on adaptive programming. However, adaptive programming was always implemented at compile time using generator technology, and there is a lot of resistance to this sort of approach because it involves non-standard tools in the build process. The contribution of this paper is showing how it can be done dynamically using reflection, with a standard Java library, and no need for extra build tools or a new language (except some traversal specifications coded as strings in Java). Even though the contribution is thus largely in the details of implementation, it is interesting, and this new implementation approach could have real impact on the manner and extent to which adaptive probramming is used.
Given the nature of the contribution and the other weaknesses of the paper noted by the reviewers, myself included, I could see not accepting this as a full paper. However, I argue *strongly* that it should be accepted as a short paper. A short paper seems to me just the right route for papers that contain contributions that are interesting and useful, but are not significant enough to merit a full paper. What is more, the key ideas could be presented briefly, both in writing and at the conference. And the approach uses reflection, tying together the SOC and reflection areas. This paper is definitely better than some others I rated as short papers. |
| Date&Time | 2001/05/03, 20:24 |
|---|---|
| Contribution | 3 |
| Significance | 2 |
| Originality | 2 |
| Relevance | 3 |
| Readability | 3 |
| Overall | 3 |
| Familiarity | 4 |
| Author note | Overall comment - I thought that the paper described a nice re-engineering of adaptive programming in Java, but it wasn`t clear to me that it contained anything new otherwise. It seems to build on a lot of previous work but I was surprised that most of the references seemed to be to technical reports, and there were no recent journal or conference publications.
Section 1 - Introduction I didn`t find your explanation of the Law of Demeter very clear. What do you mean by "behavioural dependencies"? It seems to me that traversal strategies are concerned with abstracting away from the object structure, i.e. you`re trying to reduce "structural dependencies". Also, it was hard to see what was excluded from your definition of "preferred suppliers". I wasn`t sure what you meant by "immediate parts on this" - the fields of the current object or only those fields that are not inherited from a parent class? In fact, all I think you`re saying is that accessing subobjects directly is a bad idea (i.e. using expressions of the form x.y where y is not a method). This makes me think that I might have parsed your definition of "preferred suppliers" incorrectly - is the phrase "immediate parts" supposed to apply to all the different objects you listed? I think you could explain all this more clearly. Also, the sentence about "limiting which methods can call which other methods" doesn`t make sense in this context - surely it`s about limiting which objects are accessed directly by methods. After the long preamble about the Law of Demeter, the introduction seemed to end rather abruptly without giving a clear indication of what the paper was about! A sentence of the form "This paper describes..." would help the reader. It is also traditional to outline the structure of the rest of the paper at the end of the introductory section. Section 2 - Example I found your XML example very confusing for a number of reasons. I think you rushed into the detail without explaining the example properly. It would help if you provided a little bit more bckground about XML schemas and the semantics of XML. For example, without knowing the details of how types are defined and referenced using XML attributes, it is difficult to relate the semantics of the the two operations you are implementing to the code in Attribute that implements them. The layout of Fig 1 was atrocious with subtypes above their supertypes so that the type hierarchy was completely obscured. You also didn`t explain the difference between the two kinds of arrow used to indicate relationships between classes. Looking at the code in Fig 2, I noticed several anomalies. Why isn`t attrs[] declared in SchemaItem and then inherited by TypeDef and Decl? Why do some classes only provide addDef whilst others only provide addUndef? Why do some methods call super whilst others do not? Why do some classes recurse over all their members whilst others do not? The answers to these questions appear to depend on XML semantics ("only element declarations can contain type definitions") and it seems to me that your choice of representation and implementation depends on these semantic rules. You appear to have encoded the semantics of XML deeply in your object structure and then been guilty of premature optimisation ("addDef in ComplexType doesn`t have to traverse adecls because attribute declarations can`t include type definitions"). The complexity and lack of uniformity in the code stems from this - otherwise, the code is a pretty standard recursive traversal of your object structure. I can see why you might want to generate this traversal code automatically but I don`t see how you can apply these semantic optimisations automatically. Furthermore, if the object model does depend on the semantics of XML, then it isn`t likely to change, which destroys one of your motivations for separating out the traversal code. Your comments about implementing the same example using the Visitor pattern are tantalisingly brief - it would be interesting to show this as a comparison. More generally, you could contrast several different approaches to solving the same problem but this would move the focus of the paper away from DJ to Adaptive Programming in general. Section 3 - DJ This seems to be the heart of the paper and your main contribution. I thought the code shown in FIg 3 was very elegant - a nice use of nested classes. DJ seems to be a much more natural way of doing Adaptive Programming in Java than DemeterJ. It would be worth saying more about how you use Java reflection (introspection) to link the traversal strategy to the before method in the Adaptive Visitor pattern. It would be more normal in Java for the before method to take a parameter of type Object - being able to link a traversal that looks for a particular kind of object (in this case Attribute) to a method that expects an object of the appropriate type is a nice achievement. (I did wonder though whether expressions of the form "host.name.equals" were in accordance with the Law of Demeter!) I don`t understand how your traversal strategies relate to the code in Fig 2. In particular, you seem to be only traversing one branch of the type hierarchy for each method (TypeDef or Decl). So I don`t see how you will reach the TypeDef object referenced by an ElementDecl (for getDefinedTypeNames) or the AttributeDecl object referenced by a ComplexType (for getUndefinedTypeNames). I thought it was questionable whether DJ provided support for "generic programming" in the C++ sense - the C++ implementation depends heavily on parameterised types (templates) which are not a feature of Java. I guess it depends on exactly what you mean by "generic programming". However, I could see the value in providing a List view of a traversal. Nevertheless, I wondered whether it was necessary to actually realise the List object - I thought it would be more in keeping with the philosophy of generic programming to obtain an iterator from the traversal directly. Otherwise, all you`re doing is fitting DJ into the Java Collections framework, and it is the Java Collections framework rather than DJ that is providing the support for generic programming. Something that wasn`t clear was whether you used lazy evaluation to compute the contents of the List object. Section 4 - Implementation Highlights I wondered if it would be worth dividing this section up into sub-sections. It wasn`t clear whether your strategy for constructing the class graph by searching the class path dealt with JAR files and other archive formats. The overhead of loading every class on the class path seemed excessive - you don`t comment on this point. I didn`t find your explanation of the traverse method very clear but I wondered if there was anything new here - you previously cited [18] as a description of the implementation strategy. I would prefer it if you said "methods ... are inspected and invoked by introspection" rather than reflection. The optimisation of only checking the visitor object once seems so obvious I wondered why you hadn`t done it already. Is there a subtle complication here you`re not explaining? Your discussion of asList made it clear that you were using lazy evaluation but I think you should have stated this earlier. Without this optimisation, it`s not clear what benefit you gain from providing a list based traversal of the object graph - you should discuss the time/space trade-off of using a lazy evaluation strategy. I found the paragraph about customising the behaviour of the before method confusing because of the preamble about how Java doesn`t support intercession. I think you`re confusing two different things here - all you`re really doing here is explaining how the mechanism by which the traversal calls the before method of the visitor pattern. Yes, I suppose you`re opening up your implementation of traversals in some sense but I don`t really think this is intercession in a classical sense - it`s just a standard example of an extensible framework. I think you could make the link clearer between the before method with two arguments described here, and the before method with one argument that is defined by the visitor pattern. In particular, you could show how you use Java introspection to implement the default semantics of visiting each node by calling the before method of the visitor pattern. The XML pretty printing example looked like something that could have been implemented quite easily using an event-driven parser for XML, so I think you need to comment on this. Arguably, the example belongs in the previous section as a way in which you can use DJ - you could divide the material up into three sub-sections (standard traversals, generic programming, customised visitor patterns). The last line of the code in Fig 5 ("XSD.cg.traverse") looked garbled to me - what is XSD and where is cg defined? Section 5 - Related Work I found the comparison with DemeterJ interesting and thought that DJ sounded like a real improvement. I think you could make more of this comparison. It seems to me that you don`t make much of the dynamic aspect of DJ but perhaps this is because Java doesn`t allow the object graph to change dynamically at run time - classes can be loaded dynamically but can`t be modified once they`ve been loaded. I thought the comparison with OQL was spurious - you might just as well have compared DJ with JDBC and the mechanism for executing SQL statements. An important distinction between database traversals and object graph traversals is that object traversals reflect on the object graph used by the program and allow call backs. Database traversals use a different object graph (database schema), aren`t really reflective in the same sense, and don`t provide a callback style of interaction. Your observations about the link between DJ and AOP are really observations about the link between AP and AOP. I don`t think there`s anything new here. Section 6 - Summary and Future Work Most of your future work seems to be concerned with performance optimisations, but this is perhaps not surprising because the contribution of this paper appears to be technological rather than conceptual - the concepts have been around for a while, this is just a nice re-engineering of them. I thought the idea of reducing the reflective overhead by generating a class dynamically was interesting, but of course, this is problematical because Java only supports dynamic loading of class files, and doesn`t provide a standard mechanism for dynamic generation of classes. |
| Summary | This paper gives a brief introduction to adaptive programming with a rather confusing XML example. It then shows how adaptive programming can be implemented in Java using standard Java introspection. The programming model is quite elegant and an improvement on previous work, but more could be made of this comparison and the paper doesn`t otherwise seem to contain anything new for someone who is already familiar with Adaptive Programming. Thus, the contribution is technological rather than conceptual - a nice re-engineering of existing ideas. Hence my recommendation for a short paper rather than a long paper. |
| PC-note | A neat implementation of Adaptive Programming in Java but otherwise nothing new for someone who is already familiar with Adaptive Programming. |