[OJB-developers] [fyi]: Jakamar / OJB

[Mahler T. <tho...@it...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Erki Suurjaak [mailto:er...@la...]
> Gesendet: Donnerstag, 21. Februar 2002 10:49
> An: Mahler Thomas
> Betreff: Re: Jakamar / OJB
>=20
>=20
> On Tue, 19 Feb 2002, Mahler Thomas wrote:
>=20
> 	Sorry for the delay, had some trouble with the mail server.
>=20
> >I found your thesis on Jakamar on the web.=20
> 	Out of curiosity, how did you come upon it?
>=20
> >I am not that happy with your feature comparison. I don't=20
> know which OJB
> >version you have been looking at. If you check it against the =
current
> >0.7.343 version you will see that only the instantiating of=20
> persistent
> >classes is still not flexible (we still rely on a public=20
> constructor).=20
> >All other points you mention have either been solved or have=20
> never existed
> >(e.g. since version 0.1.1 we allowed compound identities,=20
> support all types
> >specified by JDBC, and allow all type for PK columns etc.)
> 	The version I used was 0.5.155. By integer type PK=20
> columns I meant
> that identity generation assumes integer type. I should have=20
> stated it=20
> more clearly. But some bigger issues, like logging, error handling,=20
> documentation, flexibility in reflection and SQL still stand, I =
think.
> 	But your point is valid - the comparison is outdated and=20
> misleading, especially because I did not, for some obscure=20
> reason, mention=20
> the version number. Since changing the contents of the thesis in the=20
> current form would not be right, I will insert a disclaimer=20
> stating that=20
> several concerns have been already cleared, and that the=20
> benchmarks are=20
> also suspect.
>=20
> >I'm very interested in sharing ideas. I am also keen to=20
> learn how you could
> >make Jakamar that fast!
> 	It was not fast. It's very difficult to say how much effort I=20
> spent on it, since I started in spring 2001, worked on it=20
> sporadically=20
> over the summer and did some long coding marathons before=20
> producing the=20
> thesis. And the bugger is still not as ready as I would like=20
> it to be :)
>=20
> >Are still working on Jakamar? Are you interested in sharing=20
> of ideas or even
> >collaboration.
> 	I am still working. I was planning to make it publicly=20
> available=20
> last year, but then I had an idea to refactor Jakamar to=20
> achieve greater=20
> flexibility and power. Namely, to have a pluggable=20
> ClassMapper that maps a=20
> class onto an RDBMS. Then the present form of mapping classes=20
> (one class=20
> to one table) would just be one case of mapping, and in=20
> addition there=20
> would be mappings between a class and several tables, or=20
> whatever kind of=20
> mapping the users wants to produce themselves.
> 	Unfortunately, this has raised some difficult issues=20
> that I have=20
> not yet managed to solve and at the moment I am stalled.
>=20
> 	It would be very beneficial to incorporate some good aspects of
> Jakamar into OJB. However, I am afraid there is a severe=20
> limit on how much
> OJB can be changed, as it's pretty big and used by many=20
> people already.
> But I'm game.
> 	I'm quite satisfied with some parts of dynamic=20
> configuration that
> Jakamar has. For example, how IdentityGenerators are created - each
> generator has an IdentityGeneratorBuilder that is fed data from the
> configuration file and finally produces a usable object. This=20
> has many=20
> advantages over simple class instantiation. I'm using the=20
> same approach=20
> for creating the ClassMappers I mentioned.
> 	ObjectFactory is a good thing, allowing greater=20
> flexibility when=20
> needed. For example, some people want to reuse objects that=20
> are no longer=20
> needed, to avoid the memory overhead.
> 	ObjectIntrospector is good layer of abstraction, because the=20
> default way of using reflection for direct manipulation might=20
> not do the=20
> trick at all times. OJB is very hard-coded into using Field objects,=20
> eliminating the possibility of invoking accessor methods, for =
example.
> 	Customizable error handling, via a pluggable=20
> ErrorHandlingPolicy,=20
> is pretty good. There is a limit, of course, on what can be done to=20
> mitigate an error, but the possibility of robust performance=20
> is pleasant.=20
> It is quite bothersome, though, to write code that has to=20
> query a policy=20
> to know what to do in case of an error.
>=20
> 	Some words on OJB's error handling. It could be better. =20
> Exceptions should be more varied. For example, Jakamar has=20
> exception types
> ConfigurationException, DataStoreException, ReflectionException, and
> InvalidQueryException, that each carry information in their=20
> type itself.
> For instance, ReflectionException signals that an exception=20
> occurred when
> manipulating object fields.
> 	Some methods in OJB throw exceptions that they shouldn't. For=20
> example,=20
> PersistenceBrokerFactory.createPersistenceBroker(String) throws=20
> exceptions like SAXException, ParserConfigurationException=20
> etc. But the=20
> user has no reason whatsoever to watch out for these exceptions, they =

> should belong to the factory's internal affairs. No method=20
> callable by the=20
> user should throw anything else but an instance of=20
> PersistenceException=20
> (or PersistenceBrokerException in OJB). Unchecked exceptions=20
> aside, of=20
> course. Another thing - in some place, OJB throws a direct=20
> instance of=20
> RuntimeException. This is most definitely bad.
> 	Some methods don't throw exceptions that they should.=20
> For example,
> PersistenceBrokerFactory.createPersistenceBroker() throws no=20
> exception,
> but performs a System.exit in case of an error. There are other =
places
> that just catch an exception, maybe log it, and that's it. This is =
not
> good.
>=20
> 	OJB uses an Iterator for a results cursor. Jakamar has a Cursor
> interface, which extends ListIterator. In this way, the user=20
> can choose
> what kind of behaviour he wants, either that of ListIterator,=20
> Iterator or
> Cursor. Java's iterators has a really bad way of navigation,=20
> Cursor has a
> better one (no mixed query and command methods).
>=20
> 	OJB has Query classes in a separate package. This is a minor=20
> inconvenience for the user who has to import another package for =
this.
>=20
>=20
> 	I would like to help with OJB, as it is a pretty=20
> component, but I=20
> don't know how.
>=20
>=20
>=20
> Erki
>=20