My thinking is just a separate ticket for each one. This makes the work easier to manage and gives a better sense about how much work is left as well as makes it easier to prioritize independent issues. We could link all the sub-issues to a single task / feature / whatever (that is, if JIRA has that capability).
-r On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon < mhern...@wickedsoftware.net> wrote: > I think whatever makes sense to do. > > possibly create one jira for now with a running list that can be modified > and possibly as people pull from that list, cross things off or create a > separate ticket that links back to to the main one. > > > > > On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <codekai...@gmail.com> wrote: > > > @Michael - > > > > Should that list be in JIRA? It would be easier to manage, I think... > > > > If yes, I'll happily do it. > > > > -r > > > > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon < > > mhern...@wickedsoftware.net > > > wrote: > > > > > * need to document what the build script does. whut grammerz? > > > > > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon < > > > mhern...@wickedsoftware.net> wrote: > > > > > > > @Rory, @All, > > > > > > > > The only tickets I currently have for those is LUCENE-419, LUCENE-418 > > > > > > > > 418, I should be able to push into the 2.9.4g branch tonight. 419 > is > > a > > > > long term goal and not as important as getting the tests fixed, of > have > > > the > > > > tests broken down into what is actually a unit test, functional test, > > > perf > > > > or long running test. I can get into more why it needs to be done. > > > > > > > > I'll also need to make document the what build script currently does > on > > > the > > > > wiki & and make a few notes about testing, like using the > RAMDirectory, > > > > etc. > > > > > > > > Things that need to get done or even be discussed. > > > > * There needs to be a running list of things to do/not to do with > > > testing. > > > > I don't know if this goes in a jira or do we keep a running list on > the > > > wiki > > > > or site for people to pick up and help with. > > > > * Tests need to run on mono and not Fail (there is a good deal of > > > failing > > > > tests on mono, mostly due to the temp directory have the C:\ in the > > > path). > > > > * Assert.Throw<ExceptionType>() needs to be used instead of > Try/Catch > > > > Assert.Fail. ** > > > > * File & Path combines to the temp directory need helper methods, > > > > * e,g, having this in a hundred places is bad new > > > > > > > > > > System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir", > > > > ""), "testIndex")); > > > > * We should still be testing deprecated methods, but we need to use > > > #pragma > > > > warning disable/enable 0618 for testing those. otherwise compiler > > > warnings > > > > are too numerous to be anywhere near helpful. > > > > * We should only be using deprecated methods in places where they > are > > > > being explicitly tested, other tests that need that functionality in > > > order > > > > to validate those tests should be re factored to use methods that are > > not > > > > deprecated. > > > > * Identify code that could be abstracted into test utility classes. > > > > * Infrastructure Validation tests need to be made, anything that > seems > > > > like infrastructure. e.g. does the temp directory exist, does the > > > folders > > > > that the tests use inside the temp directory exist, can we read/write > > to > > > > those folders. (if a ton of tests fail due to the file system, we > > should > > > be > > > > able to point out that it was due to permissions or missing folders, > > > files, > > > > etc). > > > > * Identify what classes need an interface, abstract class or > inherited > > > in > > > > order to create testing mocks. (once those classes are created, they > > > should > > > > be documented in the wiki). > > > > > > > > > > > > > > > > ** Asset.Throws needs to replace stuff like the following. We should > > also > > > > be checking the messages for exceptions and make sure they make sense > > and > > > > can help users fix isses if the exceptions are aimed at the library > > > users. > > > > try > > > > { > > > > d = DateTools.StringToDate("97"); // no date > > > > Assert.Fail(); > > > > } > > > > catch (System.FormatException e) > > > > { > > > > /* expected exception */ > > > > } > > > > > > > > On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire <codekai...@gmail.com > > > >wrote: > > > > > > > >> So, veering towards action - are there concrete tasks written up > > > anywhere > > > >> for the unit tests? If a poor schlep like me wanted to dig in and > > start > > > to > > > >> improve them, where would I get the understanding of what is good > and > > > what > > > >> needs help? > > > >> > > > >> -r > > > >> > > > >> On Thu, Jun 30, 2011 at 3:29 PM, Digy <digyd...@gmail.com> wrote: > > > >> > > > >> > I can not say I like this approach, but till we find an automated > > > >> way(with > > > >> > good results), it seems to be the only way we can use. > > > >> > > > > >> > DIGY > > > >> > > > > >> > -----Original Message----- > > > >> > From: Troy Howard [mailto:thowar...@gmail.com] > > > >> > Sent: Friday, July 01, 2011 12:43 AM > > > >> > To: lucene-net-dev@lucene.apache.org > > > >> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port > > > needed? > > > >> > > > > >> > Scott - > > > >> > > > > >> > The idea of the automated port is still worth doing. Perhaps it > > makes > > > >> sense > > > >> > for someone more passionate about the line-by-line idea to do that > > > work? > > > >> > > > > >> > I would say, focus on what makes sense to you. Being productive, > > > >> regardless > > > >> > of the specific direction, is what will be most valuable. Once you > > > >> start, > > > >> > others will join and momentum will build. That is how these things > > > work. > > > >> > > > > >> > I like DIGY's approach too, but the problem with it is that it is > a > > > >> > never-ending manual task. The theory behind the automated port is > > that > > > >> it > > > >> > may reduce the manual work. It is complicated, but once it's built > > and > > > >> > works, it will save a lot of future development hours. If it's > built > > > in > > > >> a > > > >> > sufficiently general manner, it could be useful for other project > > like > > > >> > Lucene.Net that want to automate a port from Java to C#. > > > >> > > > > >> > It might make sense for that to be a separate project from > > Lucene.Net > > > >> > though. > > > >> > > > > >> > -T > > > >> > > > > >> > > > > >> > On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard < > > > lombardena...@gmail.com > > > >> > >wrote: > > > >> > > > > >> > > Ok I think I asked the wrong question. I am trying to figure > out > > > >> where > > > >> > to > > > >> > > put my time. I was thinking about working on the automated > > porting > > > >> > system, > > > >> > > but when I saw the response to the .NET 4.0 discussions I > started > > to > > > >> > > question if that is the right direction. The community seemed > to > > be > > > >> more > > > >> > > interested in the .NET features. > > > >> > > > > > >> > > The complexity of the automated tool is going to become very > high > > > and > > > >> > will > > > >> > > probably end up with a line-for-line style port. So I keep > asking > > > my > > > >> > self > > > >> > > is the automated tool worth it. I don't think it is. > > > >> > > > > > >> > > I like the method has been Digy is using for porting the code. > So > > I > > > >> > guess > > > >> > > for me the real question is Digy where did you see 2.9.4g going > > next > > > >> and > > > >> > > what do you need help on? > > > >> > > > > > >> > > Scott > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > -----Original Message----- > > > >> > > > From: Digy [mailto:digyd...@gmail.com] > > > >> > > > Sent: Thursday, June 30, 2011 4:20 PM > > > >> > > > To: lucene-net-dev@lucene.apache.org > > > >> > > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave > port > > > >> > needed? > > > >> > > > > > > >> > > > Michael, > > > >> > > > You interpret the report as "whoever commits code wins"? But > > when > > > I > > > >> > look > > > >> > > > at it, I see "a lof of talk, no work". .Net community is not > > > >> interested > > > >> > > in > > > >> > > > contributing. > > > >> > > > I really don't understand what hinders people to work on > > > Lucene.Net. > > > >> As > > > >> > I > > > >> > > > did for 2.9.4g, grab the code, do whatever you want on it and > > > submit > > > >> > > back. > > > >> > > > If it doesn't fit to the project's direction it can still find > a > > > >> place > > > >> > in > > > >> > > > contrib or in branch. All of the approaches can live side by > > side > > > >> > happily > > > >> > > > in the Lucene.Net repository. > > > >> > > > > > > >> > > > Troy, > > > >> > > > I also don't understand why do you wait for 2.9.4g? It is a > > > *branch* > > > >> > and > > > >> > > > has nothing to do with the trunk. It need not be an offical > > > release > > > >> and > > > >> > > > can live in branch as a PoC. > > > >> > > > > > > >> > > > > > > >> > > > As a result, I got bored to listen to "this should be done > that > > > >> way". > > > >> > > What > > > >> > > > I want to see is "I did it that way, should we continue with > > > this". > > > >> > > > > > > >> > > > DIGY > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > -----Original Message----- > > > >> > > > From: Troy Howard [mailto:thowar...@gmail.com] > > > >> > > > Sent: Thursday, June 30, 2011 10:47 PM > > > >> > > > To: lucene-net-dev@lucene.apache.org > > > >> > > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave > port > > > >> > needed? > > > >> > > > > > > >> > > > Michael, > > > >> > > > > > > >> > > > I agree with everything you said. My point in saying "whoever > > > >> commits > > > >> > > code > > > >> > > > wins" was to illustrate the reality of how and why the project > > has > > > >> the > > > >> > > > current form. > > > >> > > > > > > >> > > > Building consensus is difficult. It is an essential first step > > > >> before > > > >> > we > > > >> > > > can > > > >> > > > do something like make a list of bit-sized pieces of work that > > > >> others > > > >> > can > > > >> > > > work on. > > > >> > > > > > > >> > > > This is why my real message of "Let's find a way to > accommodate > > > >> both" > > > >> > is > > > >> > > > so > > > >> > > > important. It allows us to build consensus, so that we can > > settle > > > on > > > >> a > > > >> > > > direction and structure our work. > > > >> > > > > > > >> > > > Until we accomplish that, it really is "whoever commits code > > > wins", > > > >> and > > > >> > > > that > > > >> > > > is an unhealthy and unmaintainable way to operate. > > > >> > > > > > > >> > > > From a technical perspective, your statements about the unit > > tests > > > >> are > > > >> > > > completely accurate. They really need a LOT of reworking. > That's > > > the > > > >> > very > > > >> > > > first step before making any significant changes. Part of the > > > >> problem > > > >> > is > > > >> > > > that the tests themselves are not well written. The other part > > is > > > >> that > > > >> > > the > > > >> > > > Lucene object model was not designed for testability, and it > > makes > > > >> > > writing > > > >> > > > good tests more difficult, and certain tests might not be > > > possible. > > > >> It > > > >> > > > will > > > >> > > > be difficult to write good unit tests without re-structuring. > > The > > > >> > biggest > > > >> > > > issue is the use of abstract classes with base behaviour vs > > > >> interfaces > > > >> > or > > > >> > > > fully abstracted classes. Makes mocking tough. This is the > > > direction > > > >> I > > > >> > > was > > > >> > > > going when I started the Lucere project. I'd like to start in > on > > > >> that > > > >> > > work > > > >> > > > after the 2.9.4g release. > > > >> > > > > > > >> > > > Thanks, > > > >> > > > Troy > > > >> > > > > > > >> > > > > > > >> > > > On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon < > > > >> > > > mhern...@wickedsoftware.net> wrote: > > > >> > > > > > > >> > > > > I'd say that is all the more reasons that we need to work > > > smarter > > > >> and > > > >> > > > not > > > >> > > > > harder. I'd also say thats a good reason to make sure we > build > > > >> > > consensus > > > >> > > > > rather than just saying whoever commits code wins. > > > >> > > > > > > > >> > > > > And its a damn good reason to focus on the effort of growing > > the > > > >> > number > > > >> > > > of > > > >> > > > > contributors and lowing the barrier to submitting patches, > > > >> breaking > > > >> > > > things > > > >> > > > > down into pieces that people would feel confident to work on > > > >> without > > > >> > > > > being overwhelmed by the complexity of Lucene.Net. > > > >> > > > > > > > >> > > > > There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 > > and > > > >> the > > > >> > > > > internals and index formats are significantly different > > > including > > > >> > > nixing > > > >> > > > > the > > > >> > > > > current vint file format and using byte[] array slices for > > Terms > > > >> > > instead > > > >> > > > of > > > >> > > > > char[]. > > > >> > > > > > > > >> > > > > So while porting 1 to 1 while require less knowledge or > > thought, > > > >> its > > > >> > > > most > > > >> > > > > likely going to require more hours of work. And Its > definitely > > > not > > > >> > > going > > > >> > > > to > > > >> > > > > guarantee the stability of the code or that its great code. > > > >> > > > > > > > >> > > > > I'd have to say that its not as stable as most would believe > > at > > > >> the > > > >> > > > moment. > > > >> > > > > > > > >> > > > > Most of the tests avoid anything that remotely looks like it > > > knows > > > >> > > about > > > >> > > > > the > > > >> > > > > DRY principle and there is a static constructor in the core > > test > > > >> case > > > >> > > > that > > > >> > > > > throws an exception if it doesn't find an environment > variable > > > >> "TEMP" > > > >> > > > which > > > >> > > > > will fail 90% of the tests and nunit will be unable to give > > you > > > a > > > >> > clear > > > >> > > > > reason why. Just to name a few issues I came across working > > > >> towards > > > >> > > > > getting > > > >> > > > > Lucene.Net into CI. I haven't even started really digging > in > > > >> under > > > >> > the > > > >> > > > > covers of the code yet. > > > >> > > > > > > > >> > > > > So my suggestion is to chew on this a bit more and build > > > >> consensus, > > > >> > > > avoid > > > >> > > > > fracturing people into sides. Be open to reservations and > > > >> concerns > > > >> > > that > > > >> > > > > others have and continue to address them. > > > >> > > > > > > > >> > > > > - Michael > > > >> > > > > > > > >> > > > > > > > >> > > > > On Thu, Jun 30, 2011 at 2:10 PM, Digy <digyd...@gmail.com> > > > wrote: > > > >> > > > > > > > >> > > > > > Although there are a lot of people using Lucene.Net, this > is > > > our > > > >> > > > > > contribution report for the past 5 years. > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ- > > > >> > > > 2Q > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=- > > > >> > > > 1&issue > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin > > > >> > > > .r > > > >> > > > > > eport.contributions%3Acontributionreport&Next=Next > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > DIGY > > > >> > > > > > > > > >> > > > > > -----Original Message----- > > > >> > > > > > From: Ayende Rahien [mailto:aye...@ayende.com] > > > >> > > > > > Sent: Thursday, June 30, 2011 8:16 PM > > > >> > > > > > To: Rory Plaire; lucene-net-dev@lucene.apache.org > > > >> > > > > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line > Jave > > > port > > > >> > > > needed? > > > >> > > > > > > > > >> > > > > > As someone from the nhibernate project > > > >> > > > > > We stopped following hibernate a while ago, and haven't > > > >> regretted > > > >> > it > > > >> > > > > > We have mire features, less bugs and better code base > > > >> > > > > > > > > >> > > > > > Sent from my Windows Phone From: Rory Plaire > > > >> > > > > > Sent: Thursday, June 30, 2011 19:58 > > > >> > > > > > To: lucene-net-dev@lucene.apache.org > > > >> > > > > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line > Jave > > > port > > > >> > > > needed? > > > >> > > > > > I don't want to drag this out much longer, but I am > curious > > > with > > > >> > > > people > > > >> > > > > who > > > >> > > > > > hold the "line-by-line" sentiment - are you NHibernate > > users? > > > >> > > > > > > > > >> > > > > > -r > > > >> > > > > > > > > >> > > > > > On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght < > > > >> > lysag...@hotmail.com> > > > >> > > > > > wrote: > > > >> > > > > > > > > >> > > > > > > Can I just plug in my bit and say I agree 100% with what > > > Moray > > > >> > has > > > >> > > > > > outlined > > > >> > > > > > > below. > > > >> > > > > > > > > > >> > > > > > > If we move away from the line by line port then over > time > > > >> we'll > > > >> > > > loose > > > >> > > > > out > > > >> > > > > > > on the momentum that is Lucene and the improvements that > > > they > > > >> > make. > > > >> > > > > > > It is only if the Lucene.NET community has expertise in > > > >> search, > > > >> > a > > > >> > > > > deep > > > >> > > > > > > knowledge of the project and the community can guarantee > > > that > > > >> the > > > >> > > > > > knowledge > > > >> > > > > > > will survive members coming and going should such a > > > >> consideration > > > >> > > be > > > >> > > > > > give. > > > >> > > > > > > > > > >> > > > > > > When Lucene.NET has stood on it's feet for a number of > > years > > > >> > after > > > >> > > > it > > > >> > > > > has > > > >> > > > > > > moved out of Apache incubation should consideration be > > given > > > >> to > > > >> > > > > > abandoning > > > >> > > > > > a > > > >> > > > > > > line by line port. > > > >> > > > > > > By all means extend and wrap the libraries in .NET > > > equivalents > > > >> > and > > > >> > > > .NET > > > >> > > > > > > goodness like LINQ (we do this internally in our company > > at > > > >> the > > > >> > > > > moment); > > > >> > > > > > but > > > >> > > > > > > leave the core of the project on a line by line port. > > > >> > > > > > > > > > >> > > > > > > Just my tu-pence worth. > > > >> > > > > > > > > > >> > > > > > > Kind Regards > > > >> > > > > > > Noel > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > -----Original Message----- From: Moray McConnachie > > > >> > > > > > > Sent: Thursday, June 30, 2011 10:25 AM > > > >> > > > > > > > > > >> > > > > > > To: lucene-net-user@lucene.apache.**org< > > > >> > > > > > lucene-net-u...@lucene.apache.org> > > > >> > > > > > > Cc: > > > >> > > > > > lucene-net-dev@incubator.**apache.org< > > > >> > > > > lucene-net-...@incubator.apache.org> > > > >> > > > > > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line > > Jave > > > >> port > > > >> > > > > needed? > > > >> > > > > > > > > > >> > > > > > > I don't think I'm as hard core on this as Neal, but > > > remember: > > > >> the > > > >> > > > > > > history of the Lucene.NET project is that all the > > > intellectual > > > >> > > work, > > > >> > > > > all > > > >> > > > > > > the understanding of search, all the new features come > > from > > > >> the > > > >> > > > Lucene > > > >> > > > > > > Java folks. Theirs is an immensely respected project, > and > > I > > > >> trust > > > >> > > > them > > > >> > > > > > > to add new features that will be well-tested and > > > >> well-researched, > > > >> > > > and > > > >> > > > > to > > > >> > > > > > > have a decent roadmap which I can trust they will > execute > > > on. > > > >> > > > > > > > > > >> > > > > > > Now I know there's been an influx of capable developers > to > > > >> > > > Lucene.NET > > > >> > > > > > > who are ready, willing and (I'm going to assume) able to > > add > > > a > > > >> > lot > > > >> > > > more > > > >> > > > > > > value in a generic .NET implementation as they change > it. > > > But > > > >> > it'll > > > >> > > > > take > > > >> > > > > > > a while before I trust a .NET dedicated framework which > is > > > >> > > > > significantly > > > >> > > > > > > diverged from Java in the way I do the line-by-line > > version. > > > >> And > > > >> > at > > > >> > > > > what > > > >> > > > > > > stage is it not just not a line-by-line port, but not a > > port > > > >> at > > > >> > > all? > > > >> > > > > > > > > > >> > > > > > > At the same time, I recognise that if this project is > > going > > > to > > > >> > > > > continue, > > > >> > > > > > > and attract good developers, it has to change in this > > > >> direction. > > > >> > > > > > > > > > >> > > > > > > So that said, I can see why a line-by-line port might > not > > be > > > >> > > > > > > sustainable. And most people don't need it. But most of > us > > > >> using > > > >> > > > Lucene > > > >> > > > > > > in production systems do need a system that we can trust > > and > > > >> rely > > > >> > > > on. > > > >> > > > > So > > > >> > > > > > > let me chime in with someone else's plea, to keep the > > > general > > > >> > > > structure > > > >> > > > > > > close to Lucene, to keep the same general objects and > > > >> inheritance > > > >> > > > > > > set-up, and to keep the same method names, even if you > add > > > >> other > > > >> > > > > methods > > > >> > > > > > > and classes to provide additional functionality. > > ABSOLUTELY > > > >> the > > > >> > > same > > > >> > > > > > > file formats. End users benefit a lot from a high degree > > of > > > >> > > > similarity, > > > >> > > > > > > with good documentation and help being available from > the > > > Java > > > >> > > > > > > community. > > > >> > > > > > > > > > >> > > > > > > Yours, > > > >> > > > > > > Moray > > > >> > > > > > > ------------------------------**------- > > > >> > > > > > > Moray McConnachie > > > >> > > > > > > Director of IT +44 1865 261 600 > > > >> > > > > > > Oxford Analytica http://www.oxan.com > > > >> > > > > > > > > > >> > > > > > > -----Original Message----- > > > >> > > > > > > From: Granroth, Neal V. > > > >> > > > > > > > > >> > > > [mailto:neal.granroth@**thermofisher.com< > > > >> > neal.granr...@thermofisher.com> > > > >> > > > > > > ] > > > >> > > > > > > Sent: 29 June 2011 20:47 > > > >> > > > > > > To: lucene-net-user@lucene.apache.**org< > > > >> > > > > > lucene-net-u...@lucene.apache.org> > > > >> > > > > > > Cc: > > > >> > > > > > lucene-net-dev@incubator.**apache.org< > > > >> > > > > lucene-net-...@incubator.apache.org> > > > >> > > > > > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line > > Jave > > > >> port > > > >> > > > > needed? > > > >> > > > > > > > > > >> > > > > > > This is has been discussed many times. > > > >> > > > > > > Lucene.NET is not valid, the code cannot be trusted, if > it > > > is > > > >> not > > > >> > a > > > >> > > > > > > line-by-line port. It ceases to be Lucene. > > > >> > > > > > > > > > >> > > > > > > - Neal > > > >> > > > > > > > > > >> > > > > > > -----Original Message----- > > > >> > > > > > > From: Scott Lombard > > > >> > > > > > [mailto:lombardenator@gmail.**com<lombardena...@gmail.com > > > > > >> > > > > > > ] > > > >> > > > > > > Sent: Wednesday, June 29, 2011 1:58 PM > > > >> > > > > > > To: lucene-net-dev@lucene.apache.**org < > > > >> > > > > lucene-net-dev@lucene.apache.org > > > >> > > > > > >; > > > >> > > > > > > lucene-net-user@lucene.apache.**org <lucene-net- > > > >> > > > u...@lucene.apache.org > > > >> > > > > > > > > >> > > > > > > Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave > > port > > > >> > > needed? > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > After the large community response about moving the code > > > base > > > >> > from > > > >> > > > .Net > > > >> > > > > > > 2.0 to Net 4.0 I am trying to figure out what is the > need > > > for > > > >> a > > > >> > > > > > > line-by-line port. Starting with Digy's excellent work > on > > > the > > > >> > > > > > > conversion to generics a priority of the 2.9.4g release > is > > > the > > > >> 2 > > > >> > > > > > > packages would not be interchangeable. So faster > > turnaround > > > >> from > > > >> > a > > > >> > > > > java > > > >> > > > > > > release won't matter to non line-by-line users they will > > > have > > > >> to > > > >> > > > wait > > > >> > > > > > > until the updates are made to the non line-by-line code > > > base. > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > My question is there really a user base for the > > line-by-line > > > >> > port? > > > >> > > > > > > Anyone have a comment? > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > Scott > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > ------------------------------**--------------------------- > > > >> > > > > > > Disclaimer > > > >> > > > > > > > > > >> > > > > > > This message and any attachments are confidential and/or > > > >> > > privileged. > > > >> > > > If > > > >> > > > > > > this has been sent to you in error, please do not use, > > > retain > > > >> or > > > >> > > > > disclose > > > >> > > > > > > them, and contact the sender as soon as possible. > > > >> > > > > > > > > > >> > > > > > > Oxford Analytica Ltd > > > >> > > > > > > Registered in England: No. 1196703 > > > >> > > > > > > 5 Alfred Street, Oxford > > > >> > > > > > > United Kingdom, OX1 4EH > > > >> > > > > > > > > ------------------------------**--------------------------- > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > >