Kirill Grouchnikov's Blog

J2SE Archives

Reading Swing code and learning Java

  (ltr ? decrButton : incrButton).setBounds(leftButtonX, 
     itemY, leftButtonW, itemH);
  (ltr ? incrButton : decrButton).setBounds(rightButtonX, 
     itemY, rightButtonW, itemH);

Native XML support in Dolphin

• DOM is excellent feature-wise, but requires too much code to be written, and reads poorly.
• JDOM is more concise, and if you tilt your head and squint, it looks almost like XML.
• JAXB 2.0 is schema-driven and can not handle "free" XMLs (w/o schema definition) or "intermediate" XMLs (in the middle of the processing).
• It would be great to directly write XML, but that will drive compiler guys insane.
• One of possibilities - using hash mark # to refer to XML attributes or subelements.
• This can be either to get or to set a new value.
• Enhanced for loop should allow looping over all instances of some attribute.
• A lot of generified suggestions for new classes (XML and such).

class Order {
  // has get-set pair
  private int id;
}

class Customer {
  // has get-set pair
  private int id;
  // has get-set pair
  private String name;
  // has get-set pair
  private List orders;
}

@XmlAccessorType(AccessType.FIELD)

@XmlRootElement(name = "customer")

<customer>
  <id>1</id>
  <name>Dan</name>
  <order>
    <id>1</id>
  </order>
  <order>
    <id>1</id>
  </order>
</customer>

String xml = ...;  // contains the above XML
Customer cust = xml;

cust.setName("Arnold");

String newXml = cust;

for (Order order : cust.getOrders[id>3]) {
  System.out.println(order.getId());
}

<customer>
  <id>1</id>
  <name>Dan</name>
  <age>32</age>
  <order>
    <id>1</id>
    <extId>1000</extId>
  </order>
  <order>
    <id>1</id>
    <extId>2000</extId>
  </order>
</customer>

String xml = ...;  // contains the above XML
Customer cust = xml;

String xml = ...;  // contains the above XML
extends Customer cust = xml;

System.out.println(cust.age);

• Single instance with simple value
• Single instance with complex value (inner elements)
• Multiple instances

// must extend Object as we don't know it's type
for (extends Object age : cust.age) {
  // implicit function provided by the compiler
  if (age.isSimple()) {
    // the cast will succeed
    System.out.println((String)age);
  }
}

cust.weight = 180;

private Customer cust1;
private extends Customer cust2;

void test() {
  // narrowing implicit cast - all undeclared
  // attributes and elements are discarded
  cust1 = cust2;
  // widening implicit cast
  cust2 = cust1;
}

Set customers = new HashSet();
Customer cust1 = ...;
extends Customer cust2 = ...;
// implicit widening cast
customers.add(cust1);
// regular insert
customers.add(cust2);
for (Customer cust : customers) {
  System.out.println(cust.age);
}

void foo(Customer cust) {
  // widening cast - undeclared fields
  // can appear after the call.
  bar(cust);
}
void bar(extends Customer cust) {
  // implicit narrowing cast - only declared fields
  // can be changed.
  foo(cust);
}

Map getAllElements();

void dumpXml(extends Object xmlObj) {
  // see if it is a simple (and implicitly single) element
  if (xmlObj.isSimple()) {
    System.out.println((String)xmlObj);
    return;
  }
  // see if it is a single (and complex because of the previous
  // check) element
  if (xmlObj.isSingle()) {
    // iterate over inner elements. The getElements()
    // function is generated implicitly in the same way as 
    // name() is for enums
    for (Map.Entry element : xmlObj.getElements()) {
      System.out.println(element.getKey()); // element tag name
      dumpXml(element.getValue());          // recurse on value
    }
    return;
  }
  
  // here - we have multiple instances of element with the same
  // tag (collection). Can call .isMultiple() function on 
  // xmlObj
  for (extends Object child : xmlObj.getElements().valueSet()) {
    dumpXml(child);             // recurse on the current child
  }
}

• Partial processing of XML can not use schema-derived types. If i know that the input XML contains fields that i wish to ignore, i just don't define them in my data model and work on extends object. In XJ, I'll have to work on XMLElement even if I wish to ignore some fields (unless i have schema definition for every intermediate XML state in my business process chain).
• XMLElement is not a run-time class as far as I can see from the bundle distribution (the documentation is very scarce). The only way to get elements from it is using XPath, even for simple attributes.

Porting small library from Java 5.0 to Java 1.4 - could it be any harder?

• background of menu and menu items is dark gray instead of nice light gray. The same for combobox.
• default button behaviour is transferred to the clicked button.
• the buttons are not "rollover-enabled"
• dialog root pane is not opaque
• selected items in list are not highlighted
• sliders have background for ticks
• progress bar is off by 1 pixel in both width and height
• root pane header is off by 1 pixel in width

POJO - Complex New Perl Classes

• The P stands for plain. A java class with annotations is quite far from being plain. The annotations can be quite complex (take a look at the JAXB 2.0 generated classes).
• The O stands for old. Apart from the obvious (that the annotations are only part of JDK 5.0), i don't see many examples of new JSRs that propose to work with classes that aren't annotated at all.
• The J stands for java. More on this later in the entry, but annotations make a class to be non-standard Java (in my view).
• The O stands for object. The annotations are on classes, and not on a single instance, but this may be more suitable for BileBlog incoherent blabbering.

• The configuration XML file is now spread all over our class model. Furthermore, once you compiled your classes, you can't configure annotations (correct me if i'm wrong).
• The bean getters and setters are gone, but instead the corresponding fields are marked with a predefined annotation. You say potato, and i say @potato.
• The marker interfaces are gone, but instead the corresponding classes are marked with a predefined annotation. You say tomato, and i say @tomato.
• Everybody is welcome to create his own annotations. Everybody can finally feel like a king and create his own kingdom. Everybody can finally create his own flavour of Java. Everybody does. Sun realizes that and tries to come up with common annotations. The community happily ignores the JSR. It becomes impossible to read the code because each field and class has more than 10 annotations attached to them. Java becomes Perl.

This work is licensed under a Creative Commons License.