WRT Java 5: the current code already has references to Java 5 methods and classes like StringBuilder and Character.isLetterOrDigit
But, the POM only requires Java 1.4, so that's broken. Gary On Tue, Dec 20, 2011 at 10:53 AM, sebb <seb...@gmail.com> wrote: > On 20 December 2011 14:07, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Dec 20, 2011, at 2:02, Damjan Jovanovic <damjan....@gmail.com> wrote: >> >>> On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gwlu...@sonalysts.com> wrote: >>> >>>> I see there's some discussion about the next release of Sanselan between >>>> Damjan Jovanovic, Gary Gregory (I'm the other Gary) and some of the Apache >>>> community leaders. My name was even mentioned... so I thought I'd chime >>>> in. >>>> >>>> First off, Damjan posted a note to the issue tracker that my submitted >>>> patches for performance enhancements aren't going to make it into the 1.0 >>>> release. While I'm naturally disappointed about that, I can understand the >>>> perspective that it is probably the best choice at this time. Also, a delay >>>> would give us more time to refine the concept before we start applying it >>>> to other areas of the code. The only point I would add here is that I >>>> think Sanselan does have problems with performance and that those problems >>>> are really unnecessary. Java is plenty fast nowadays and there's nothing >>>> wrong with the Sanselan code per se, just a rather an unlucky choice on >>>> which API element to use for setting pixel values in an image. I think >>>> that the kind of changes proposed for one small area of the code base (TIFF >>>> images) would have applicability to other parts of the code. I also think >>>> that performance is probably one of the issues might keep Sanselan from >>>> reaching a broader user base. So I'd encourage everyone interested in >>>> Sanselan development to keep that in mind for future releases. >>>> >>> >>> No, I never said your patches wouldn't make it into the 1.0 release. I said >>> they wouldn't make it into the "next" release, which at the time I was >>> thinking would be 0.98, and would be released within days. Things have >>> changed since then, the next release will be 1.0, and it's due later, so >>> maybe your patches will make it. >>> >>> Also I care very much about performance - in fact right now I am optimizing >>> my TIFF CCITT T.4 and T.6 compression algorithms that I will commit later - >>> but premature optimization is said to be the root of all evil, and the >>> state of Sanselan's TIFF parser strikes me as very premature (eg. TIFF is >>> fundamentally a multi-image file format, but there was no support for >>> reading multiple images from TIFF files until my patch yesterday). >>> >>> In terms of renaming the project from "Sanselan" to "Image" or something >>>> like that. Well, I think the key issue here is that the change in name >>>> would signal a much more ambitious concept of what the project is for. To >>>> me, the name Sanselan says "I'm a small and unassuming software package >>>> focused on a particular niche application." The name "Image" or something >>>> like that says "I'm gunning for the JAI, and it's high time somebody did it >>>> too". I wonder if the reason that the original authors chose the obscure >>>> name was that their intentions were fairly modest, though with the amount >>>> of work that went into Sanselan it seems a shame not to promote it. So >>>> I'm strictly on the fence about the whole name change thing. >>>> >>>> >>> Sanselan seems to have started as an image metadata extraction/manipulation >>> project. For example the TIFF image support is flaky, but the parts of TIFF >>> used for JPEG EXIF metadata are excellent. >>> >>> >>>> Finally, I wanted to ask if there would be any problems in changing the >>>> compiler targets in the pom.xml to 1.5 for release 1.0. The current >>>> compiler targets are set up to compile with Java 1.4 features, but I just >>>> switched them to 1.5 and everything build and tested without errors. I'm >>>> not proposing that anyone go make code changes to Sanselan so that it uses >>>> generics or other 1.5 fixtures. Just compile the current code to >>>> accommodate 1.5 rather than being stuck in the 1.4 feature set. By >>>> switching release 1.0 to Java 1.5 does have the advantage that in any new >>>> work, coders will be able to use 1.5 without compatibility issues. >>>> >>>> >>> I was hoping for several small releases with incremental changes, but since >>> we seem to be going the route of a big bang release with many changes, we >>> might as well do the 1.5 upgrade too. >> >> I like release early release often. My intent is to not have big bang >> releases. > > Release early, release often is fine so long as that does not mean > frequent compatibility breaks. > It can be tricky to get an API right; releasing early can make it more > likely that the API will need to be changed later. > >> If someone wants to push a 0.x release now, please do so. > > -1 > > That would be contrary to the Commons versioning rules - a package > name change requires a major version bump. > >> For 1.0, we should make all big changes before 1.0, which may feel >> like a big bang release. Anything that breaks compatibility should be >> done now before a 1.0. > > Agreed. > >> Using java 5 can break source compat once add generics, so you only >> want to do that when you have to. If the java 5 changes are not user >> visible like using enhanced for loops the you can do it anytime. > > Someone else suggested updating source and target version to 1.5, but > not adding generics. > I think the idea was to allow Java 5 methods such as StringBuilder etc. > > However AFAIK this will result in huge numbers of compiler warnings. > Since Apache releases source, IMO we should at least ensure that the > source compiles cleanly. > > So I am -1 on changing the source requirements without fixing generics. > >> But, if someone wants to put the time in now, go for it! :) > >> Performance improvements can come in after for example but I'll let >> someone else make that call. >> >> Now is the time to get the API right. > > Indeed. > >> Gary >>> >>> >>>> Gary >>>> >>>> >>>> >>>> >>>> Computer Programming is the Art of the Possible >>>> Gary W. Lucas >>>> Sonalysts, Inc. >>>> 215 Parkway North >>>> Waterford, CT 06385 >>>> >>> >>> >>> Damjan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
