|
osdir.com mailing list archive |
|
Subject: Re: ScheduledThreadPoolExecutor - msg#00004List: windows.dotnet.spring.develPascal, Not sure I follow the ThreadPool reference. Can you expand on it a little? MSN: griffincaprio@xxxxxxxxxxx - Griffin On Feb 18, 2008, at 3:46 PM, Pascal Vantrepote wrote: > For Collections it's not a big deal. You do not change Collection > every release (Collections are quit steady). > It might be an issue for other type of class (ThreadPool), but I > don't see why. > > By the way, are you guys using MSN? > > Pascal. > > > On 18-Feb-08, at 4:36 PM, Griffin Caprio wrote: > >> Ah, i see. I guess that makes sense from a compatibility >> standpoint, but it creates a HUGE maintenance nightmare because >> then we're basically creating one class that conforms to two >> interface contracts. Off the top of my head, I would bet that >> means we'll have to make concessions when implementing features >> inside classes that implement the IQueue<T> interface. >> >> Though, I could just be overestimating the cost of supporting two >> interfaces. >> >> - Griffin >> On Feb 18, 2008, at 3:26 PM, Pascal Vantrepote wrote: >> >>> Yes, that what I mean. >>> Sorry I was not clear. >>> English is not my first language. Sorry again. >>> >>> Pascal. >>> >>> On 18-Feb-08, at 4:24 PM, Griffin Caprio wrote: >>> >>>> Pascal, >>>> >>>> I'm not sure I understand. If a user had written something with >>>> a IQueue paramter, why would that change with the introduction of >>>> IQueue<T> unless they wanted to take advantage of the generic >>>> interface. Then, they would just change the parameter to >>>> IQueue<T> and move on. Do you mean that it would be easier for >>>> the user to pass in an instance of a IQueue<T> class, since it >>>> inherits from IQueue? >>>> >>>> - Griffin >>>> >>>> On Feb 18, 2008, at 3:21 PM, Pascal Vantrepote wrote: >>>> >>>>> That was the idea (having Spring.Threading.Generic...) and sorry >>>>> I did not develop the idea in my previous mail. >>>>> >>>>> Now, having Generic inherit from non generic is to keep >>>>> compatibility with already written non generic class. >>>>> Like Microsoft is doing with IList<T> : IList. >>>>> By this way if a user already wrote a class using IQueue has a >>>>> parameter, he doesn't have to rewrite his class. >>>>> Is it ok for you? >>>>> >>>>> Thanks. >>>>> Pascal >>>>> >>>>> On 18-Feb-08, at 1:46 PM, Mark Pollack wrote: >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> I certainly agree that it would make more sense if IQueue<T> is >>>>>> defined in >>>>>> Spring.Core and that is the end goal. Putting such classes in >>>>>> the namespace >>>>>> Spring.Collections.Generic would seem like a natural location >>>>>> considering we >>>>>> already have a non generic namespace and it would mirror >>>>>> System.Collections.Generic. We wouldn't remove what is >>>>>> currently in >>>>>> Spring.Collections even if we support only >= .NET 2.0. >>>>>> >>>>>> In any case, since we would like to have much more than >>>>>> IQueue<T> put under >>>>>> Spring.Collections.Generic, why don't you create that namespace >>>>>> in the >>>>>> Spring.Threading project? This way once Spring.Threading is >>>>>> properly >>>>>> 'incubated' under this umbrella project of Spring Extensions we >>>>>> can easily >>>>>> move it into the main code base. If it is an urgent matter of >>>>>> adding a few >>>>>> classes into Spring.Core that would make development for you >>>>>> much easier >>>>>> right now, we can consider doing that, but I think it would be >>>>>> a good idea >>>>>> for all of the classes in Spring.Threading to have the same >>>>>> 'bake time'. >>>>>> >>>>>> Sound ok? >>>>>> >>>>>> BTW: Isn't inheriting IQueue<T> from IQueue defeating the >>>>>> purpose of having >>>>>> generics? I would have thought a generic version would imply a >>>>>> cut-n-paste >>>>>> reuse of existing IQueue interfaces and implementing classes? >>>>>> >>>>>> Cheers, >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>> Sent: Monday, February 18, 2008 1:04 PM >>>>>> To: Mark Pollack >>>>>> Cc: 'Griffin Caprio' >>>>>> Subject: Re: ScheduledThreadPoolExecutor >>>>>> >>>>>> Just to be able to have Generic for Collection in Spring.Core. >>>>>> It will be easier if IQueue (defined in Spring.Core) was Generic >>>>>> (IBlockingQueue inherit from IQueue). >>>>>> >>>>>> For now I can create a Generic IQueue (in Threading) inherited >>>>>> from >>>>>> the non Generic IQueue. >>>>>> The day, a decision is made to drop support of .NET 1.1, the >>>>>> definition can move from Threading to Core. >>>>>> >>>>>> But for me it make more sense if IQueue<T> is define in >>>>>> Spring.Core. >>>>>> >>>>>> Let me know >>>>>> Pascal. >>>>>> >>>>>> >>>>>> On 18-Feb-08, at 12:46 PM, Mark Pollack wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Great to see this progress! I'm working on getting the svn >>>>>>> stuff >>>>>>> setup. >>>>>>> >>>>>>> Adding generics support in Spring.Core hasn't been fully >>>>>>> scoped out >>>>>>> yet. At >>>>>>> the moment there is some debate if we should hold off doing >>>>>>> that until >>>>>>> Spring.NET 2.0 in which case we would also drop support >>>>>>> for .NET 1.0 >>>>>>> and >>>>>>> 1.1. In any case, I don't see Spring.Threading functionality >>>>>>> places >>>>>>> this >>>>>>> requirement on Spring.Core. Can you explain? >>>>>>> >>>>>>> Cheers, >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>>> Sent: Monday, February 18, 2008 12:09 PM >>>>>>> To: Griffin Caprio; Mark Pollack >>>>>>> Subject: ScheduledThreadPoolExecutor >>>>>>> >>>>>>> Hey Guys, >>>>>>> >>>>>>> I have good news. The port of ScheduledThreadPoolExecutor is >>>>>>> done. >>>>>>> Do you want me to send the files (I had to modify FutureTask and >>>>>>> IBlockingQueue) or wait until the repository is up? >>>>>>> >>>>>>> I think it was the last not implemented class. Griffin can >>>>>>> confirm >>>>>>> that, please? >>>>>>> So next step is to add Generic support. >>>>> >>>> >>> >> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ Thread at a glance:
Previous Message by Date: click to view message previewSpring.NET-Daily Build Fixed: Build 382CruiseControl.NET Build Results for project Spring.NET-Daily (web page)BUILD SUCCESSFULProject:Spring.NET-DailyDate of build:2/12/2008 2:53:58 AMRunning time:< /td>00:44:50Build condition: Forced Build Warnings: (8) Read-only property "cvs.executable" cannot be overwritten.Read-only property "build.file" cannot be overwritten.ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005BUILD FAILEDC:\projects\daily\Spring.Net\doc\build.xml:105: C:\projects\daily\Spring.Net\doc\reference\lib not found.Total time: 5 seconds Modifications since last build (0) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Springnet-developer mailing list Springnet-developer@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springnet-developer Next Message by Date: click to view message previewRe: ScheduledThreadPoolExecutorHi, I'd rather have a clean 'generic' only interface contract for IQueue<T> and therefore not inherit from IQueue and considering that IQueue isn't widely used, we can afford to make that change unlike the case with IList<T>/IList in the BCL. Cheers, Mark -----Original Message----- From: springnet-developer-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:springnet-developer-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Griffin Caprio Sent: Monday, February 18, 2008 5:11 PM To: springnet-developer@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springnet-developer] ScheduledThreadPoolExecutor <Moving this to the Spring.NET Dev group> Pascal, Not sure I follow the ThreadPool reference. Can you expand on it a little? MSN: griffincaprio@xxxxxxxxxxx - Griffin On Feb 18, 2008, at 3:46 PM, Pascal Vantrepote wrote: > For Collections it's not a big deal. You do not change Collection > every release (Collections are quit steady). > It might be an issue for other type of class (ThreadPool), but I > don't see why. > > By the way, are you guys using MSN? > > Pascal. > > > On 18-Feb-08, at 4:36 PM, Griffin Caprio wrote: > >> Ah, i see. I guess that makes sense from a compatibility >> standpoint, but it creates a HUGE maintenance nightmare because >> then we're basically creating one class that conforms to two >> interface contracts. Off the top of my head, I would bet that >> means we'll have to make concessions when implementing features >> inside classes that implement the IQueue<T> interface. >> >> Though, I could just be overestimating the cost of supporting two >> interfaces. >> >> - Griffin >> On Feb 18, 2008, at 3:26 PM, Pascal Vantrepote wrote: >> >>> Yes, that what I mean. >>> Sorry I was not clear. >>> English is not my first language. Sorry again. >>> >>> Pascal. >>> >>> On 18-Feb-08, at 4:24 PM, Griffin Caprio wrote: >>> >>>> Pascal, >>>> >>>> I'm not sure I understand. If a user had written something with >>>> a IQueue paramter, why would that change with the introduction of >>>> IQueue<T> unless they wanted to take advantage of the generic >>>> interface. Then, they would just change the parameter to >>>> IQueue<T> and move on. Do you mean that it would be easier for >>>> the user to pass in an instance of a IQueue<T> class, since it >>>> inherits from IQueue? >>>> >>>> - Griffin >>>> >>>> On Feb 18, 2008, at 3:21 PM, Pascal Vantrepote wrote: >>>> >>>>> That was the idea (having Spring.Threading.Generic...) and sorry >>>>> I did not develop the idea in my previous mail. >>>>> >>>>> Now, having Generic inherit from non generic is to keep >>>>> compatibility with already written non generic class. >>>>> Like Microsoft is doing with IList<T> : IList. >>>>> By this way if a user already wrote a class using IQueue has a >>>>> parameter, he doesn't have to rewrite his class. >>>>> Is it ok for you? >>>>> >>>>> Thanks. >>>>> Pascal >>>>> >>>>> On 18-Feb-08, at 1:46 PM, Mark Pollack wrote: >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> I certainly agree that it would make more sense if IQueue<T> is >>>>>> defined in >>>>>> Spring.Core and that is the end goal. Putting such classes in >>>>>> the namespace >>>>>> Spring.Collections.Generic would seem like a natural location >>>>>> considering we >>>>>> already have a non generic namespace and it would mirror >>>>>> System.Collections.Generic. We wouldn't remove what is >>>>>> currently in >>>>>> Spring.Collections even if we support only >= .NET 2.0. >>>>>> >>>>>> In any case, since we would like to have much more than >>>>>> IQueue<T> put under >>>>>> Spring.Collections.Generic, why don't you create that namespace >>>>>> in the >>>>>> Spring.Threading project? This way once Spring.Threading is >>>>>> properly >>>>>> 'incubated' under this umbrella project of Spring Extensions we >>>>>> can easily >>>>>> move it into the main code base. If it is an urgent matter of >>>>>> adding a few >>>>>> classes into Spring.Core that would make development for you >>>>>> much easier >>>>>> right now, we can consider doing that, but I think it would be >>>>>> a good idea >>>>>> for all of the classes in Spring.Threading to have the same >>>>>> 'bake time'. >>>>>> >>>>>> Sound ok? >>>>>> >>>>>> BTW: Isn't inheriting IQueue<T> from IQueue defeating the >>>>>> purpose of having >>>>>> generics? I would have thought a generic version would imply a >>>>>> cut-n-paste >>>>>> reuse of existing IQueue interfaces and implementing classes? >>>>>> >>>>>> Cheers, >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>> Sent: Monday, February 18, 2008 1:04 PM >>>>>> To: Mark Pollack >>>>>> Cc: 'Griffin Caprio' >>>>>> Subject: Re: ScheduledThreadPoolExecutor >>>>>> >>>>>> Just to be able to have Generic for Collection in Spring.Core. >>>>>> It will be easier if IQueue (defined in Spring.Core) was Generic >>>>>> (IBlockingQueue inherit from IQueue). >>>>>> >>>>>> For now I can create a Generic IQueue (in Threading) inherited >>>>>> from >>>>>> the non Generic IQueue. >>>>>> The day, a decision is made to drop support of .NET 1.1, the >>>>>> definition can move from Threading to Core. >>>>>> >>>>>> But for me it make more sense if IQueue<T> is define in >>>>>> Spring.Core. >>>>>> >>>>>> Let me know >>>>>> Pascal. >>>>>> >>>>>> >>>>>> On 18-Feb-08, at 12:46 PM, Mark Pollack wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Great to see this progress! I'm working on getting the svn >>>>>>> stuff >>>>>>> setup. >>>>>>> >>>>>>> Adding generics support in Spring.Core hasn't been fully >>>>>>> scoped out >>>>>>> yet. At >>>>>>> the moment there is some debate if we should hold off doing >>>>>>> that until >>>>>>> Spring.NET 2.0 in which case we would also drop support >>>>>>> for .NET 1.0 >>>>>>> and >>>>>>> 1.1. In any case, I don't see Spring.Threading functionality >>>>>>> places >>>>>>> this >>>>>>> requirement on Spring.Core. Can you explain? >>>>>>> >>>>>>> Cheers, >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>>> Sent: Monday, February 18, 2008 12:09 PM >>>>>>> To: Griffin Caprio; Mark Pollack >>>>>>> Subject: ScheduledThreadPoolExecutor >>>>>>> >>>>>>> Hey Guys, >>>>>>> >>>>>>> I have good news. The port of ScheduledThreadPoolExecutor is >>>>>>> done. >>>>>>> Do you want me to send the files (I had to modify FutureTask and >>>>>>> IBlockingQueue) or wait until the repository is up? >>>>>>> >>>>>>> I think it was the last not implemented class. Griffin can >>>>>>> confirm >>>>>>> that, please? >>>>>>> So next step is to add Generic support. >>>>> >>>> >>> >> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Springnet-developer@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springnet-developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ Previous Message by Thread: click to view message previewSpring.NET-Daily Build Fixed: Build 382CruiseControl.NET Build Results for project Spring.NET-Daily (web page)BUILD SUCCESSFULProject:Spring.NET-DailyDate of build:2/12/2008 2:53:58 AMRunning time:< /td>00:44:50Build condition: Forced Build Warnings: (8) Read-only property "cvs.executable" cannot be overwritten.Read-only property "build.file" cannot be overwritten.ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005ANTLR Parser Generator Version 2.7.6 (2005-12-22) 1989-2005BUILD FAILEDC:\projects\daily\Spring.Net\doc\build.xml:105: C:\projects\daily\Spring.Net\doc\reference\lib not found.Total time: 5 seconds Modifications since last build (0) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ Springnet-developer mailing list Springnet-developer@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springnet-developer Next Message by Thread: click to view message previewRe: ScheduledThreadPoolExecutorHi, I'd rather have a clean 'generic' only interface contract for IQueue<T> and therefore not inherit from IQueue and considering that IQueue isn't widely used, we can afford to make that change unlike the case with IList<T>/IList in the BCL. Cheers, Mark -----Original Message----- From: springnet-developer-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:springnet-developer-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Griffin Caprio Sent: Monday, February 18, 2008 5:11 PM To: springnet-developer@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Springnet-developer] ScheduledThreadPoolExecutor <Moving this to the Spring.NET Dev group> Pascal, Not sure I follow the ThreadPool reference. Can you expand on it a little? MSN: griffincaprio@xxxxxxxxxxx - Griffin On Feb 18, 2008, at 3:46 PM, Pascal Vantrepote wrote: > For Collections it's not a big deal. You do not change Collection > every release (Collections are quit steady). > It might be an issue for other type of class (ThreadPool), but I > don't see why. > > By the way, are you guys using MSN? > > Pascal. > > > On 18-Feb-08, at 4:36 PM, Griffin Caprio wrote: > >> Ah, i see. I guess that makes sense from a compatibility >> standpoint, but it creates a HUGE maintenance nightmare because >> then we're basically creating one class that conforms to two >> interface contracts. Off the top of my head, I would bet that >> means we'll have to make concessions when implementing features >> inside classes that implement the IQueue<T> interface. >> >> Though, I could just be overestimating the cost of supporting two >> interfaces. >> >> - Griffin >> On Feb 18, 2008, at 3:26 PM, Pascal Vantrepote wrote: >> >>> Yes, that what I mean. >>> Sorry I was not clear. >>> English is not my first language. Sorry again. >>> >>> Pascal. >>> >>> On 18-Feb-08, at 4:24 PM, Griffin Caprio wrote: >>> >>>> Pascal, >>>> >>>> I'm not sure I understand. If a user had written something with >>>> a IQueue paramter, why would that change with the introduction of >>>> IQueue<T> unless they wanted to take advantage of the generic >>>> interface. Then, they would just change the parameter to >>>> IQueue<T> and move on. Do you mean that it would be easier for >>>> the user to pass in an instance of a IQueue<T> class, since it >>>> inherits from IQueue? >>>> >>>> - Griffin >>>> >>>> On Feb 18, 2008, at 3:21 PM, Pascal Vantrepote wrote: >>>> >>>>> That was the idea (having Spring.Threading.Generic...) and sorry >>>>> I did not develop the idea in my previous mail. >>>>> >>>>> Now, having Generic inherit from non generic is to keep >>>>> compatibility with already written non generic class. >>>>> Like Microsoft is doing with IList<T> : IList. >>>>> By this way if a user already wrote a class using IQueue has a >>>>> parameter, he doesn't have to rewrite his class. >>>>> Is it ok for you? >>>>> >>>>> Thanks. >>>>> Pascal >>>>> >>>>> On 18-Feb-08, at 1:46 PM, Mark Pollack wrote: >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> I certainly agree that it would make more sense if IQueue<T> is >>>>>> defined in >>>>>> Spring.Core and that is the end goal. Putting such classes in >>>>>> the namespace >>>>>> Spring.Collections.Generic would seem like a natural location >>>>>> considering we >>>>>> already have a non generic namespace and it would mirror >>>>>> System.Collections.Generic. We wouldn't remove what is >>>>>> currently in >>>>>> Spring.Collections even if we support only >= .NET 2.0. >>>>>> >>>>>> In any case, since we would like to have much more than >>>>>> IQueue<T> put under >>>>>> Spring.Collections.Generic, why don't you create that namespace >>>>>> in the >>>>>> Spring.Threading project? This way once Spring.Threading is >>>>>> properly >>>>>> 'incubated' under this umbrella project of Spring Extensions we >>>>>> can easily >>>>>> move it into the main code base. If it is an urgent matter of >>>>>> adding a few >>>>>> classes into Spring.Core that would make development for you >>>>>> much easier >>>>>> right now, we can consider doing that, but I think it would be >>>>>> a good idea >>>>>> for all of the classes in Spring.Threading to have the same >>>>>> 'bake time'. >>>>>> >>>>>> Sound ok? >>>>>> >>>>>> BTW: Isn't inheriting IQueue<T> from IQueue defeating the >>>>>> purpose of having >>>>>> generics? I would have thought a generic version would imply a >>>>>> cut-n-paste >>>>>> reuse of existing IQueue interfaces and implementing classes? >>>>>> >>>>>> Cheers, >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>> Sent: Monday, February 18, 2008 1:04 PM >>>>>> To: Mark Pollack >>>>>> Cc: 'Griffin Caprio' >>>>>> Subject: Re: ScheduledThreadPoolExecutor >>>>>> >>>>>> Just to be able to have Generic for Collection in Spring.Core. >>>>>> It will be easier if IQueue (defined in Spring.Core) was Generic >>>>>> (IBlockingQueue inherit from IQueue). >>>>>> >>>>>> For now I can create a Generic IQueue (in Threading) inherited >>>>>> from >>>>>> the non Generic IQueue. >>>>>> The day, a decision is made to drop support of .NET 1.1, the >>>>>> definition can move from Threading to Core. >>>>>> >>>>>> But for me it make more sense if IQueue<T> is define in >>>>>> Spring.Core. >>>>>> >>>>>> Let me know >>>>>> Pascal. >>>>>> >>>>>> >>>>>> On 18-Feb-08, at 12:46 PM, Mark Pollack wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Great to see this progress! I'm working on getting the svn >>>>>>> stuff >>>>>>> setup. >>>>>>> >>>>>>> Adding generics support in Spring.Core hasn't been fully >>>>>>> scoped out >>>>>>> yet. At >>>>>>> the moment there is some debate if we should hold off doing >>>>>>> that until >>>>>>> Spring.NET 2.0 in which case we would also drop support >>>>>>> for .NET 1.0 >>>>>>> and >>>>>>> 1.1. In any case, I don't see Spring.Threading functionality >>>>>>> places >>>>>>> this >>>>>>> requirement on Spring.Core. Can you explain? >>>>>>> >>>>>>> Cheers, >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Pascal Vantrepote [mailto:pvantrepote@xxxxxxxxx] >>>>>>> Sent: Monday, February 18, 2008 12:09 PM >>>>>>> To: Griffin Caprio; Mark Pollack >>>>>>> Subject: ScheduledThreadPoolExecutor >>>>>>> >>>>>>> Hey Guys, >>>>>>> >>>>>>> I have good news. The port of ScheduledThreadPoolExecutor is >>>>>>> done. >>>>>>> Do you want me to send the files (I had to modify FutureTask and >>>>>>> IBlockingQueue) or wait until the repository is up? >>>>>>> >>>>>>> I think it was the last not implemented class. Griffin can >>>>>>> confirm >>>>>>> that, please? >>>>>>> So next step is to add Generic support. >>>>> >>>> >>> >> > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Springnet-developer mailing list Springnet-developer@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/springnet-developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ Loading Comments...
|
|
