From: Theo Y. <ot...@ri...> - 2002-08-12 08:05:36
|
Sorry about the previous truncated post. I was thinking something similar along Charlie's lines, but in a subtlely different way (and subsequently had proposed this design to help drjava register Apple-specific handlers, so we can build on non-apple machines). So... JSR14 (whichever version) wants us to subclass a class Foo, in their codebase... What if we create a dummy subclass (say, AFoo) that delegates to our proprietary interface, that has identical methods (that way we could always swap out our implementation). Let's just use IFoo, for hypothetical reasons. Thus we have an AFoo class with no logic, and we can compile it *once* with the proprietary JSR14 classes, and zip it up into our lib directory, never to be touched again. In the meanwhile, we write and test whatever necessary IFoos that we wish... and we can instantiate AFoo (a full-fledged subclass of Foo) with reflection. So... we follow their rules and subclass -- but we don't dynamically load our "Foo adapter" to allow us to cooperate with their silly rules. Apple's event handlers also want us to subclass/implement Apple's proprietary event interfaces, so I had thought maybe this mechanism would enable us to do that without requiring the original interfaces to be on the classpath. However, this does pose an interesting dilemma still for testing. We would still need to have both versions of JSR14 available if we were to write testcases to handle each situation, no? (Eric?) What do we presently do to ensure that platform specific bugs don't propogate? Just some thoughts before bed... theo:) p.s. I had sent that previous message because it's evil how close Ctrl-X and Ctrl-C are on the keyboard (Pine shortcuts). I had originally meant to cancel the message and draft one later... but you guys saw what happenned :-D On Sun, 11 Aug 2002, Charles Reis wrote: > Date: Sun, 11 Aug 2002 22:49:33 -0500 > From: Charles Reis <cr...@ri...> > To: Brian Stoler <bs...@bs...> > Cc: drj...@li... > Subject: Re: [DrJava] ack re jsr14 1.2 > > Rather than compiling against the JSR-14 v1.0/v1.2 compilers directly, > couldn't we just invoke their compile, etc, methods using reflection? > Then we don't have to worry about this if the compiler interface changes > yet again-- we just "invoke" a different method... > > I'm not entirely against the other method (some classes only compile in > some environments), but I'd like to allow everyone to be able to compile > everything as long as we can, if possible... > > Of course, if reflection isn't an option, I think we'd have to do that > anyway-- JSR-14 v1.0 isn't available anymore, so only people who have an > old copy could compile DrJava if we went the route of requiring both. > (And we've already gotten complaints from people outside Rice who want > to compile. Rightfully so...) > > Charlie > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > drjava-hackers mailing list > drj...@li... > https://lists.sourceforge.net/lists/listinfo/drjava-hackers > |