Pulihora

Toplink vs hibernate

2006-04-10T22:02:00.000-07:00

I still remember the excitement I felt when I started working on Toplink. It was early 2000. Before that, I was working mainly in visual c++. Visual c++ community never had this type of tool; I even thought that such a tool is impossible. During that time, I attended toplink training, and was amazed to know that it can store/retrieve practically any object model into a database, with out any sql. It was not just I, every body in the training session was like that. It was like a dream come true to all of us. Over the period toplink worked very well for us, major productivity gains were there, you know all the regular ORM benefit stuff…

Though I am a fan of toplink, after looking at Hibernate, looks like Hibernate is a better framework than toplink, and for very good reasons.
Obviously, Hibernate is free (as in free beer?), has better user base, community, articles, resources, books and momentum.
Hibernate API is lot cleaner than Toplink API. Toplink API, naming conventions are unintuitive in many areas (am I picky on this?).
The most problematic feature in toplink is it is practically impossible to get away from its cache. In toplink, cache is a necessary evil, there is no simple way to bypass cache to go to db. Documentation says few options to set on its descriptor, but none of them work well. In Hibernate cache is optional, if we want we can have it, it always goes to database by default.

We are not going to switch to hibernate anyway.

orm tricks ..

Books are in a Library or Library has books or is it both?

2006-02-26T22:32:00.000-08:00

Is it silly? but for a developer doing object relational mapping this could be interesting.
Suppose we model this relationship as bidirectional, i.e. Book *<---->1 Library, then, when we load/send a book from database, we load book’s library (since book references library), and all the books in that library (since library refers books).
If we model this relation as a unidirectional--Library has Books (Library 1 -->* Book), then, since book doesn’t refer to library, we don’t have the previous problem of loading and serializing all the books. However, our book does not know which library it came from. If we need to load library, we still end up loading all the books in the library.
Suppose we model this relation as Books are in library, i.e. Book *-->1 Library, then, when we load book we get book’s library, but since library does not have books we don’t end up reading all the books; When we load library we load only library. I choose option Books are in library (Book *-->1 Library), it’s me.
Object relationships and OR Mapping are very interesting, if we don’t model them properly, reading/sending a small object may result in reading a whole load of things that we are not intended to read/send. Technique is, model relationships to the right granularity to match our object reading and writing patterns. In many places, I find turning a container into a marker, as we did above, to be very helpful in getting to right object granularity. Then, what about finding books in a library? If need be, we can always find books in a library by query: get all books whose library is x.
How should we model relation between Book and book pages, Pages are in book or Book has pages or both?

Great lens

2006-02-22T17:51:00.000-08:00

If you want a cheap and excellent lens for canon rebel, Canon EF 50mm f/1.8 II is the one to buy.
It is very cheap(<$70.00), fast, and pictures are sharp (see six-packistan).

Why Thread implements Runnable?

2006-02-18T22:50:00.000-08:00

I have this questions for many years, why Thread implemets Runnable?

We implement Runnable, if we want our method (task) to be called from a new thread or a special thread. Then we do some thing like below.

public void doTaskInRunnable() {
Runnable r = new Runnable() {
public void run() {
task();
}
};

// to make it tarket of a new thread.
Thread thread = new Thread(r);
thread.start();
// or to make our task run from a sp thread.
SwingUtilities.invokeLater(r);
}

If we use Thread instead of Runnable above code becomes

public void doTaskInRunnable() {
Thread r = new Thread() {
public void run() {
task();
}
};
// Reason 1 : to make it tarket of a new thread.
Thread thread = new Thread(r);
thread.start();
// or Reason 2 : to make our task run from a sp thread.
SwingUtilities.invokeLater(r);
}

Making a Thread target of another new Thread is plain stupid, why create a new thread and call it from another at all, in the above code at Reason1 we can as well call r.start().
Making a Thread target of a special thread is confusing, why a thread is running in another thread.
Until java 5, if we use Thread in place of Runnable, we have a memory leak. In the code above thread r is never started--it's run is called from another thread but never started, until java 5 ThreadGroup used to keep track of all un-started threads and r is never released.

Using Thread in place of Runnable is ugly, then why Thread implements Runnable? Is it because they have same method named run with same signature?

Spring, just another hype?

2006-01-23T21:47:00.000-08:00

A book challenging a platform and developing an open source project to prove its point is unprecedented. That’s how Spring is born, from the ideas of (its manifesto) book "J2EE with out ejb". Spring’s alternative to ejb is an aspect oriented and POJO based inversion of control or dependency injection (IOC/DI) container, which integrates with other enterprise ingredients--orm tools, transaction services, custom protocols etc--and also provides client interfaces to Spring. While the ingredients, at least orm tools, are not new, integrating them together to build a toolset is different. IOC, DI, POJOs and hype make me take a closer look at Spring.

Dependency injection, that too for POJOs (i.e. without no explicit interfaces) is good--less burden on lazy developers, we don’t need to worry about building objects or learning new APIs. However, objects can have many possible lifecycles, can Spring really inject dependencies in all cases?
Spring documents limitations in some cases:

on lifecycle mismatch it says "There is however a problem when the bean lifecycles are different. Consider a singleton bean A which needs to use a non-singleton (prototype) bean B, perhaps on each method invocation on A." and suggests to forgo POJO ness get it,
warns on prototype lifecycle by saying "Spring cannot manage the complete lifecycle of a non-singleton/prototype bean".
There are many other limitations too: sharing a prototype (state-full) object across multiple objects, composing object graph of non-singletons with circular references among others, temporal objects (objects with time to live) etc are not possible in Spring. Spring barely supports non-singleton objects, and justifies can’t support or missing features as "they are not common", "not needed", or "heavy weight".

Non-singletons, state full objects, objects with circular dependencies are not uncommon.
Containers have a smell in them, their lookup services are very plain, e.g. Spring bean-factory looks up objects based on their id. We are used to factories or registries that have meaning full lookups and classifiers, our lookups have methods like get a pricer for a product type and region, or get a data access object for currencies etc. and a lot more magic is possible in our localized factories/lookup utilities.
Whatever elegance gained in dependency injection is lost by lack of rich object composition and vanilla object classifications of spring. Managing singletons is not a big deal, perhaps, dependency injection is just a good idea only.

So can, Spring, "torchbearer of anti ejb", replace ejb? Yes and no.
Transactional ejbesque services follow a pattern of business service depending on an orm tool and together participating in transactions. In these scenarios rarely state-full services are needed, at the maximum business façade may be a state-full service, they don’t have lifecycle mismatch problems. Spring integrates well with almost all persistence solutions, and its declarative transactions work inside and outside a container.
Declarative transactions are part of the ejb story only; remoting or distribution support is another important feature in ejb. Spring's remoting/distribution is through custom protocols (non rmi-iiop) --hessian, burlap,httpinvoker, these protocols have serialization and user/transaction context propagation limitations.
Even with problems in dependency injection and incomplete remoting, spring framework accomplishes what very few contemporary frameworks are able to do--declarative transactions inside or outside container and of course lot of hype.

2005-04-09T23:41:00.000-07:00

untitlable image

Turn turn (Rangula ratnam)

2005-04-09T23:30:00.000-07:00

I was playing with shutter speed at a local mall.

2005-04-09T23:20:00.000-07:00

turn turn turn

why python?

2005-01-03T00:00:00.000-08:00

I experimented with Python few times. It looked interesting, but turned off by it’s odd indentation, lack of IDEs and my inability to find right area (application) to use. I felt it is a stronger glue scripting language than perl and weeker programming language than java.

Recently, I loaded Linux on my home desktop and wondered what is the language of choice for gnome applications: to my surprise I found it to be Python. Many gnome UI applets and games are developed in Python.

its simplicity, which is not as barbaric as C/C++ , a seasoned programmer can learn in a week.
great interoperability with native gtk libraries, unlike java.
and great glade UI designer, not there in java world.

are making python popular on linux. Perhaps, a good IDE(?) and a database independent db access API like ODBC/JDBC, can turn it into a true enterprise application language.

Check out diveintopython, PyGTK, Guido van Rossum's interview, Bruce Eckel's python zen, and his case for strong testing to offset weak typing.

What is clean code?

2004-12-11T23:51:00.000-08:00

Coding standards are language and project dependent. Some C/C++ teams strictly think all local variables in a method should be declared at the begining of the method, some think a method should have only one return statement, Some encourage anonymous inner classes and some out right hate them.
So What is clean code? Is it the code that follows coding, documenation and testing standards. Can we apply bookish knowledge--ofcode smells,best practices, and freak out on switch case statements, series of if-elses, instanceofs, lack of test cases etc. Or on the contrary, a nice looking (unsmelly)program that has javadocs, test cases and follows some bookish buzz words is always clean code?
We programmers (perhaps human tendancy) don't accept other's code as clean. More over in a large team with group politics, it is even worse, one group thinks rival group's code is crap, and vice versa. IMO 90% of the cases, calling code bad, horrible, crap is for personal or political reasons.

IntelliJ style tabs

2004-11-25T12:11:00.000-08:00

Swing JTabbedPane's LEFT and RIGHT tab placements are rarely used. They waste screen space by placing tab titles left to right (see below left image).

I recently came across infonode's toolbar library. It has features to have tabbed titles drawn bottomup or topdown along with many other cool features. Using infonode I created a tabbed panel like the one in IntelliJ Idea (see right image).

Infonode has some cool features but is costly, they should have offered a reasonable site wide licensing price.

BloGTK

2004-11-23T18:46:00.000-08:00

I am posting from BloGTK.

After looking at it, I am planning to learn python.

Upgrading to core 3

2004-11-12T23:30:00.000-08:00

Spent this evening upgrading to core 3 from core 1. I don't have a cdrw. Initially I tried installing using yum. I was getting a weird error saying udev and kernel are conflicting.
Later found a cool hack way to install from hard disk downloaded iso image file.
Fedora core 3 has pre installed firefox 1.0, evolution 2.0, gnome 2.8, kernel 2.6 and is much faster than core 1.

JBoss AOP - 10 out of 10

2004-10-27T17:38:00.000-07:00

I looked into jboss-aop today and am delighted. It has

Great documentation and tutorials (not unusual any more in jboss projects).
Great examples (with brief explanation) covering all most all jboss-aop features. All the examples work out of the box. We dont need to do any thing special to run them.
Excellent eclipse ide plugin. This one rocks.
Works with jdk1.4 & jdk1.5 .

Over all I am able to get started in half an hour. JBoss team is living upto their "professional opensource" slogan.

Cool Runnables

2004-10-23T23:53:00.000-07:00

A frequent reason to implement Runnable is, a class already extends other class we want it's objects to be active objects.

Another important reason is runnable can be used as a generic call back.
We can have a method like below doCallback where it calls back run on given runnable.



  doCallback(Runnable r){

    ...;

    r.run();

    ...

  }

This idiom is used in SwingUtilities.invokeLater(Runnable r), and SwingUtilitie.invokeAndWait(r). In these runnable is posted to a event queue and AWTEvent thread reads it and calls run from event thread. This makes given runnable called execute in a particular thread.

Recently I have been using this idiom in our persistence framework, we do normal operations on our business objects and post persistence tasks to a set of database aware threads. These db aware threads call our runnable task and do pre/post processing(transaction, connection management etc). Isn't it cool?

Why not JOnAS?

2004-10-11T21:58:00.000-07:00

I am wondering why JOnAS is not as popular and as hip as JBoss?

JOnAS is also an open source (LGPL) project. It is J2EE certified for a while. Lot of developer/user documentation is freely available (Unusual for a open source project). According to study conducted by rice university JOnAS scales better than JBoss. Redhat officially supports JOnAS as part of redhat application server.

Is it because JOnAS doesn't have evangelists, entusiasts JBoss has? Is marketing/hype important for a free and open source project also?

Linux desktop

2004-10-10T20:28:00.000-07:00

I tried using a Linux desktop four years ago, it was a disaster. My dell PC had a winmodem and Linux didn't recognize it. It made me switch back to windows.

I tried again six months back. This time Linux recognized cable connection :). Over this period gnome/kde improved a lot. In many ways gnome looks and feels better than ms windows. All my favorite IDEs, tools are available on Linux also. In fact eclipse looks better on Linux. I am able to use samba file server, use vnc to control windows PC from Linux and vice versa. I feel p2p clients are perceivably faster on Linux. Open office is nice also. Open office can convert from open office format to PDF. Mail client evolution is great. Most importantly there is no worry of spyware.

On the -ve side multimedia tools are still lagging. XMMS doesn't have nice play list editor. Not many video players available and available ones are not that friendly.

Only big complaint this time is Firefox on Linux is not able to recognize telugu fonts. After some trouble I am able to install eenadu font and read it. I am not able to set up rest of the telugu news paper fonts.

I found tamil, bengali and hindi linux builds. I could not find telugu linux. Is it out there?

Overall this time I am very happy with Linux desktop.

I will post some screen shots soon :)

Visitor thoughts

2004-10-09T21:08:00.000-07:00

Riley white gives an excellent visitor example and explanation.

My 2 cents are

I prefer foreign method to visitor pattern. Foreign method can traverse Subject's hierarchy with out accept method in subject. In reily white's example I would have some thing like
class CheckoutImpl extends Checkout{ void checkout(ShoppintCart cart) { Collection items = cart.getItems(); // traverse and add all items. } }
Only advantage of Visitor is it's accept method can encapsulate traversing items in a Subject. In Most cases it tends to be very simple traversal.

Use visitor only when there is a need to do special traversal. For example when traversing a closet an employee need to sort only items under $3.00 or need to remove expired items. Then Subject's accept method becomes
void accept(Visitor v, Condition c){ Collection = getItemsSatisfyingCondition(c); doNormalAccept... }

Java (my language choice) determines overloaded resolution at compile time, visitor need to have explicit visit methods for each sub type of Subject and an instance of checking method to resolve and call explicitly typed methods. Resolving these conditional type checks is some sort of ugly code.
Changes in Subject hierarchy causes changing all visitor implementations.

Beware of these problems and (as advised by GoF) use visitor only when subject hierarchy is stable(rarely/never changes).

Assigning Responsibilities Duh!

2004-09-11T17:10:00.000-07:00

In object design a big dilemma is where to assign responsibilities, thumb rule is to keep behavior with data i.e. to define methods in the class that has the data. This rule has is always not correct even when data is in the class. Look at this simple example, An application need to store Order object(s) containing set of Order Items, Customer who ordered it. These objects need to be saved to a database. Order, OrderLineItem and Customer classes and relation ship among them are identified. Dilemma is where should save responsibility(methods) live and why it need to be there. To be specific, Is there a need to have a new class like DataStore, or have save method be part of Order object (it is the object that has data).



public class Order

{

void save();

}

// or

class DataStore

{

void save(Order anOrder);

}

If it is a method in order, then

Order object needs knowledge of api like JDBC. It is not a real part of Order object.
Similarly save method should be in each domain object.
If need be, How to handle bulk saves(saving a collections of Orders) in a single transaction?

All the above are valid objections even in a medium level complex application. So (If they are) it is better make other datastore abstraction to handle these db related operations.

In this application Order need to be priced also. Price of an Order is sum of it’s OrderLineItem’s price. Where does price responsibility belong?



public class Order

{

double price();

}

// or

class Pricer

{

double price(Order anOrder);

}

Here Order's price does not depend on any external data, keeping price calculation in Order makes more sense. (there may be a method in OrderLineItem also to calculate its individual price). What if price of a order is dependent on current interest rates (external data), and need to price set of orders with same set of interest rates, then clearly in other Pricer class.

When adding a responsibility to a class, ask why not move it to it's new (or other) class. Questions like

can the same responsibility/behavior be applied to collection of objects in single operation? (transaction, data set etc).
is same/similar responsibility need to be there in classes?
is needed data (to fulfill responsibility) noisy?
Is needed data (to fulfill responsibility) external?

can help in idenitifying the responsibility's location. If all things equal, add it to class with data - its the norm.

Duh!.

Facade Notes

2004-09-08T17:39:00.000-07:00

Generally façades are implemented as concrete classes or as singletons or as helper static methods. Even design patterns workbook says “A facade provides an interface, but it does not use a Java interface. Rather, a facade is a class with methods that make it easy to use the classes in a subsystem”. Implementing facades as concrete classes should not be a qualification, in fact interface based facade implementations are better.

Concrete façade/singleton classes make testing client code difficult, e.g., client using a concrete facade that hides remote calls. We can’t test client code unless remote services needed by façade are running.
If implemented as interfaces, we can easily change implementations (even intent change to a bridge).

Are helper utility classes facades? Helpers and utilities simplify complex API usage by wrapping commonly used code. If helpers can abstract complete client needs to facaded API, then helpers are façades.

Do we need facades to standard APIs? Standard APIs are well documented, well understood and well designed. By standard APIs I mean subsystems like swing, jms etc. Wrapping rich APIs for your needs is difficult. Our facades tend to hide well needed APIs richness. Why do we need facades to well known standard APIs? Except for temporary advantage of hiding some of the (noisy) classes from client they are not really helpful. In the long run our facades to such apis tend to be maintenance headaches. So letting user deal with the standard apis is better. If needed we can have some helper classes to simplify some parts of it.

Does it mean data access objects, Object Relational Mapping tools, aren’t needed, aren’t they facades to standard APIs? Data access objects are not treated JDBC facades, they are helper classes to abstract a client modules persistence needs. ORM tools are defining new set of APIs with intent of providing persistence features for objects, their primary intent is not to hide JDBC layers.

Core J2EE's Session Façade, Fowler's Gateway, Business Service, Remote Façade are they facades? They certainly are, their specialized (overloaded) intent is to hide low level (remote/ session handling/ integration) abstractions by providing a high level user/application friendly interface. They hide noise (convert application requests to low level requests, convert low level exceptions to business exceptions etc.)

In the end Facade’s intent is to provide a consolidated complete unified cool API to a complex/noisy abstractions.

cool pictures

2004-09-04T18:05:00.000-07:00

A thumbnail is worth thousand words. especially evolution charts, are n't they.

Quotable “Design Patterns" Quotes

2004-09-01T19:09:00.000-07:00

“A solution to a problem in a context.”

ChristopherAlexander

“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”

ChristopherAlexander

“A pattern is a way of doing something, a way of pursuing an intent. ”

Rebecca Wirfs-Brock

Parallel Inheritance

2004-08-30T18:31:00.000-07:00

There are two(+) associated classes A, B, and every sub type of A is associated with a (different?) sub type of B. e.g ProductEditor provides UI for a Product. Curtains and Books are different type of Products. CurtainEditor provides UI for Curtain. BookEditor provides UI for Book. And so on. Is this a CodeSmell?

If there is duplicate parallel relationship child classes, managing the duplicate relationship can be a problem.



class Product

{

}



class Book extends Product

{

}



class ProductEditor

{

   private Product product;

  public void setProduct(Product prd)

  {

    this.product = prd;

  }

}



class BookEditor extends ProductEditor

{

  // need to be careful?

  private Book book;



  public void setProduct(Book book)

  {

    this.product = prd; // need to call super also

  }

}





BookEditor bookEditor = ...;

Product product = new Book(...);

bookEditor.setProduct(product); // calls base class method.

Book book = new Book(...);

bookEditor.setProduct(product); // calls chile class methods.

Adding duplicate relationship for convenience is bad. Apart for code duplication, if not done correctly, there could be dangling/spurious references.
How ever I don't think this is a code smell (due to its -ve meaning).In fact relation ships among parallel inheritance hiearchies is common in many frameworks (is a good smell?). Are not these relations cornerstone for template methods?When such relation ships exist,

Document them and advise against duplicate relations.
If needed provide a controlled relation ship managers for setting relations among the participant Objects (do we need a DIP for this?)

What should methods return arrays or Collections?

2004-08-25T20:28:00.000-07:00

To prolong Paul River's Weblog: By returning arrays we have a temporary advantage of typed objects(untill we java 5). There are many other advantages if a method returns Collections, We can decorate collections as needed.

We can implement lazy loading returned objects very easily (with arrays also it may be possible by proxies etc in a long way).
We can easily return (private) inner data (unmodifiable), instead of returning new cloned array each time.
We can share data between multiple threads.
Collection is as simple to use as an array type.

In summary returned collection can be changed to any sub type collection (which is very very useful from implementors perspective) with minimal client changes.

Method Overloading

2004-08-20T18:45:00.000-07:00

There is a chance of surprise/confusion in using methods overloaded with subtype arguments (Effective java #26). e.g.

void foo(String s);
void foo(Long l);
void foo(Object o);
...
// in client code
Object x = "Some String";
foo(x); // call actually goes to foo(object).

Differenent method names instead of overloading is more elegant . e.g see below Bladestore interfaces to delete blades first one with overloaded and second one with different methods.
boolean delete(Blade blade);
boolean delete(long bladeID);
boolean delete(Blade[] blades);
boolean delete(String bladeName);

boolean delete(Blade blade);
boolean deleteById(long id);
boolean deleteByName(String name);
boolean deleteAll(Blade[] blades);

interface with different method names is better, It make intent absolutely clear.

Adding methods like is excess (overaction).

boolean deleteByName(char[] name);
boolean deleteById(Long l);

to second interface is an unnecessary(smelly) overloading. We are not adding any extra benefit.

Moral of the story : Overload only when method intent is absolutely same, method is useful and there is no possibility of confusion.

Methods with too many parameters

2004-08-18T21:28:00.000-07:00

Method with too many parameters (esp in exported api) is a Codestench (?). It makes an API usage a pain. IMO 4-5 parameters should be the practical maximum.

I have seen them evolve in two (anti) patterns. One is a desire to create a feature rich API. And in doing so adding new enhancements very intrusively, e.g by adding a parameter for each parallel feature in existing methods. In turn producing a polluted feature creepy (YAGNI) API, making it very difficult for normal situations.

e.g.
// Normal API to find a blade in database by a its id a long type.
Blade blade = bladeFinder.getBladeById(id);

Developer modified above finder to search by multiple id types (by name, key, by group etc addin one param) , from multiple data sources(adding three params), and multiple service types (ejb/jms/corba servers) in total adding five more parameters.

// Ugly
List blades = (List) bladeFinder.getBlades(idType, id, userid, password, datasourceName, servertype);

In next version developer added a new feature to get data in different formats XML, formatted HTML, Blade object etc (adding one more param for dataformat). As part of this new version a new parameter object is created with all the parameters from old previous finder method + one more to support dataformats. A Response object is also added to wrap return data, exceptions, some more methods. Usage pattren changes to

// The ugly
BladeRequest request = bladeRequestFactory.createReadBladeRequest(idType, id, dataFormat, userid, password, datasourceName, usingJMS, ...);

BladeResponse response = bladeRequestProcessor.processRequest(request);

If (response.getAttribute(somecode).equals(successcode))
Blade blade = (Blade) response.getObjectType(OBJ_FORMAT);
else
String failMessage = (String) response.getFailureObject();

Other pattern is a need/plan to develop very loosely coupled modules. These modules agree only on a minimal set of interfaces and see world very differently.
e.g. proverbial OR mismatch. One layer looks a BladeObject and other looks it as a Map.

Possible refactorings ?

Make one or more parameter objects with all the parameters. We are moving problem from one place to other place.
Setters instead of constructor for Parameter object, with possible defaults for some. (confusing some times, difficult to document etc)
A magic container like properties(map), that server assumes a default for missing properties. (confusing some times, difficult to document etc)
Write Facades to hide ugly code(If we can't change any interfaces or if it is a result of a loose coupling design).
Remove unused features/parameters, computable parameters if any.
If a parameter is an enumeration provide different methods for each type.

The above example can be refactored by removing unneeded features data source (user and password too) parameter. And adding new Criteria a parameter objects and new methods for each data format.

// Refactoring to below
Criteria criteria = ...; // to make a search expression
List /**/blades = bladeFinder.findBlades(criteria);
//or xml as String
List /**/ blades = bladeFinder.findXmlBlades(criteria);

is synchronization not enough?

2004-08-06T22:59:00.000-07:00

java5 has a class called Lock, with methods lock() and unlock(). They can be used to lock in one block and unlock in another block (even in different methods, but needs to be explicitly unlocked unlike synchronized). Lock is termed as an enhancement to synchronization

Now we can write code like
Lock a = ...;
Lock b = ...;
{
a.lock();
}
...;
b.lock();
...;
a.unlock(); // reversing the order.
{
b.unlock();
}

Where to use these, I am waiting for a execuse :)

Six Simple Rules

2004-08-05T21:15:00.000-07:00

Clarity and simplicity are of paramount importance.
Modules should be as small as possible but no smaller.
Code should be reused rather than copied.
The dependencies between modules should be kept to a minimum.
Errors should be detected as soon as possible after they are made, ideally at compile time.
You should not slavishly follow these rules, but you should violate them only occasionally and with good reason.

Jashua Bloch in Effective java.

Java UI - 'some thing is better than nothing'

2004-07-15T20:36:00.000-07:00

Java normal GUI application performance is bad enough. Who needs looking glass and Java3d.

JDNC big deal. Every other language/tool has form building, data/db binding framework for the last 10+ years.

JDIC file explorer, is another example pathetic integration.