|
From: Trenton L. <Tre...@cn...> - 2002-06-05 16:59:01
|
> The 1.3 stuff is probably still the code that is > primarily used as most people won't have migrated > to 1.4. (Least that's my experience) Agreed. Our platform upgrade cycle is 6 - 9 months. Luckily, 1.4 was announced at the beginning, so it's being considered, but it'll be next year before we switch. As an alternative, so we can support both 1.3 and 1.4 developers, any mock that needs to be JDK-specific could be instantiated via a factory. The factory could look at the rev of JDK you're running and select the appropriate class accordingly. *trenton -----Original Message----- From: Jeff Martin [mailto:je...@mk...] Sent: Wednesday, June 05, 2002 3:16 AM To: MockObjects Subject: Re: [MO-java-dev] Compiling under JDK1.4? On Mon, 2002-06-03 at 00:08, Scott Lamb wrote: > When will mockobjects be able to compile under JDK 1.4? It does not now > - the SQL stuff does not implement nearly all of the necessary interfaces. Sorry hadn't realized this was the case. > > I had this working in April, but you didn't like my approach - > automatically generating all the stuff that throws > NotImplementedException, getting rid of a bunch of existing code in > there as well as fixing this problem, at the expense of a slightly more > complicated build.xml. > > What approach would you like? It would be easy to paste the generated > code into the source files. As much as I don't like that way, it would > work. And I really would like to see it working under 1.4. Keeping 1.3 > around just for this is silly. > Probably the thing to do is inherit where possible from the common/1.3 mocks and implement any new methods using notImplemented(); apart from any that you may need to be fully mocked. The 1.3 stuff is probably still the code that is primarily used as most people won't have migrated to 1.4. (Least that's my experience) > -- > Scott Lamb > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev -- _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Mockobjects-java-dev mailing list Moc...@li... https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev |
|
From: Jeff M. <je...@mk...> - 2002-06-05 17:38:17
|
It's actually a lot easier than that. The build system currently tailors the build to each JDK. So as long as someone builds against the relavent JDK a jar will be produced that is appropriate. We just need to put some 1.4 specific code in the src/jdk/1.4 dir. On Wed, 2002-06-05 at 17:58, Trenton Lipscomb wrote: > > The 1.3 stuff is probably still the code that is > > primarily used as most people won't have migrated > > to 1.4. (Least that's my experience) > > Agreed. Our platform upgrade cycle is 6 - 9 months. Luckily, 1.4 was announced at the beginning, so it's being considered, but it'll be next year before we switch. > > As an alternative, so we can support both 1.3 and 1.4 developers, any mock that needs to be JDK-specific could be instantiated via a factory. The factory could look at the rev of JDK you're running and select the appropriate class accordingly. > > *trenton > > -----Original Message----- > From: Jeff Martin [mailto:je...@mk...] > Sent: Wednesday, June 05, 2002 3:16 AM > To: MockObjects > Subject: Re: [MO-java-dev] Compiling under JDK1.4? > > > On Mon, 2002-06-03 at 00:08, Scott Lamb wrote: > > When will mockobjects be able to compile under JDK 1.4? It does not now > > - the SQL stuff does not implement nearly all of the necessary interfaces. > > Sorry hadn't realized this was the case. > > > > > I had this working in April, but you didn't like my approach - > > automatically generating all the stuff that throws > > NotImplementedException, getting rid of a bunch of existing code in > > there as well as fixing this problem, at the expense of a slightly more > > complicated build.xml. > > > > What approach would you like? It would be easy to paste the generated > > code into the source files. As much as I don't like that way, it would > > work. And I really would like to see it working under 1.4. Keeping 1.3 > > around just for this is silly. > > > > Probably the thing to do is inherit where possible from the common/1.3 > mocks and implement any new methods using notImplemented(); apart from > any that you may need to be fully mocked. > > The 1.3 stuff is probably still the code that is primarily used as most > people won't have migrated to 1.4. (Least that's my experience) > > > > -- > > Scott Lamb > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Mockobjects-java-dev mailing list > > Moc...@li... > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > -- > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev -- |