Imagine, you use the DummyCalendar in Calendar2DateFieldConversion.

javaToSql will be ok.
 (... if (source instanceof Calendar) ...)

but sqlToJava will materialize not the DummyCalendar (that you need), but a GregorianCalendar.
(... GregorianCalendar cal = new GregorianCalendar()...)


 public class TestThingy2 extends TestCase
 {
   public void testCalendarConv()
   {
     DummyCalendar dc0 = new DummyCalendar();
     Date d = Calendar2DateFieldConversion.javaToSql(dc);
     Calendar dc1 = Calendar2DateFieldConversion.javaToSql(d);

     assertEquals(dc1, dc0); //will fail

     DummyCalendar dc2 = (DummyCalendar)dc1; //will fail
   }
 }

Absolutely - but then you must create your own conversion strategy !
Instanceof has nothing to do with this.
>
The Fieldconversion implementation must know what calendar implementation to
instantiate (although Calendar2DateFieldConversion should, probably, do
Calendar.getInstance and not instantiate GregorianCalendar directly) - and
it can't derive this information for the java.sql.Date

If you want to convert java.sql.Date <--> DummyCalendar then you have to
create a DummyCalendar2DateFileConversion class...

But imagine, someone doesn't care about the exact class of calendar, only calls getInstance(). In future JDKs, there may be a couple of Calendars, depending on locales... and OJB will silently degrade all of them onto GregorianCalendar.


In case of .getClass() match, the silent (and maybe not so easily debuggable) replacement of Calendar instances easily can't happen.
Are there any cons of .getClass() in favour of instanceof, that I'm missing?


But as you can notice in the title, i called it "little", so I don't think it's a huge issue - and it may be a timewaste to flame on the list around a single keyword...

And moreover, you are the developers of OJB and I'm currently only a [mostly happy] user, so the decision will be definitely yours...

David

Charles.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to