You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2008/02/05 05:47:20 UTC
[io] 2.0 Moving to minimum of JDK 1.5
We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
theres also an JIRA report here:
http://issues.apache.org/jira/browse/IO-140
>From memory the preference was to move to a new package name - how
about "org.apache.commons.io2"?
Are there any objections to me creating an IO 1.4 branch from the
current trunk and then starting work on IO 2.0 in the trunk.
Initial plans would be:
- rename to the new package
- remove deprecated items
- Making appropriate JDK 1.5 changes (generics, using StringBuilder
and new Appendable for Writers etc).
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 5, 2008 6:09 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > Sent: Tuesday, February 05, 2008 9:52 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > On Feb 5, 2008 5:49 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > > Should we come up with a general package naming convention for all commons
> > projects and Java 5?
> > >
> > > Either:
> > >
> > > org.apache.commons.io2
> > > org.apache.commons.lang2
> > > org.apache.commons.[project]2
> > >
> > > Or:
> > >
> > > org.apache.commons2.io
> > > org.apache.commons2.lang
> > > org.apache.commons2.[project]
> > >
> > > Where the minimum requirement will be Java 5, or perhaps:
> > >
> > > org.apache.commons5.io
> > > org.apache.commons5.lang
> > > org.apache.commons5.[project]
> > >
> > > ?
> >
> > I think the packages shoud stay "org.apache.commons" - how about using
> > "v" as the qualifier - roman numeral for five - so
> >
> > org.apache.commons.iov
> > org.apache.commons.langv
> > org.apache.commons.[project]v
> >
> > Niall
>
> A long time ago, in that other galaxy, I worked on a product called 'Smalltalk/V', and guess what some people called it? 'Smalltalk Five', where in fact the 'V' stood for Virtual. So I know folks are going to ask what /is/ the difference is between 'lang' and 'lang vee' ;-) Since it is not called 'Java V (roman numeral)', we should not, IMO, have Project V, so if we do want to put a suffix, I'd say a number would be better that a letter.
OK well I'm happy with "org.apache.commons.io2"
Niall
> Gary
>
>
> >
> > > Thank you,
> > > Gary
> > >
> > >
> > > > -----Original Message-----
> > > > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > > > Sent: Monday, February 04, 2008 8:47 PM
> > > > To: Commons Developers List
> > > > Subject: [io] 2.0 Moving to minimum of JDK 1.5
> > > >
> > > > We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> > > > theres also an JIRA report here:
> > > > http://issues.apache.org/jira/browse/IO-140
> > > >
> > > > From memory the preference was to move to a new package name - how
> > > > about "org.apache.commons.io2"?
> > > >
> > > > Are there any objections to me creating an IO 1.4 branch from the
> > > > current trunk and then starting work on IO 2.0 in the trunk.
> > > >
> > > > Initial plans would be:
> > > >
> > > > - rename to the new package
> > > > - remove deprecated items
> > > > - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> > > > and new Appendable for Writers etc).
> > > >
> > > > Niall
> > > >
> > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Tuesday, February 05, 2008 9:52 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On Feb 5, 2008 5:49 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > Should we come up with a general package naming convention for all commons
> projects and Java 5?
> >
> > Either:
> >
> > org.apache.commons.io2
> > org.apache.commons.lang2
> > org.apache.commons.[project]2
> >
> > Or:
> >
> > org.apache.commons2.io
> > org.apache.commons2.lang
> > org.apache.commons2.[project]
> >
> > Where the minimum requirement will be Java 5, or perhaps:
> >
> > org.apache.commons5.io
> > org.apache.commons5.lang
> > org.apache.commons5.[project]
> >
> > ?
>
> I think the packages shoud stay "org.apache.commons" - how about using
> "v" as the qualifier - roman numeral for five - so
>
> org.apache.commons.iov
> org.apache.commons.langv
> org.apache.commons.[project]v
>
> Niall
A long time ago, in that other galaxy, I worked on a product called 'Smalltalk/V', and guess what some people called it? 'Smalltalk Five', where in fact the 'V' stood for Virtual. So I know folks are going to ask what /is/ the difference is between 'lang' and 'lang vee' ;-) Since it is not called 'Java V (roman numeral)', we should not, IMO, have Project V, so if we do want to put a suffix, I'd say a number would be better that a letter.
Gary
>
> > Thank you,
> > Gary
> >
> >
> > > -----Original Message-----
> > > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > > Sent: Monday, February 04, 2008 8:47 PM
> > > To: Commons Developers List
> > > Subject: [io] 2.0 Moving to minimum of JDK 1.5
> > >
> > > We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> > > theres also an JIRA report here:
> > > http://issues.apache.org/jira/browse/IO-140
> > >
> > > From memory the preference was to move to a new package name - how
> > > about "org.apache.commons.io2"?
> > >
> > > Are there any objections to me creating an IO 1.4 branch from the
> > > current trunk and then starting work on IO 2.0 in the trunk.
> > >
> > > Initial plans would be:
> > >
> > > - rename to the new package
> > > - remove deprecated items
> > > - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> > > and new Appendable for Writers etc).
> > >
> > > Niall
> > >
> >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 5, 2008 5:49 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Should we come up with a general package naming convention for all commons projects and Java 5?
>
> Either:
>
> org.apache.commons.io2
> org.apache.commons.lang2
> org.apache.commons.[project]2
>
> Or:
>
> org.apache.commons2.io
> org.apache.commons2.lang
> org.apache.commons2.[project]
>
> Where the minimum requirement will be Java 5, or perhaps:
>
> org.apache.commons5.io
> org.apache.commons5.lang
> org.apache.commons5.[project]
>
> ?
I think the packages shoud stay "org.apache.commons" - how about using
"v" as the qualifier - roman numeral for five - so
org.apache.commons.iov
org.apache.commons.langv
org.apache.commons.[project]v
Niall
> Thank you,
> Gary
>
>
> > -----Original Message-----
> > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > Sent: Monday, February 04, 2008 8:47 PM
> > To: Commons Developers List
> > Subject: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> > theres also an JIRA report here:
> > http://issues.apache.org/jira/browse/IO-140
> >
> > From memory the preference was to move to a new package name - how
> > about "org.apache.commons.io2"?
> >
> > Are there any objections to me creating an IO 1.4 branch from the
> > current trunk and then starting work on IO 2.0 in the trunk.
> >
> > Initial plans would be:
> >
> > - rename to the new package
> > - remove deprecated items
> > - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> > and new Appendable for Writers etc).
> >
> > Niall
> >
>
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Should we come up with a general package naming convention for all commons projects and Java 5?
Either:
org.apache.commons.io2
org.apache.commons.lang2
org.apache.commons.[project]2
Or:
org.apache.commons2.io
org.apache.commons2.lang
org.apache.commons2.[project]
Where the minimum requirement will be Java 5, or perhaps:
org.apache.commons5.io
org.apache.commons5.lang
org.apache.commons5.[project]
?
Thank you,
Gary
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Monday, February 04, 2008 8:47 PM
> To: Commons Developers List
> Subject: [io] 2.0 Moving to minimum of JDK 1.5
>
> We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> theres also an JIRA report here:
> http://issues.apache.org/jira/browse/IO-140
>
> From memory the preference was to move to a new package name - how
> about "org.apache.commons.io2"?
>
> Are there any objections to me creating an IO 1.4 branch from the
> current trunk and then starting work on IO 2.0 in the trunk.
>
> Initial plans would be:
>
> - rename to the new package
> - remove deprecated items
> - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> and new Appendable for Writers etc).
>
> Niall
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 7, 2008 8:10 AM, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Niall Pemberton wrote:
> >>> [Note CharSequence replaces String and/or StringBuffer flavours]
> >
> > OK for the above I added new methods, rather than changing the method
> > signature - so still compatbile atm:
> > http://svn.apache.org/viewvc?view=rev&revision=619188
>
> Although, the API is now bigger. If we decide to break binary
> compatibility later, we need to remember to delete duplicates like this.
>
> >> All the other changes are binary compatible. Except for the problem that
> >> the bytecode format for Java 5 is different as well, so you'd need
> >> retrotranslator to help you out as well.
> >
> > Anything that depends on a JDK 1.5 IO version will have to also be
> > minimum JDK 1.5 and therefore direct or indirect users must be
> > running on JDK 1.5 - so I don't see any need for retrotranslator or
> > issues for users. Have I missed something?
>
> Hmm, yes we should be OK.
>
> >> In addition to the changes above, you will probably want to change most
> >> APIs that take in a Collection to take an Iterable instead.
> > OK I just had a quick scan and it looks we have the following methods
> > where we could do this:
> > FilenameUtils.isExtension()
> > FileUtils.convertFileCollectionToFileArray()
> > FileUtils.writeLines()
> > IOUtils.writeLines()
> > but this could also be done by just adding new flavours with an
> > Iterable, rather than changing the existing methods.
>
> Agreed, additional method can be added. Its certainly not as neat as
> just one method, and deprecation won't help (as any code linking to [io]
> will always pick the method taking a Collection, until the method is
> removed - hence removing the deprecation will never really be possible).
>
> >> We should probably remove all references to arrays in the public API, as
> >> generics and arrays work badly together, and I would strongly recommend
> >> treating arrays as a type not to be exposed on any public API post-Java5.
> >
> > Perhaps you could expand more on this because I don't see a big issue
> > for IO. - are you thinking along the following lines:
> > http://www.tbray.org/ongoing/When/200x/2005/06/12/Comparable
>
> Kind of. Arrays and Generics do not work well together. One example is
> passing a generified list to a vararge method:
> public void process(List<String>... values)
> This will always generate a warning, as the list gets converted to an array.
OK I'm not convinced by this. "Arrays and Generics do not work well
together" is a big generalization and your example doesn't relate to
arrays - from this you could say "varargs and Generics don't work well
together" so lets not use varargs in IO, but I don't see how it
relates to arrays.
How about Commons IO examples:
1) NameFileFilter has both String[] and List constructors:
public NameFileFilter(List<String>)
public NameFileFilter(String[])
IMO this provides choice for the user - how would removing the
String[] constructor benefit the user in any way?
2) I guess the other side of the equation is where we return an array,
there doesn't seem many cases of this, a quick scan showed these:
- FileUtils.convertFileCollectionToFileArray()
- FileUtils.readFileToByteArray()
- FileUtils.toFiles()
- FileUtils.toURLs()
- IOUtils.toByteArray()
- IOUtils.toCharArray()
Most seem appropriate, but perhaps toFiles() / toURLs() could return
an Iterable - but I could just as well envisage unhappy users who
prefer getting an array - better in that use case to provide two
flavours of methods so that the user can choose.
> In general, arrays work poorly with generics, to the point that you
> can't avoid the warnings. My recommendation would be to replace arrays
> in the API with Collection/Iterable/List as appropriate. Existing API
> users can easily adapt, and they will thank us for the lack of warnings.
I think you need to make a better case for this kind of policy.
Niall
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Niall Pemberton wrote:
>>> [Note CharSequence replaces String and/or StringBuffer flavours]
>
> OK for the above I added new methods, rather than changing the method
> signature - so still compatbile atm:
> http://svn.apache.org/viewvc?view=rev&revision=619188
Although, the API is now bigger. If we decide to break binary
compatibility later, we need to remember to delete duplicates like this.
>> All the other changes are binary compatible. Except for the problem that
>> the bytecode format for Java 5 is different as well, so you'd need
>> retrotranslator to help you out as well.
>
> Anything that depends on a JDK 1.5 IO version will have to also be
> minimum JDK 1.5 and therefore direct or indirect users must be
> running on JDK 1.5 - so I don't see any need for retrotranslator or
> issues for users. Have I missed something?
Hmm, yes we should be OK.
>> In addition to the changes above, you will probably want to change most
>> APIs that take in a Collection to take an Iterable instead.
> OK I just had a quick scan and it looks we have the following methods
> where we could do this:
> FilenameUtils.isExtension()
> FileUtils.convertFileCollectionToFileArray()
> FileUtils.writeLines()
> IOUtils.writeLines()
> but this could also be done by just adding new flavours with an
> Iterable, rather than changing the existing methods.
Agreed, additional method can be added. Its certainly not as neat as
just one method, and deprecation won't help (as any code linking to [io]
will always pick the method taking a Collection, until the method is
removed - hence removing the deprecation will never really be possible).
>> We should probably remove all references to arrays in the public API, as
>> generics and arrays work badly together, and I would strongly recommend
>> treating arrays as a type not to be exposed on any public API post-Java5.
>
> Perhaps you could expand more on this because I don't see a big issue
> for IO. - are you thinking along the following lines:
> http://www.tbray.org/ongoing/When/200x/2005/06/12/Comparable
Kind of. Arrays and Generics do not work well together. One example is
passing a generified list to a vararge method:
public void process(List<String>... values)
This will always generate a warning, as the list gets converted to an array.
In general, arrays work poorly with generics, to the point that you
can't avoid the warnings. My recommendation would be to replace arrays
in the API with Collection/Iterable/List as appropriate. Existing API
users can easily adapt, and they will thank us for the lack of warnings.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 6, 2008 8:25 PM, Stephen Colebourne <sc...@btopenworld.com> wrote:
> The following would be binary backwards incompatible:
>
> > FileUtils
> > - public static void writeStringToFile(File file, CharSequence data,
> > String encoding)
> > [note CharSequence version replaces String falvour]
>
> > IOUtils
> > - public static InputStream toInputStream(CharSequence input)
> > - public static InputStream toInputStream(CharSequence input, String encoding)
> > - public static void write(CharSequence data, Writer output)
> > - public static void write(CharSequence data, OutputStream output)
> > - public static void write(CharSequence data, OutputStream output,
> > String encoding)
> > [Note CharSequence replaces String and/or StringBuffer flavours]
>
> > So the changes are pretty minimal for IO - question is are these
> > incompatible changes with generics being erased? If not then perhaps
> > we can do this without breaking anything.
OK for the above I added new methods, rather than changing the method
signature - so still compatbile atm:
http://svn.apache.org/viewvc?view=rev&revision=619188
> All the other changes are binary compatible. Except for the problem that
> the bytecode format for Java 5 is different as well, so you'd need
> retrotranslator to help you out as well.
Anything that depends on a JDK 1.5 IO version will have to also be
minimum JDK 1.5 and therefore direct or indirect users must be
running on JDK 1.5 - so I don't see any need for retrotranslator or
issues for users. Have I missed something?
> In addition to the changes above, you will probably want to change most
> APIs that take in a Collection to take an Iterable instead.
OK I just had a quick scan and it looks we have the following methods
where we could do this:
FilenameUtils.isExtension()
FileUtils.convertFileCollectionToFileArray()
FileUtils.writeLines()
IOUtils.writeLines()
but this could also be done by just adding new flavours with an
Iterable, rather than changing the existing methods.
> We should probably remove all references to arrays in the public API, as
> generics and arrays work badly together, and I would strongly recommend
> treating arrays as a type not to be exposed on any public API post-Java5.
Perhaps you could expand more on this because I don't see a big issue
for IO - are you thinking along the following lines:
http://www.tbray.org/ongoing/When/200x/2005/06/12/Comparable
or something else?
Niall
> Both these changes would be backwards incompatible.
>
> Finally, we should look to see if we can use the Appendable interface in
> any of our APIs. This may also result in incompatible changes.
>
>
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The following would be binary backwards incompatible:
> FileUtils
> - public static void writeStringToFile(File file, CharSequence data,
> String encoding)
> [note CharSequence version replaces String falvour]
> IOUtils
> - public static InputStream toInputStream(CharSequence input)
> - public static InputStream toInputStream(CharSequence input, String encoding)
> - public static void write(CharSequence data, Writer output)
> - public static void write(CharSequence data, OutputStream output)
> - public static void write(CharSequence data, OutputStream output,
> String encoding)
> [Note CharSequence replaces String and/or StringBuffer flavours]
> So the changes are pretty minimal for IO - question is are these
> incompatible changes with generics being erased? If not then perhaps
> we can do this without breaking anything.
All the other changes are binary compatible. Except for the problem that
the bytecode format for Java 5 is different as well, so you'd need
retrotranslator to help you out as well.
In addition to the changes above, you will probably want to change most
APIs that take in a Collection to take an Iterable instead.
We should probably remove all references to arrays in the public API, as
generics and arrays work badly together, and I would strongly recommend
treating arrays as a type not to be exposed on any public API post-Java5.
Both these changes would be backwards incompatible.
Finally, we should look to see if we can use the Appendable interface in
any of our APIs. This may also result in incompatible changes.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Torsten Curdt <tc...@apache.org>.
I agree with James here. Spanning across packages makes this whole
thing overly complex. IMO we should keep it easy and consistent.
org.apache.commons.io = 1.x
org.apache.commons.io2 = 2.x
...
I think we are a little too afraid to maintain a second branch here.
I know we are few people. But if we switch to 2.x and move 1.x to
bugfix mode only. Upgrading to 2.x should not be that bad. For some
maybe not even more than a organize imports. No one is forced to
upgrade. So I don't really see the point of making our life harder
than it is.
cheers
--
Torsten
On 08.02.2008, at 14:49, James Carman wrote:
> So, you are suggesting having part of a release in the o.a.c.io
> package and the other part in the o.a.c.io2? It seems rather
> inconsistent, but I guess it would work. Isn't that going to get
> ugly with 3.x and 4.x releases adding to the mix?
>
> On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Feb 6, 2008 1:51 PM, Niall Pemberton
>> <ni...@gmail.com> wrote:
>>> So the changes are pretty minimal for IO - question is are these
>>> incompatible changes with generics being erased? If not then perhaps
>>> we can do this without breaking anything.
>>
>> +1 If there are cases where we can't avoid breaking backwards
>> compatibility, then let's use the name2 pattern on individual classes
>> or interfaces instead of the entire o.a.c.io package. There are large
>> parts of Commons IO that don't need to change when upgrading to
>> Java 5
>> and I don't see why a client that only uses those parts should be
>> affected in any way by the upgrade.
>>
>> BR,
>>
>> Jukka Zitting
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by James Carman <ja...@carmanconsulting.com>.
On 2/11/08, Gary Gregory <GG...@seagullsoftware.com> wrote:
> In my mind, the point of io2 (as in, the next version plus the possible repackaging) is to allow us to (re)write io2 with Java 5 in mind. For example, you would never use a raw type in the API or internally. Any other non collection generics APIs (array parameters) left would be for backward compatibility. But for new APIs, we just need to think what is the best for an API parameter, for example, an array or a generics collections? I think we are going with generics from now on.
>
+1 on "rewrite with Java 5 in mind" Not necessarily for io2,
specifically, but that's what I see as a major reason to bump to a new
major release number for some libraries (collections comes to mind).
> Thank you,
> Gary
>
> > -----Original Message-----
> > From: Torsten Curdt [mailto:tcurdt@apache.org]
> > Sent: Monday, February 11, 2008 4:39 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > >> Additionally, nobody stops us from shipping an io compat library
> > >> which translates the
> > >> calls original io 1.x calls for io2. That one can be used as real
> > >> replacement of old 1.x
> > >> series, but offers the possibility to use as much Java 5 specifics
> > >> as possible in the
> > >> new API (varargs, new interfaces, generics, enums, ...).
> > >
> > > I still don't see the need to overhaul the entire API.
> >
> > And I don't see the point why we shouldn't. Going from from java 1.4 -
> > > 1.5 usually means a bit overhaul.
> > No one forces anyone to switch from 1.x to 2.x.
> >
> > cheers
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
In my mind, the point of io2 (as in, the next version plus the possible repackaging) is to allow us to (re)write io2 with Java 5 in mind. For example, you would never use a raw type in the API or internally. Any other non collection generics APIs (array parameters) left would be for backward compatibility. But for new APIs, we just need to think what is the best for an API parameter, for example, an array or a generics collections? I think we are going with generics from now on.
Thank you,
Gary
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@apache.org]
> Sent: Monday, February 11, 2008 4:39 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> >> Additionally, nobody stops us from shipping an io compat library
> >> which translates the
> >> calls original io 1.x calls for io2. That one can be used as real
> >> replacement of old 1.x
> >> series, but offers the possibility to use as much Java 5 specifics
> >> as possible in the
> >> new API (varargs, new interfaces, generics, enums, ...).
> >
> > I still don't see the need to overhaul the entire API.
>
> And I don't see the point why we shouldn't. Going from from java 1.4 -
> > 1.5 usually means a bit overhaul.
> No one forces anyone to switch from 1.x to 2.x.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 12, 2008 12:27 AM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Perhaps we should do the following in trunk:
>
> 1) Generify (I know, it's not a word and it is funny that my spellchecker suggests 'gentrify')) everything
> and keep backwards compatibility (this has started)
> 2) Re-implement using Java 5 APIs where appropriate. For example, if we catch and re-throw an
> exception, make sure we pass the cause up the chain.
> 3) See what it all looks like
> 4) Discuss what old style APIs to remove if any. For example: Do we keep foo(Type[]) when we
> now have foo(List<Type>)) or foo(Iterable<Type>)
+1 Sounds good to me. This discussion will be much more productive
when we have concrete changes to look at.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Perhaps we should do the following in trunk:
1) Generify (I know, it's not a word and it is funny that my spellchecker suggests 'gentrify')) everything and keep backwards compatibility (this has started)
2) Re-implement using Java 5 APIs where appropriate. For example, if we catch and re-throw an exception, make sure we pass the cause up the chain.
3) See what it all looks like
4) Discuss what old style APIs to remove if any. For example: Do we keep foo(Type[]) when we now have foo(List<Type>)) or foo(Iterable<Type>)
Gary
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@apache.org]
> Sent: Monday, February 11, 2008 10:34 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> >>> I still don't see the need to overhaul the entire API.
> >>
> >> And I don't see the point why we shouldn't. Going from from java 1.4
> >> -> 1.5 usually means a bit overhaul.
> >
> > Perhaps usually, but for Commons IO?
>
> The question was - why not? We are running around in circles here.
>
> > I see only a few isolated candidates for Java 5 improvements
>
> <snip/>
>
> Counting that's already 4 :)
>
> > Do such isolated changes justify changing the entire API? Or do you
> > have some other major changes in mind?
>
> Hell, it's a new version and no one would be required to upgrade. And
> upgrading would still be easy. So why not get rid of some cruft.
>
> Could we maybe just settle on doing the changes on a branch first and
> then discuss compatibility and a possible merge?
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Torsten Curdt <tc...@apache.org>.
>>> I still don't see the need to overhaul the entire API.
>>
>> And I don't see the point why we shouldn't. Going from from java 1.4
>> -> 1.5 usually means a bit overhaul.
>
> Perhaps usually, but for Commons IO?
The question was - why not? We are running around in circles here.
> I see only a few isolated candidates for Java 5 improvements
<snip/>
Counting that's already 4 :)
> Do such isolated changes justify changing the entire API? Or do you
> have some other major changes in mind?
Hell, it's a new version and no one would be required to upgrade. And
upgrading would still be easy. So why not get rid of some cruft.
Could we maybe just settle on doing the changes on a branch first and
then discuss compatibility and a possible merge?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 11, 2008 2:38 PM, Torsten Curdt <tc...@apache.org> wrote:
> > I still don't see the need to overhaul the entire API.
>
> And I don't see the point why we shouldn't. Going from from java 1.4
> -> 1.5 usually means a bit overhaul.
Perhaps usually, but for Commons IO?
I see only a few isolated candidates for Java 5 improvements in the
filefilter, input, and output subpackages, and the comparator package
is mostly covered already by Niall's changes that AFAIUI are backwards
compatible. In the main io package there are some methods that would
benefit from Java 5 features, but they are also a minority.
Do such isolated changes justify changing the entire API? Or do you
have some other major changes in mind?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Torsten Curdt <tc...@apache.org>.
>> Additionally, nobody stops us from shipping an io compat library
>> which translates the
>> calls original io 1.x calls for io2. That one can be used as real
>> replacement of old 1.x
>> series, but offers the possibility to use as much Java 5 specifics
>> as possible in the
>> new API (varargs, new interfaces, generics, enums, ...).
>
> I still don't see the need to overhaul the entire API.
And I don't see the point why we shouldn't. Going from from java 1.4 -
> 1.5 usually means a bit overhaul.
No one forces anyone to switch from 1.x to 2.x.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 11, 2008 11:02 AM, Jörg Schaible
<Jo...@elsag-solutions.com> wrote:
> Additionally, nobody stops us from shipping an io compat library which translates the
> calls original io 1.x calls for io2. That one can be used as real replacement of old 1.x
> series, but offers the possibility to use as much Java 5 specifics as possible in the
> new API (varargs, new interfaces, generics, enums, ...).
I still don't see the need to overhaul the entire API. Do we have some
specific cases where switching to Java 5 features would be both
backwards incompatible and worth making?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Gary Gregory wrote:
> Ag, let's not have /both/ io and io2, this gets messy.
+1
Additionally, nobody stops us from shipping an io compat library which translates the calls original io 1.x calls for io2. That one can be used as real replacement of old 1.x series, but offers the possibility to use as much Java 5 specifics as possible in the new API (varargs, new interfaces, generics, enums, ...).
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Mark Fortner <ph...@gmail.com>.
Just out of curiosity, would it be possible to maintain a single API and
have separate implementation JARs? Or are there plans to change method
signatures as well (such as to add generics or NIO support)? If the method
signatures remained the same but the internal implementations were updated
it might be possible to give users a more easily pluggable update to IO.
Regards,
Mark Fortner
On Feb 8, 2008 8:07 AM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> Ag, let's not have /both/ io and io2, this gets messy.
>
> Thank you,
> Gary
>
> > -----Original Message-----
> > From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
> > On Behalf Of James Carman
> > Sent: Friday, February 08, 2008 5:50 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > So, you are suggesting having part of a release in the o.a.c.io
> > package and the other part in the o.a.c.io2? It seems rather
> > inconsistent, but I guess it would work. Isn't that going to get
> > ugly with 3.x and 4.x releases adding to the mix?
> >
> > On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > > Hi,
> > >
> > > On Feb 6, 2008 1:51 PM, Niall Pemberton <ni...@gmail.com>
> wrote:
> > > > So the changes are pretty minimal for IO - question is are these
> > > > incompatible changes with generics being erased? If not then perhaps
> > > > we can do this without breaking anything.
> > >
> > > +1 If there are cases where we can't avoid breaking backwards
> > > compatibility, then let's use the name2 pattern on individual classes
> > > or interfaces instead of the entire o.a.c.io package. There are large
> > > parts of Commons IO that don't need to change when upgrading to Java 5
> > > and I don't see why a client that only uses those parts should be
> > > affected in any way by the upgrade.
> > >
> > > BR,
> > >
> > > Jukka Zitting
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Mark Fortner
blog: http://www.jroller.com/phidias
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Ag, let's not have /both/ io and io2, this gets messy.
Thank you,
Gary
> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
> On Behalf Of James Carman
> Sent: Friday, February 08, 2008 5:50 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> So, you are suggesting having part of a release in the o.a.c.io
> package and the other part in the o.a.c.io2? It seems rather
> inconsistent, but I guess it would work. Isn't that going to get
> ugly with 3.x and 4.x releases adding to the mix?
>
> On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > Hi,
> >
> > On Feb 6, 2008 1:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > > So the changes are pretty minimal for IO - question is are these
> > > incompatible changes with generics being erased? If not then perhaps
> > > we can do this without breaking anything.
> >
> > +1 If there are cases where we can't avoid breaking backwards
> > compatibility, then let's use the name2 pattern on individual classes
> > or interfaces instead of the entire o.a.c.io package. There are large
> > parts of Commons IO that don't need to change when upgrading to Java 5
> > and I don't see why a client that only uses those parts should be
> > affected in any way by the upgrade.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
We should get more specific on APIs here and what the problem is. If an algorithm changes, this is the same problem we have with a new version of any project. Either it's a bug fix and it is ok to change the behavior or it is not a bug fix and you need to decide if the behavior must be backward compatible. If it must be, then you need a new method name. Or a new class I suppose for pluggable classes. This can be dealt with on a case by case basis and is a separate discussion IMO.
The major differences in API I see is with generics, when we have today a class with possibly all of:
1) void fooArr(Foo[]);
2) void fooList(List listOfFoos);
3) Bar[] barArr(Bar[]);
4) List barList(List listOfBars);
we want tomorrow, to replace 4) withy:
2) void fooList(List<Foo> listOfFoos);
4) List<Bar> barList(List<Bar> listOfBars);
The question is: *What is the policy WRT 1, and 3?*
a) Keep the APIs as is.
b) Deprecate
c) Remove
Changing call sites from arrays to list is easy and mechanical but can be an extensive change. So I would start io2 with a) or b) at worst.
Thank you,
Gary
> -----Original Message-----
> From: jcarman@carmanconsulting.com [mailto:jcarman@carmanconsulting.com]
> On Behalf Of James Carman
> Sent: Friday, February 08, 2008 7:24 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > Hi,
> >
> > On Feb 8, 2008 3:49 PM, James Carman <ja...@carmanconsulting.com> wrote:
> > > So, you are suggesting having part of a release in the o.a.c.io
> > > package and the other part in the o.a.c.io2?
> >
> > No. I'd keep everything in o.a.c.io.
> >
> > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > be changed extensively to match "Java 5 style", then I'd name the
> > modified version o.a.c.io.SomeClass2 (or something better if
> > possible).
> >
>
> I don't know about that. Then, we could potentially have classes like
> SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> wouldn't be as easy to upgrade to a new version. If it were done the
> other way, folks could just do a find/replace on the package name in
> their code and be done.
>
> On the other hand, it does allow you to introduce new incompatible
> logic without requiring a new major release. Hopefully folks wouldn't
> abuse that.
>
>
> > I assume such cases to be the exception rather than the rule, so I
> > don't see the point in renaming the entire package.
> >
> > Java 5 is just an enabler of new features (generics, etc.), it doesn't
> > magically make existing APIs obsolete. Sure, you probably want to
> > adjust collection types, but that's just like any other API change
> > request.
> >
> > BR,
> >
> > Jukka Zitting
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 8, 2008 6:32 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > You'd only need to upgrade to SomeClass2 if you actually need the new
> > functionality, otherwise you could just keep using the old API when
> > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> > need to update their code when upgrading even if no part of the API
> > they touch has changed.
>
> I do not think this last paragraph is correct. The io2 package is
> not only free to introduce generics in the API, it is also free to
> use Java 5 features in its internal implementation.
Perhaps I'm being dense, but I don't get why we couldn't use Java 5
features in the internal implementation of the current Commons IO API?
If we declare Java 5 as a requirement for IO 2.x, then those Java 5
features should be available wherever you deploy the library and it
shouldn't matter how the internals work as long as the public API
remains backwards compatible.
We can always backport fixes and new functionality that don't depend
on Java 5 features to a 1.x branch that runs on earlier JVMs. There
should be no problem to keep such backports upwards compatible, so
that a 1.x client would remain functional when deployed with IO 2.x in
a Java 5 environment.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 9, 2008 8:01 AM, Gary Gregory <GG...@seagullsoftware.com> wrote:
>
> > -----Original Message-----
> > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > Sent: Friday, February 08, 2008 5:40 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > On Feb 8, 2008 4:32 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > > > From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> > > > Sent: Friday, February 08, 2008 8:24 AM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> > > >
> > > > Hi,
> > > >
> > > > On Feb 8, 2008 5:24 PM, James Carman <ja...@carmanconsulting.com>
> > wrote:
> > > > > On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > > > > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > > > > > be changed extensively to match "Java 5 style", then I'd name the
> > > > > > modified version o.a.c.io.SomeClass2 (or something better if
> > > > > > possible).
> > > > >
> > > > > I don't know about that. Then, we could potentially have classes like
> > > > > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> > > > > wouldn't be as easy to upgrade to a new version. If it were done the
> > > > > other way, folks could just do a find/replace on the package name in
> > > > > their code and be done.
> > > >
> > > > Why I should need the find/replace in the first place? A find/replace
> > > > won't help with any fundamental API incompatibilities that would
> > > > trigger the creation of SomeClass2.
> > > >
> > > > You'd only need to upgrade to SomeClass2 if you actually need the new
> > > > functionality, otherwise you could just keep using the old API when
> > > > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> > > > need to update their code when upgrading even if no part of the API
> > > > they touch has changed.
> > >
> > > I do not think this last paragraph is correct. The io2 package is not only free to
> > introduce generics in the API, it is also free to use Java 5 features in its internal
> > implementation. This gives us the freedom to use all Java 5 features in io2 while
> > keeping the API or most of it the same. So if you are using io2, you must use Java
> > 5. If you have a 3rd party library that depends on io (v1.x), then you need the io
> > package around too.
> >
> > But why does changing to use generics make it incompatible - since
> > java erases generics?
> >
> > So far I believe all the JDK 1.5 changes I've done (including
> > generics) are backward compatible - clirr thinks so except when I
> > changed the LineIterator next() method to return a String rather than
> > Object - but I think thats an error on clirrs part.
>
> Since it looks like we are keeping [] parameters instead of replacing them with List<T> that might work out.
>
> I say we complete the conversion to generics and see where that leaves us. I have some generics pending commits that I'll push out in that dept.
OK sounds good.
Niall
> Gary
>
> >
> > Niall
> >
> > > So, in short, you need all of io v2 in io2 and all of io v1 in io. This allows for an
> > application to depend on both and allows io2 to use all of Java 5 internally and in
> > presenting its external API.
> >
> > > Gary
> > >
> > >
> > > >
> > > > BR,
> > > >
> > > > Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Friday, February 08, 2008 5:40 PM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> On Feb 8, 2008 4:32 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > > From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> > > Sent: Friday, February 08, 2008 8:24 AM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> > >
> > > Hi,
> > >
> > > On Feb 8, 2008 5:24 PM, James Carman <ja...@carmanconsulting.com>
> wrote:
> > > > On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > > > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > > > > be changed extensively to match "Java 5 style", then I'd name the
> > > > > modified version o.a.c.io.SomeClass2 (or something better if
> > > > > possible).
> > > >
> > > > I don't know about that. Then, we could potentially have classes like
> > > > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> > > > wouldn't be as easy to upgrade to a new version. If it were done the
> > > > other way, folks could just do a find/replace on the package name in
> > > > their code and be done.
> > >
> > > Why I should need the find/replace in the first place? A find/replace
> > > won't help with any fundamental API incompatibilities that would
> > > trigger the creation of SomeClass2.
> > >
> > > You'd only need to upgrade to SomeClass2 if you actually need the new
> > > functionality, otherwise you could just keep using the old API when
> > > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> > > need to update their code when upgrading even if no part of the API
> > > they touch has changed.
> >
> > I do not think this last paragraph is correct. The io2 package is not only free to
> introduce generics in the API, it is also free to use Java 5 features in its internal
> implementation. This gives us the freedom to use all Java 5 features in io2 while
> keeping the API or most of it the same. So if you are using io2, you must use Java
> 5. If you have a 3rd party library that depends on io (v1.x), then you need the io
> package around too.
>
> But why does changing to use generics make it incompatible - since
> java erases generics?
>
> So far I believe all the JDK 1.5 changes I've done (including
> generics) are backward compatible - clirr thinks so except when I
> changed the LineIterator next() method to return a String rather than
> Object - but I think thats an error on clirrs part.
Since it looks like we are keeping [] parameters instead of replacing them with List<T> that might work out.
I say we complete the conversion to generics and see where that leaves us. I have some generics pending commits that I'll push out in that dept.
Gary
>
> Niall
>
> > So, in short, you need all of io v2 in io2 and all of io v1 in io. This allows for an
> application to depend on both and allows io2 to use all of Java 5 internally and in
> presenting its external API.
>
> > Gary
> >
> >
> > >
> > > BR,
> > >
> > > Jukka Zitting
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
On Feb 8, 2008 4:32 PM, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> > Sent: Friday, February 08, 2008 8:24 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
> >
> > Hi,
> >
> > On Feb 8, 2008 5:24 PM, James Carman <ja...@carmanconsulting.com> wrote:
> > > On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > > > be changed extensively to match "Java 5 style", then I'd name the
> > > > modified version o.a.c.io.SomeClass2 (or something better if
> > > > possible).
> > >
> > > I don't know about that. Then, we could potentially have classes like
> > > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> > > wouldn't be as easy to upgrade to a new version. If it were done the
> > > other way, folks could just do a find/replace on the package name in
> > > their code and be done.
> >
> > Why I should need the find/replace in the first place? A find/replace
> > won't help with any fundamental API incompatibilities that would
> > trigger the creation of SomeClass2.
> >
> > You'd only need to upgrade to SomeClass2 if you actually need the new
> > functionality, otherwise you could just keep using the old API when
> > upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> > need to update their code when upgrading even if no part of the API
> > they touch has changed.
>
> I do not think this last paragraph is correct. The io2 package is not only free to introduce generics in the API, it is also free to use Java 5 features in its internal implementation. This gives us the freedom to use all Java 5 features in io2 while keeping the API or most of it the same. So if you are using io2, you must use Java 5. If you have a 3rd party library that depends on io (v1.x), then you need the io package around too.
But why does changing to use generics make it incompatible - since
java erases generics?
So far I believe all the JDK 1.5 changes I've done (including
generics) are backward compatible - clirr thinks so except when I
changed the LineIterator next() method to return a String rather than
Object - but I think thats an error on clirrs part.
Niall
> So, in short, you need all of io v2 in io2 and all of io v1 in io. This allows for an application to depend on both and allows io2 to use all of Java 5 internally and in presenting its external API.
> Gary
>
>
> >
> > BR,
> >
> > Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Friday, February 08, 2008 8:24 AM
> To: Jakarta Commons Developers List
> Subject: Re: [io] 2.0 Moving to minimum of JDK 1.5
>
> Hi,
>
> On Feb 8, 2008 5:24 PM, James Carman <ja...@carmanconsulting.com> wrote:
> > On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > > be changed extensively to match "Java 5 style", then I'd name the
> > > modified version o.a.c.io.SomeClass2 (or something better if
> > > possible).
> >
> > I don't know about that. Then, we could potentially have classes like
> > SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> > wouldn't be as easy to upgrade to a new version. If it were done the
> > other way, folks could just do a find/replace on the package name in
> > their code and be done.
>
> Why I should need the find/replace in the first place? A find/replace
> won't help with any fundamental API incompatibilities that would
> trigger the creation of SomeClass2.
>
> You'd only need to upgrade to SomeClass2 if you actually need the new
> functionality, otherwise you could just keep using the old API when
> upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
> need to update their code when upgrading even if no part of the API
> they touch has changed.
I do not think this last paragraph is correct. The io2 package is not only free to introduce generics in the API, it is also free to use Java 5 features in its internal implementation. This gives us the freedom to use all Java 5 features in io2 while keeping the API or most of it the same. So if you are using io2, you must use Java 5. If you have a 3rd party library that depends on io (v1.x), then you need the io package around too.
So, in short, you need all of io v2 in io2 and all of io v1 in io. This allows for an application to depend on both and allows io2 to use all of Java 5 internally and in presenting its external API.
Gary
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 8, 2008 5:24 PM, James Carman <ja...@carmanconsulting.com> wrote:
> On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> > If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> > be changed extensively to match "Java 5 style", then I'd name the
> > modified version o.a.c.io.SomeClass2 (or something better if
> > possible).
>
> I don't know about that. Then, we could potentially have classes like
> SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
> wouldn't be as easy to upgrade to a new version. If it were done the
> other way, folks could just do a find/replace on the package name in
> their code and be done.
Why I should need the find/replace in the first place? A find/replace
won't help with any fundamental API incompatibilities that would
trigger the creation of SomeClass2.
You'd only need to upgrade to SomeClass2 if you actually need the new
functionality, otherwise you could just keep using the old API when
upgrading from 1.x to 2.x. With the o.a.c.io2 proposal everybody would
need to update their code when upgrading even if no part of the API
they touch has changed.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by James Carman <ja...@carmanconsulting.com>.
On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Feb 8, 2008 3:49 PM, James Carman <ja...@carmanconsulting.com> wrote:
> > So, you are suggesting having part of a release in the o.a.c.io
> > package and the other part in the o.a.c.io2?
>
> No. I'd keep everything in o.a.c.io.
>
> If there's a class or interface, say o.a.c.io.SomeClass, that needs to
> be changed extensively to match "Java 5 style", then I'd name the
> modified version o.a.c.io.SomeClass2 (or something better if
> possible).
>
I don't know about that. Then, we could potentially have classes like
SomeClass, SomeClass2, SomeClass3, etc. running around. Also, it
wouldn't be as easy to upgrade to a new version. If it were done the
other way, folks could just do a find/replace on the package name in
their code and be done.
On the other hand, it does allow you to introduce new incompatible
logic without requiring a new major release. Hopefully folks wouldn't
abuse that.
> I assume such cases to be the exception rather than the rule, so I
> don't see the point in renaming the entire package.
>
> Java 5 is just an enabler of new features (generics, etc.), it doesn't
> magically make existing APIs obsolete. Sure, you probably want to
> adjust collection types, but that's just like any other API change
> request.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 8, 2008 3:49 PM, James Carman <ja...@carmanconsulting.com> wrote:
> So, you are suggesting having part of a release in the o.a.c.io
> package and the other part in the o.a.c.io2?
No. I'd keep everything in o.a.c.io.
If there's a class or interface, say o.a.c.io.SomeClass, that needs to
be changed extensively to match "Java 5 style", then I'd name the
modified version o.a.c.io.SomeClass2 (or something better if
possible).
I assume such cases to be the exception rather than the rule, so I
don't see the point in renaming the entire package.
Java 5 is just an enabler of new features (generics, etc.), it doesn't
magically make existing APIs obsolete. Sure, you probably want to
adjust collection types, but that's just like any other API change
request.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by James Carman <ja...@carmanconsulting.com>.
So, you are suggesting having part of a release in the o.a.c.io
package and the other part in the o.a.c.io2? It seems rather
inconsistent, but I guess it would work. Isn't that going to get
ugly with 3.x and 4.x releases adding to the mix?
On 2/8/08, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Feb 6, 2008 1:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> > So the changes are pretty minimal for IO - question is are these
> > incompatible changes with generics being erased? If not then perhaps
> > we can do this without breaking anything.
>
> +1 If there are cases where we can't avoid breaking backwards
> compatibility, then let's use the name2 pattern on individual classes
> or interfaces instead of the entire o.a.c.io package. There are large
> parts of Commons IO that don't need to change when upgrading to Java 5
> and I don't see why a client that only uses those parts should be
> affected in any way by the upgrade.
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> 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: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 6, 2008 1:51 PM, Niall Pemberton <ni...@gmail.com> wrote:
> So the changes are pretty minimal for IO - question is are these
> incompatible changes with generics being erased? If not then perhaps
> we can do this without breaking anything.
+1 If there are cases where we can't avoid breaking backwards
compatibility, then let's use the name2 pattern on individual classes
or interfaces instead of the entire o.a.c.io package. There are large
parts of Commons IO that don't need to change when upgrading to Java 5
and I don't see why a client that only uses those parts should be
affected in any way by the upgrade.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Niall Pemberton <ni...@gmail.com>.
I don't know if it helps this debate, but when I went thru JDK 1.5
changes for IO I came up with the following (which are mostly
generifying methods):
ConditionalFileFilter (interface)
- public List<IOFileFilter> getFileFilters()
- public void setFileFilters(final List<IOFileFilter> fileFilters) {
AndFileFilter
- public AndFileFilter(final List<IOFileFilter> fileFilters)
- public List<IOFileFilter> getFileFilters()
- public void setFileFilters(final List<IOFileFilter> fileFilters) {
OrFileFilter
- public OrFileFilter(final List<IOFileFilter> fileFilters)
- public List<IOFileFilter> getFileFilters()
- public void setFileFilters(final List<IOFileFilter> fileFilters) {
NameFileFilter
- public NameFileFilter(List<String> names)
- public NameFileFilter(List<String> names, IOCase caseSensitivity)
PrefixFileFilter
- public PrefixFileFilter(List<String> prefixes)
- public PrefixFileFilter(List<String> names, IOCase caseSensitivity)
SuffixFileFilter
- public SuffixFileFilter(List<String> prefixes)
- public SuffixFileFilter(List<String> names, IOCase caseSensitivity)
WildcardFileFilter
- public WildcardFileFilter(List<String> prefixes)
- public WildcardFileFilter(List<String> names, IOCase caseSensitivity)
FileUtils
- public static File[] convertFileCollectionToFileArray(Collection<File> files)
- public static Collection<File> listFiles(
- public static void writeStringToFile(File file, CharSequence data,
String encoding)
[note CharSequence version replaces String falvour]
ClassLoaderObjectInputStream
- protected Class<?> resolveClass(ObjectStreamClass objectStreamClass)
ProxyReader
- public int read(CharBuffer target) [new method added]
IOUtils
- public static List<String> readLines(Reader input)
- public static InputStream toInputStream(CharSequence input)
- public static InputStream toInputStream(CharSequence input, String encoding)
- public static void write(CharSequence data, Writer output)
- public static void write(CharSequence data, OutputStream output)
- public static void write(CharSequence data, OutputStream output,
String encoding)
[Note CharSequence replaces String and/or StringBuffer flavours]
LineIterator
- public class LineIterator implements Iterator<String>
- public String next() [was returning Object]
NullWriter, ProxyWriter
- add public Writer append(char c)
- add public Writer append(CharSequence csq, int start, int end)
- add public Writer append(CharSequence csq)
So the changes are pretty minimal for IO - question is are these
incompatible changes with generics being erased? If not then perhaps
we can do this without breaking anything.
Niall
On Feb 5, 2008 4:47 AM, Niall Pemberton <ni...@gmail.com> wrote:
> We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> theres also an JIRA report here:
> http://issues.apache.org/jira/browse/IO-140
>
> From memory the preference was to move to a new package name - how
> about "org.apache.commons.io2"?
>
> Are there any objections to me creating an IO 1.4 branch from the
> current trunk and then starting work on IO 2.0 in the trunk.
>
> Initial plans would be:
>
> - rename to the new package
> - remove deprecated items
> - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> and new Appendable for Writers etc).
>
> Niall
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Torsten Curdt <tc...@apache.org>.
On 05.02.2008, at 06:44, Henri Yandell wrote:
> On Feb 4, 2008 8:47 PM, Niall Pemberton <ni...@gmail.com>
> wrote:
>> We've discussed moving to a minimum of JDK 1.5 for IO 2.0
>> previously -
>> theres also an JIRA report here:
>> http://issues.apache.org/jira/browse/IO-140
>>
>> From memory the preference was to move to a new package name - how
>> about "org.apache.commons.io2"?
>
> For Collections it makes sense as there's a big API change planned.
>
> For the others, I think they should charge in and see what kind of API
> changes are required. If we're talking small ones, then I'd prefer not
> to. I continue to not think that the next major version of a jar has
> to kill itself over backwards compatibility (ie: what's the point of a
> major version).
But that is exactly the point of a major upgrade - it might have
incompatible changes.
Or what am I not getting here in your argumentation? :)
>> Are there any objections to me creating an IO 1.4 branch from the
>> current trunk and then starting work on IO 2.0 in the trunk.
>
> Any need to make the branch?
>
> ie) Wait until you need it; as long as you have a tag of the latest
> release you can always branch from that.
>
>> Initial plans would be:
>>
>> - rename to the new package
>> - remove deprecated items
>> - Making appropriate JDK 1.5 changes (generics, using StringBuilder
>> and new Appendable for Writers etc).
>
> I'd move the new package one to 3rd rather than 1st.
I think it would much more consistent to do it across the board. If a
users upgrades from 1.x to 2.x it should not be expected too much to
run at least an "organize imports". And we would have less trouble
worrying about backwards incompatibilities - clean slate.
At least that's my take on this.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [io] 2.0 Moving to minimum of JDK 1.5
Posted by Henri Yandell <fl...@gmail.com>.
On Feb 4, 2008 8:47 PM, Niall Pemberton <ni...@gmail.com> wrote:
> We've discussed moving to a minimum of JDK 1.5 for IO 2.0 previously -
> theres also an JIRA report here:
> http://issues.apache.org/jira/browse/IO-140
>
> From memory the preference was to move to a new package name - how
> about "org.apache.commons.io2"?
For Collections it makes sense as there's a big API change planned.
For the others, I think they should charge in and see what kind of API
changes are required. If we're talking small ones, then I'd prefer not
to. I continue to not think that the next major version of a jar has
to kill itself over backwards compatibility (ie: what's the point of a
major version).
> Are there any objections to me creating an IO 1.4 branch from the
> current trunk and then starting work on IO 2.0 in the trunk.
Any need to make the branch?
ie) Wait until you need it; as long as you have a tag of the latest
release you can always branch from that.
> Initial plans would be:
>
> - rename to the new package
> - remove deprecated items
> - Making appropriate JDK 1.5 changes (generics, using StringBuilder
> and new Appendable for Writers etc).
I'd move the new package one to 3rd rather than 1st.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org