commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [lang] Builders complete?
Date Wed, 18 Sep 2002 17:30:33 GMT
On Wednesday 18 September 2002 08:11 am, scolebourne@btopenworld.com wrote:
> >  from:    Steve Downey <steve.downey@netfolio.com>
> > Post release, there should also be a discussion of introspectionX
> > versions of the reflectionX methods. I know we ruled it out of scope for
> > [lang], since it's more of a bean thing. But the builder classes aren't
> > things that [beanutils] is really doing, at least at the moment. And
> > duplicating the XBuilder classes in [beanutils] doesn't really seem to me
> > to be a good way of serving our clients.
>
> This is the cyclic dependency issue I raised a long time ago. There's no
> simple solution. Unless [beanutils] merges with [lang].
>

I assume you mean the problem of [beanutils] depending on [collections] which 
depends on [lang]. And if there is an incompatible API change, it will take a 
couple of builds for it to be resolved. That shouldn't be to big an issue. 
Formally, each released version should depend on the prior released version 
of the other libraries. If they don't, then there's a release management 
problem in any case.

In practice, dependencies cycles that can actually break things are tricky to 
construct in Java. And long cycles are almost impossible to use to construct 
broken builds. I think if you used a method of an undeclared return type, you 
might be able to do it. But only for one full build cycle. 

Bootstrap is another issue, though. Two ways, as I see it. One is to cross 
build parts of the other projects. For example, org.apache.tomcat.utils is 
used by both catalina and connectors, which are also dependent on each other. 
So, each builds it. The other is to download jars from the prior release.

Another might be to add a source ref to the javac task that references the 
foreign project, and then delete classes not in the project tree. 



> > [Read this as, I've got a really dandy use of ToStringBuilder in mind,
> > except that the classes I've got to work with don't have fields, just
> > getter/setters. Database row objects, generated by Oracle's jpub.]
>
> I guess you are thinking about using the DynaBean classes from BeanUtils.
> These are fine, but are too bean specific for my tastes.
>

No, Oracle has a tool, jpub, that generates classes that mirror Oracle 
database objects. So I've got classes that have, for example, getNAME/setNAME 
methods, but no field NAME. The methods get and set fields in a struct, ie 
_stuct.setOracleProperty(3, NAME);
or
(oracle.sql.CHAR) _struct.getOracleProperty(3);
It's a good example of a bean where property != field.

But beanutils doesn't have anything that manipulates the beans. It's focus is 
more about manipulating bean information. 

I actually want to output flat data., not XML, so betwixt isn't in scope.

The ToStringBuilder does almost exactly what I want, except that I don't have 
fields, just properties.

> I've been trying to play with a new [clazz] project. This would define an
> interface based definition for a class, like DynaBean, but have lots of
> supporting code for introspecting values in different ways. Ideally, it
> would then extend to include BCEL generation. But there are lack of time
> pressures ;-)
>
> Stephen


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message