On Wednesday 18 September 2002 08:11 am, [EMAIL PROTECTED] wrote: > > from: Steve Downey <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
