You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Lucas <gw...@sonalysts.com> on 2011/12/19 20:33:50 UTC
[sanselan] Comments on next release
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.
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.
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.
Gary
Computer Programming is the Art of the Possible
Gary W. Lucas
Sonalysts, Inc.
215 Parkway North
Waterford, CT 06385
Re: [sanselan] Comments on next release
Posted by Gary Gregory <ga...@gmail.com>.
On Dec 19, 2011, at 14:34, Gary Lucas <gw...@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.
>
> 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.
>
> 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.
1.5 is fine by me but I know someone here made a comment about Java
1.4 in relation to JavaME.
I suggest you poll the ML specifically about this move.
Gary
>
> Gary
>
>
>
>
> Computer Programming is the Art of the Possible
> Gary W. Lucas
> Sonalysts, Inc.
> 215 Parkway North
> Waterford, CT 06385
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] Comments on next release
Posted by Jörg Schaible <Jo...@scalaris.com>.
sebb wrote:
> On 20 December 2011 14:07, Gary Gregory <ga...@gmail.com> wrote:
[snip]
> 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.
[snip]
Remember that this also allow the usage of javax.imageio which provides some
more efficient ways to deal with IO for image data.
> 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.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] Comments on next release
Posted by Gary Gregory <ga...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 20 December 2011 14:07, Gary Gregory <ga...@gmail.com> wrote:
>> On Dec 20, 2011, at 2:02, Damjan Jovanovic <da...@gmail.com> wrote:
>>
>>> On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gw...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] Comments on next release
Posted by sebb <se...@gmail.com>.
On 20 December 2011 14:07, Gary Gregory <ga...@gmail.com> wrote:
> On Dec 20, 2011, at 2:02, Damjan Jovanovic <da...@gmail.com> wrote:
>
>> On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gw...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] Comments on next release
Posted by Gary Gregory <ga...@gmail.com>.
On Dec 20, 2011, at 2:02, Damjan Jovanovic <da...@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gw...@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.
If someone wants to push a 0.x release now, please do so.
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.
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.
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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sanselan] Comments on next release
Posted by Damjan Jovanovic <da...@gmail.com>.
On Mon, Dec 19, 2011 at 9:33 PM, Gary Lucas <gw...@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.
> Gary
>
>
>
>
> Computer Programming is the Art of the Possible
> Gary W. Lucas
> Sonalysts, Inc.
> 215 Parkway North
> Waterford, CT 06385
>
Damjan
Re: [sanselan] Comments on next release
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 19/12/2011 20:33, Gary Lucas a écrit :
> 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.
+1 for targeting at least Java 5
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org