From: James M. <jma...@ps...> - 2003-07-10 20:52:32
|
At 06:38 PM 7/9/2003 -0600, Ian Schneider wrote: >Hi all, > >Chris and I had a nice day yesterday planning our attack on the heinous >task of recoding features. Today we had a very productive day in >core/features and defaultcore/features. The current status of both >modules is that the main sources all compile. Tests will probably have >problems, and we have not run them yet. You have indeed been productive, a new email from the cvs server seems to arrive every few minutues! >We (mostly I) may have been a bit agressive in trimming out the fat. >This can be discussed, and in most cases, caused very little side >effects in these two packages. We were (mostly) sure to check useage of >various methods across the gt2 codebase (if we didn't like it, or it was >deprecated and nobody was using it anyway- we slashed it out). Very much needed work, there was indeed a lot of dead junk. There should be no need for any method to be marked as deprecated before we hit our first beta, we should be culling them all prior to release. >The only changes outside of core/features and defaultcore/features was >core/map and the accompianing defaultcore/map. The main problem was the >use of EnvelopeExtent (which was a victim of trimming) and the fact the >Layer was using DataSource. There was actual comments in LayerImpl >regarding the eating of DataSourceExceptions. Not really knowing what to >do, and going with my gut instinct, I replaced the use of DataSource >with FeatureCollection (which, by the way, Chris said "rocks" now). It >seems to make sense that a Layer need not have a DataSource attached to >it. If it does (for display purposes, i.e. Layer[/home/en/city.shp]) >then we can put it back. My thought was we don't want to deal with >potential I/O exceptions within layer itself. Not without some type of >error reporting mechanism anyway. We may want to have some form of name or label meta data in the FeatureCollection that the Layer can use, but I see no reason any more for Layer to have any connection to a DataSource. >Anyhoo, as I mentioned to Chris, the unfortunate splattering of sun.misc >across our codebase has rendered any attempts at cross-jdk portability >useless. I'll take a look at what you are doing - the code in sun.misc is actually quite simple so we can just replicate the parts we need if necessary. >[Before anyone jumps on me for putting classes (not interfaces) in core, >remember, if the factories are in defaultcore, then EVERYONE who uses >them is dependent upon defaultcore.] They won't be the first classes to end up in core, other factories live there. >In addition, before every single class in gt2 becomes a factory, I >suggest we reexamine the goal of making everything j2xxx neutral. I agree, it is too constraining too keep that goal any longer, what we need to look at instead are what things to we want to allow alternate implementations of. Note, that when I say alternate implementations I'm not necessarily talking about alternates that would work with the rest of gt2. For example someone may want the SLD reader to create instances of their own Style objects and not use anything else from gt2. > IMHO, those who want >to keep this type of super-portability should be forced to comb throught >the code and find those packages which don't exist on their particular >j2$!@# and alert others. Otherwise, we are just wasting time and effort. Agreed. >Following the migration and success of tests, we will both migrate our >respective datasources to rely upon the new core/defaultcore >implementations. Sounds like things are going very well, keep up the fantastic work! James |