CMSC 838Y Paper Reviews

Skip down to paper 0: Sean McDirmid, Matthew Flatt, and Wilson Hsieh. Jiazzi: New-age components for old-fashioned Java. In Proceedings of theACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages, and Applications, October 2001. [ .pdf ]

Reviews for paper 0

Review from Prashant Lamba<> at Mon Feb 24 16:40:39 EST 2003:

This paper explains the Jiazzi a components which help to write a large sacle 
binary component in Java.There are adhoc ways of implementing componets in 
JAVA.Jiazzi is a component system for the JAVA based on program units These 
components can be build from the Jiazzi components and from java Classes.In the 
earlier section of the paper author gives the overview of the units which have 
two types "Atoms" and "Compounds".Units in Jaissi import and export java 
classes.Visibility structure of the class is there in package signatures.I the 
later part of the paper author describes the atoms and compounds with examples 
In the paper Mixins and open Class Patterns are described for implementing the 
extensibilty .And explains the drawback of the Mixins .Concept of Type checking 
is also explained in the paper.Authors also explains the method scoping in the 
end of the paperwith example.
This paper fails to describe the concept in deatils .It gives just an overview 
of the system.

Review from Bryan Payne <bdpayne@cs> at Mon Feb 24 19:54:06 EST 2003:

This paper was showed how to extend Java to support components (similar to the 
previous paper's support for components in C).  After reading the Knit paper, 
there didn't seem to be a lot of new information here.  The methodology for 
integrating components into Java seemed rather obvious to me, so I wasn't too 
impressed with this work.

Having said this, even though the techniques may have been obvious, there is 
some utility in documenting such ideas.  People that desire to use components 
with Java will now have a much easier road to follow.

One concept that was new to me in this paper was the idea of mixins.  From what 
I gathered in the paper, mixins are little more than a situation where "an 
exported class subclasses an imported class".  A simple enough concept and 
clearly something that is done all the time in languages such as Java.  
Therefore it was nice to see support for this behavior in the paper.

Review from Nikhil Swamy <nswamy@cs> at Mon Feb 24 23:17:35 EST 2003:

This paper provides a description of a component system for Java. It is 
interesting in that it introduces the notion of a compilation/linking unit 
without making any modification to the Java language itself. This presumably 
brings the power of ML-style modules to Java. More than just encapsulation, the 
authors demonstrate the power of their tool by outlining an implementation of a 
kind of open-class pattern - a powerful model that pure Java is incapable of 
supporting. Jiazzi is able to delay the resolution of symbols to a separate 
linking phase by generating a stub-class from the signature.

Interesting though this model is, it appears somewhat unwieldy. By choosing to 
leave the source language untouched this module system has the distinct feeling 
of a retrofitted design. This could in part be due to the poor exposition in 
the paper along with several errors - the definition of the Program class is 
incorrect, the package notation is used inconsistently etc.

Review from Jeff Odom <> at Tue Feb 25 08:27:47 EST 2003:

Jiazzi is a system that allows Java programmers to group, abstract, and augment 
methods and objects into components.  It takes much of its direction from 
signature-based modules (a la ML), allowing a programmer to specify only what 
portions of a package to export, as well as allowing extension (subclassing) of 
individual classes on a per-map basis.

Unfortunately, this was one of the least-well organized papers this class has 
read so far.  The motivations behind Jiazzi seem, essentially, the ability to 
augment classes without access to the original source.  To illustrate how this 
is done, several examples of Jiazzi "units" were given.  A brief explanation as 
to the syntax would have been most beneficial at this point.  Consider:

atom applet {
 import ui_in : ui_s<ui_in>
 export app_out : applet_s<ui_in>

Where is the definition of ui_in?  Is it a package name?  A template parameter? 
 A type (possibly recursive)?  Is the ui_in in "import ui_in" the same as in 
"ui_s<ui_in>?"  Much of the expressiveness of the paper was lost in the reader 
attempting to muddle through syntax.  Additionally, much of the notion of 
"adding features to classes" sounds like aspect-oriented programming (e.g. 
AspectJ) - a comparison against that technology would also have been helpful.

Review from Polyvios Pratikakis <polyvios@cs> at Tue Feb 25 08:59:55 EST 2003:

Jiazzi is a system that adds better component-programming support to java. 
Similarly to Knit, Jiazzi also uses a language to describe component 
interfaces, called units. Each component might export or import many classes 
(described by atoms). The whole system uses link-time type-checking, to 
ascertain the proper combining of components that can even have circular 
dependencies. Using that interface-language, the programmer can "direct" the 
linker appropriately, which makes component programming easier. During 
compilation, there are stub files created along with the binary .class files, 
that get wrapped into the same .jar file, and describe the types of the 
components. These types are checked during linking Jiazzi's typechecker.
Jiazzi is a nice system for component-programming, although it is based on 
source code availability, which is not always the case. This makes it not so 
appealing for real world applications where the source code (therefore stubs 
and interface definitions) are not always available for all components.

Review from Piyush Bhagat<> at Tue Feb 25 09:45:00 EST 2003:

The paper is mainly about a component based software system known as Jiazzi. 
These components known as Jiazzi are made up of java classes or from other 
components. They can be linked to the other java classes and can be loaded to 
the java virtual machine for direct execution. The paper lays down several 
guidelines for a component based system to work well with java. Out of these 
guidelines the most important one is, the components should support separate 
compilation. This in turn would enable programmers to make large programs from 
various components that are compiled separately and then are finally linked 
during execution time. This also facilitates flexibility of components, which 
now a days is very important. The paper points out two properties of Jiazzi 
that make it useful for component based programming in java. They are It 
requires no other language to create a component of Jiazzi using java code and 
Jiazzi supports addition of any feature in java class file used in any 
component without editing its source code. This feature of Jiazzi provides 
extensibility to the system.
The rest of the paper explains about the Jiazzi components and their usage in 
program design, type checking and interaction between java and Jiazzi. The type 
checking used in Jiazzi is the same as is used by a traditional java compiler. 
I think this property makes it fairly secure against incoherent data types. The 
paper should have gone into more detail while explaining the Jiazzi components

Review from Nathaniel Waisbrot <waisbrot@cs> at Tue Feb 25 12:00:11 EST 2003:

	 Jiazzi's additions to Java are helpful, and it's unfortunate that Java didn't 
have them originally.  Extending components is a natural idea in an 
object-oriented language.  Unfortunately, McDirmid et al's paper on Jiazzi was 
not very well written, and the actual mechanics of their system were obscured 
by this.  The names they gave to files and classes was particularly troubling.  
The signatures, units, and implementations were denoted with both filename 
extensions and Hungarian notation-esqe warts; and ui_out was occasionally the 
same file as ui_in, but not the other way around.  This made it appear that 
actually implementing a program using Jiazzi would be arduous, although that 
may not actually be the case.

Review from Brian Krznarich <bjkrz@cs> at Tue Feb 25 12:27:35 EST 2003:

Jiazzi is a component design/usage language for java designed to allow usage of 
large compiled binary components with clean component interfaces beyond simple 
class libraries.  Jiazzi merges the java class compiler/linker with its own 
tool to produce code which can be run on the jvm.

Packages are created with visible signatures displaying imported and exported 
classes, allowing component classes to extend imported classes and vise versa. 
These class extension abilities, mixins, are used in a somewhat convoluted way 
to support the Open Class Pattern (not directly supported by the language) 
where methods added to a base class immediately become visible to derived 
classes.  Type checking and linking are handled by the java tool where possible 
except for linking components.  Jiazzais linking methods are noted to cause 
some code bloat with binary duplication, but it is commented that this allows 
certain optimizations by eliminating virtualizations that are not needed for 
duplicated code sections.  I don't know that they actually tested this.  
Otherwise there is little performance impact as compiled code is not 
appreciably different from standard compiled java (from what I could see).  The 
main change is the information that is made visible to the programmer to work 
with a binary component.  

Review from Mujtaba Ali <> at Tue Feb 25 12:29:04 EST 2003:

I admittedly found this article hard to read, primarily because I found the 
Jiazzi syntax confusing and found myself having to flip back and forth between 
the examples again and again.  GUI examples are always bad examples because it 
is very difficult to provide a comprehensive example when speaking of GUIs.  At 
first glance, Jiazzi seemed eerily similar to Knit.  Well, it is, but I think 
that's more because currently there seems to be a lot of interest in module 
systems and there is bound to be overlap - call it "O'Caml envy".

In general, I have reservations against mixins. I believe it's hard to keep 
track of what output "mixined" classes actually have and don't have and mixins 
have strange side effects (hence the need for open classes).  Why not just 
stick with simple delegation?  The Open Class pattern is a very interesting 
concept, but I still believe it's a bandage on the wrong approach.

Review from Yuan Yuan<yuanyuan@cs> at Tue Feb 25 21:04:26 EST 2003:

From the same token of Knit, authors designed Jiazzi as a component definition 
and linking language without extending Java language. Jiazzi supports separate 
compilation, external linking, hierarchical structure, cyclic component 
dependencies, and class inheritance across component boundaries by using an 
explicit language to define components.

Here is summary for Jiazzi. Jiazzi enhances Java with support for large-scale 
software components. Jiazzi components are constructed as units. A unit is a 
container of compiled Java classes with support for ¡°typed¡± connections. 
Jiazzi includes a component language that provides a convenient way for 
programmers to build and reason about units. Using this language, the structure 
of classes in a unit¡¯s imported and exported packages can be described using 
package signatures. Because package signature can be used in multiple unit 
definitions, they enhance the component language¡¯s scaling properties. Jiazzi 
supports the composition of class-extending components; e.g., mixins. Mixins 
and cyclic component linking can be combined into an open class pattern. With 
the open class pattern, we can replace the use of many design patterns used to 
implement modular feature addition, such as abstract factories and bridges, 
with a combination of external linking and Java¡¯s in-language constructs for 
subclassing and instantiation. Separate type checking is an essential part of 
separate compilation. 

I more like posted a ad for Jiazzi. But the idea of Jiazzi and Knit is almost 
the same; the difference just is that they act on different languages. Using 
explicit language to depict components enabled developing large-scale software 
components. But extra linking specification need to be written if we want have 
all the advantages. 

Generated: Thu Mar 6 15:39:24 EST 2003 by mwh