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