Sub-projects Details
 
Dna Subproject
 
The Dna subproject is the basic building block for the JEF Proj since it provides a framework for dinamically manipulating Java TM class files. Amongst all the possibilities, this package allows developers to obtain object oriented Java class files representations, modify them according to their own needs up to the bytecode level (thus removing, adding or modifying the bytecode of already existing methods), add brand new methods to already existing classes, or even programmatically create new classes  completely from scratch, validate newly created class files according to the constraints imposed by the Official Java Class File Specification, all by means of an easy to use/understand and well defined API, characterized by a rapid learning curve.
 
At the moment this subproject is located under the node named jef.dna. Here we have three main classes, namely:
 
  1. 1. Dna: this class provides the object oriented representation of every Java class file, providing the developers with classical getter and setter methods useful for basic class files manipulations. 
  2. 2. DnaReader: this class is simply in charge of providing methods for instantiating new Dna objects starting from a stream.
  3. 3. DnaWriter: this class plays a role ortogonal to the one played by the DnaReader, providing developers with methods for writing to a stream a Dna instance.
 
It is easy to argue that the three classes above represent the main three entry points available to every developer willing to use the Dna Proj. for performing Java class files manipulations.
 
Beyond these three classes there are other subpackages gathering the object oriented representations of all the basic constituents of a Java class file. All these packages contain, at a first level of depth, a set of interfaces defining all the entities related to the package itself, and one interface defining how a real implementation factory able to instantiate implementations of the former entities should be. At the same level of depth we generally have an exceptions package, and an impl package containing the default implementation provided for the interfaces above.
 
For sake of clarity let's give an example.
 
Firstly follows a brief representation of the content of each Java class file:
 
ClassFile
{
        magic;
        minor_version;
        major_version;
        constant_pool_count;
        info constant_pool[constant_pool_count-1];
        access_flags;
        this_class;
        super_class;
        interfaces_count;
        interfaces[interfaces_count];
        fields_count;
        fields[fields_count];
        methods_count;
        methods[methods_count];
        attributes_count;
        attributes[attributes_count];
}
 
As one can see, at the end of every Java class file there is a list of entities named attributes. In terms of Dna, this means there exists a package named jef.dna.attributes containing at its first level of depth all the interfaces mapping those attributes defined by the Java Virtual Machine Specification, and stored in the above list of attributes. At this first level there other two packages, namely exceptions and impl, respectively containing all the exceptions related to handling classes in this package, and the default implementation we provide. Thus it is obvious developers are allowed to work over their own implementation of our specification too, and use them at run-time, simply changing the content of the Dna Proj. configuration file, DnaConfig.xml.
 
This simple example well illustrates the overall design of the Dna Proj., and can be applied to all the other subpackages too.
 
Dna Configuration File: DnaConfig.xml
 
As stated previously, the run-time behaviour of the Dna framework can be defined via the DnaConfig.xml configuration file. This file simply defines the factory implementations that should be used by the framework to instantiate entities when necessary. Follows the default DnaConfig.xml file that comes with the current distribution:
 
<?xml version="1.0" encoding="UTF-8"?>
<DnaConfig>
    <Attributes>
        <AttributeFactory>jef.dna.attributes.impl.AttributeFactory</AttributeFactory>
    </Attributes>
    <ConstantPoolTable>
        <ConstantPoolTableFactory>
            jef.dna.constantPoolTable.impl.CPTableFactory
        </ConstantPoolTableFactory>
    </ConstantPoolTable>
    <ConstantInfo>
        <ConstantInfoFactory>
            jef.dna.constantInfo.impl.ConstantInfoFactory
        </ConstantInfoFactory>
    </ConstantInfo>
    <FieldsTable>
        <FieldsTableFactory>
            jef.dna.fieldsTable.impl.def.FTableFactory
        </FieldsTableFactory>
    </FieldsTable>
    <MethodsTable>
        <MethodsTableFactory>
            jef.dna.methodsTable.impl.def.MTableFactory
        </MethodsTableFactory>
    </MethodsTable>
    <AttributesTable>
        <AttributesTableFactory>
            jef.dna.attributesTable.impl.def.ATableFactory
        </AttributesTableFactory>
    </AttributesTable>
    <InfoStrucures>
        <InfoStructureFactory>
            jef.dna.infoStructures.impl.InfoFactory
        </InfoStructureFactory>
    </InfoStrucures>
    <Instructions>
        <InstructionFactory>
            jef.dna.instructions.impl.InstructionFactory
        </InstructionFactory>
    </Instructions>
</DnaConfig>
 
It is sufficient providing a new implementation of one of the jef.dna subpackages along with a compliant factory, and replacing one of the above default entry with the new fully qualified class name of the custom factory providing access to the new custom implementation.
 
Jef Subproject
 
The Jef subproject follows the same approach outlined before. The most relevant classes are located beneath the package named jef.mixers. As one might guess, this package contains a first level set of interfaces defining the basic methods every Mixer implementation has to expose, and how a compliant MixerFactory should look like. The inner impl package is meant for gathering different implementations for both the Mixer and MixerFactory interfaces.
 
It is possible to determine which real implementation classes should be used, changing the JefConfig.xml configuration file. Follows a brief example of how this file should look like:
 
<?xml version="1.0" encoding="UTF-8"?>
<JefConfig>
    <DnaMixer>
        <DnaMixerFactory>
            jef.mixers.impl.simpleMixer.DnaSimpleMixerFactory
        </DnaMixerFactory>
    </DnaMixer>
</JefConfig>
 
JXTA-Jef Subproject
 
As stated in the Development Status, this part of the JEF Project is still in a conceptual stage, so no further information can be provided here.
 
State of The Art
 
Please, refer to the most recent entry in the Releases section to have a much precise insight of the status of the JEF Project.