16th, May
   ---------

First day of class. Sounds promising. Looking forward to learning some GUI stuff.

 
   18th May
   ---------

Got hold of a book. Barbara Johnston's Java Programming today. It's got some nice pointers on OOP design patterns. Reviewed the chapters on

• polymorphism.
• anonymous class.
• inner class.

 
   23rd May
   ---------

Spent few hours trying to get the applet to work from utd server. It was working fine from my machine, as soon as I would upload it to the server, the applet would not initilalize. I was getting an "applet not inited" error. Searched on the google and seems everybody on this planet who has ever written an applet encountered the problem.
Read some stuff on Java RTTI (run time type identification). It provides the mechanism to gather meta information about a type at run-time. For every class written by a programmer, Java creates a corresponding Class object that encapsulates higher level info about the type. Therefore, each type has a Class object such as

MainPictures.java ---> Class object

AnyJavaClass.java --> Class object. etc

Class object can't negotiate anything beyond type or hierarchy information relating to the type it is connected with. So, calling a method of the type (e.g., MainPictures.drawAPic()) through MainPicture's Class object won't work. For this to work, one has to create an instance of the type.

Class mpic = Class.forName("MainPictures"); //watch out, don't write "MainPictures.class" in the arg param

Object o = mpic.newInstance(); // o needs to be explicitly downcast to MainPictures before calling methods specific to MainPictures. Alternatively MainPictures mp = mpic.newInstance().

Working from the opposite direction, one can get a Class object if one has the object of the specific type. For example,

MainPictures mp = new MainPictures();

Class cl = mp.getClass(); // now operate on the meta info of MainPictures

 
   25th May
   ---------

It's getting more and more confusing. The applet works just fine from a different machine, but not from mine. I uninstalled my JRE and installed again from java.com. JDK has an internal JRE (under the jdk folder) and then there's a seperate JRE that is run by the browsers as a plug-in. I compile my programs to JDK's JRE. I brought up the java console and looked at the error trace (it's available from the JRE/bin folder. Run the jcpl.exe and from the advanced tab, check in show console, which brings up a java coffee cup logo everytime there's an applet related acitiviy going on). The error is a classNotFoundException. I don't know if my machine is corrupting the JRE/JVM for the browsers. The applet can be executed here

 
   28th May
   ---------

Since the next week the topic for the class would be on XML, thought I would go over it ahead of time. I already knew XML syntax, so I wound up spending the whole evening on XML schema. XML schema provides an alternative means to more commonly used counterpart - DTD. W3C's schema language, unlike DTD, is just another XML document and therefore relives the XML application developer of not having to know two different platforms. Schema language is more powerful than DTD insofar as its rich repatoire of built-in data types and custom types bestows more control on developers. But after looking at few examples, I think DTD is more intuitive than XML Schema and doesn't produce a shipwreck as the final result. Besides the argument about DTD being an alien platform and thus it makes potential developers wince at it is overstated. It took me more time to figure out elements in XML Schema specification and how they can applied than the whole DTD shebang. The real argument should lie in its power, not ease of use. I think standardizations are merging towards XML Schema and modern applications and parsers are supposed to recognize and exercise this than DTD, meaning DTD mechanism is left to saunter to a graceful death.

W3C's Schema Language allows one to define elements and attributes for the instance documents that will adhere to the rules in the schema.

1. Schema Namespace ===> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
2. Element tag to identify document elements ===> <xs:element ...>
3. Element tag to identify document attributes ===> <xs:attribute ...>

Built-in data types in XML Schema: decimal, positiveInteger, negativeInteger, integer, int, long, date, string etc.

Elements are defined inlined with name and type atrributes, or with complexType tag. complexTag signals the processor that the element has attributes and nested elements. Order of nested elements can be controlled mostly with <xs:sequence> and <xs:choice>. sequence is a strict ordering where's choice is an option ordering. Number of times an element (nested or not)can appear can be controlled by minOccurs and maxOccurs attributes(these are attributes, unlike tags such as sequence).

The real strength emenates from the ability to define user-defined types and extend these and also the built-in types. Extending the types could be seen somewhat parallel to extending Classes in Java, that is grab the super class and change its functionality to make your new class more specific. In XML Schema, this extension is usually done through <xs:restriction> or <xs:extention>. The restriction creates a subset of the superclass. For example

<xs:element name="Author> <xs:simplyType> <xs:restriction base="xs:string"> <xs:length value="3"/> ...        <xs:simpleType name="threeLetterAuthorName;> <xs:restriction base="xs:string"> <xs:length value="3"> ... <xs:element name="Author type="threeLetterAuthorName">
The example on the right-sided textbox is a variation of the first one, except this time the new class is named and therefore can be referred by other elements and attributes later. In the former case, the type is created anonymously inside the element definition.

 
   29th May
   ---------

XML Schema continues...
So new types can be complexType or simpleType. complexType can have simpleContent, which is a get-around mechanism to add an attribute to the element without going through the hassle of adding child element first to add contents. simpleContent prohibits the element from carrying any descendents. To add nested element as well as attributes, one needs to create complexContent. Recap: simpleContent and complexContent are meaningful only within the scope of complexType, so don't use them with simpleType which prohibits addition of children elements and attributes (just text is allowed and nothing else) of any kind.

<xs:element name="Author> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="isAlive" default="yes"/> ...        <xs:complexType name="AuthorInfo> <xs:complexContent> <x:extention base="someUserDefinedType"> <xs:sequence> <xs:element name="Address" type="xs:string"/> ... <xs:element name="FullAuthorInfo type="AuthorInfo">

In the right side, someUserDefinedType could be a user-defined type that contains elements and attributes capturing an author's birthdate, awards, names of novels etc. In effect, this could have been done inline within the scope of the element where such info is required, but creating type provides modularity since any element that specifies this info can have its type set to the above someUserDefinedType. Without the type, all such elements would have to create the inlined hierarchy, thus cluttering the space with repeated text. Therefore, in general anonymous/inline (one on the left) is less preferable than named type (one on the right).

 
   7th June
   ---------

Was working on an RDF project that requires walking through the RDF tree and flattening it to grab the statements info. Unfortunately, the Jena API -- the backburner that enables working with RDF in a programming level -- strips property resources belonging to a subject resource from their structured, coalesced form and make a new statement out each of them. What this means is if a subject contains two properties in an RDF file you wrote in your RDF Editor, they are part of two different statements in the Jena model holding the tree. While this exposes the internal membrane of the RDF philsophy -- that is, a statement consists of single subject, single property, single value -- this is cumbersome when you need to print them out in say System.out by walking through the statements. Since, subjects having multiple properties are duplicated, they appear same number of times as they have properties, which resembles N-triple format. Obviously, model.write(tree,"RDF/XML-ABBREV") provides the desired output, but this call goes directly to output stream without me being able to manipulate the statements. So I need to store the statements in a Java collection that forbids duplicates. The whole reason for the long-winded paragraph is to set the basis for why collection is such an important framework. There're two collections that majority of people are familiar with. One is the C++ STD library and the other is Java's Collection Framework (JCF). Since Jena is Java based (and so is this class :-)), I will have to study the collection classes.

 
   10th June
   ---------

JCF is backed by several interfaces and the concrete classes that implement those interaces. Interfaces are straightforward and hierarchical: At the top is the Collection interface and Map (Map doesn't inherit from Collection)

            Collection                       Map
                |  
     ------------------------
     |          |            |
    Set        List        Queue



The implementation classes that provide the concrete implementations for these are quite interesting:

                 Interface                ---------------                 Concrete Classes
           1)      Set                                                HashSet, TreeSet, LinkedHashSet
           2)      List                                               ArrayList, Vector
           3)      Map                                              HashMap, TreeMap, LinkedHashMap

These interface are defined in a generic fashion and requies explicit type information when creating their instances (Hello C++!). So a set could be created as Set<String> s = new HashSet<String>. Obviously, s could have been HashSet too, but that runs against the polymorphism ideals and therefore not good programming practice. Difference between Hash*, Tree*, LinkedHash* is the first one doesn't provide ordering, second one provides ordering based on element values (can be quirky), and the last one provides ordering based on insertion(meaning programmer defines the ordering). HashSet is the fastest implementation, but I need LinkedHashSet for my work. Some Important methods that provide the basic operations are as follows:

1)Set --
 
add(T e) [adds an element of type e],
 
            
toArray() [returns an Object[] of the elements],
 
            
iterator()
2)List -- 

get(int index), 
          
add(int index, T e)[adds e at index], 
           
 set(int index, T e)[replaces the element at index]
3)Map --  

get(Object key) [returns the value key is linked to],
 
           
put(T1 key, T2 val),
           
 keySet()[returns Set<keys>],
           
values()[returns Collections<values>
          reason why it's not Set is because there can be multiple values for each key which is prohibited in Set],
entrySet() [returns Set<Map.Entry<Key, Val>>]

Note: Map.Entry is a nested interface in Map which contains the key-to-value mappings. Important methods for Map.Entry are getValue() and getKey(). Last, if Map is thought of as a table, then there're only two columns: the first one is the key column and the second value column. The first column is like a primay Key column in a relational database, which disallows key duplicates.