>> I'm all for making this a gradual transition. That sentence was intended to
>> address the notion that the older methods will always be useful.
The gradual transition isn't to be done by the OFBiz project team. It's to be done by owners of
older projects based on older methods in OFBiz. Give those folks some time to change.
As far as OFBiz is concerned, the transition is instant. Or rather, as instant as the time it
takes for OFBiz to completely move away from the older methods (could be 1-2 days?). As we can
see, even OFBiz itself needs time to move. We can't possibly shut down OFBiz SVN and development
for those 2 days while OFBiz makes the move.
> Leave the other ones in place - deprecate them for all I care, but don't go
> around breaking things that aren't broken for other people.
For those projects that don't care about timezone or locale (say those that are only ever accessed
from one location), things really aren't broken. It just means those projects cannot be ported
over for international access.
> Should we keep the older methods that ignore the user's time zone and locale?
> My answer is No. As long as those methods remain in the class, lazy
> developers will try to use them. A perfect example is the commit in rev
> 586582 and the storm of controversy that erupted from it.
I still wonder why many Java developers don't pay attention to warning messages from the java
compiler. We should make it a point to note the deprecation warnings.
Well, ok, the 2 things to weigh may be these. Are there more lazy OFBiz committers (who ignore
deprecation warnings) now than there are old projects (that rely on older methods) out there?
Given the assumption that OFBiz is globally used, and we don't exactly know the full extent of its
adoption worldwide, I would guess backward compatibility is more important. It could be easier to
fix our lazy attitudes towards deprecation warnings, than to fix the multitude of deployed
implementations out there.
> It has been suggested that, instead of deprecating the older methods, they
> should have JavaDoc comments pointing out that they shouldn't be used. Well,
> if they shouldn't be used, then why keep them?
Because for older projects that rely on those old methods (even before the new ones came in),
there would be some costs in change propagation, fantastic documentation notwithstanding.
Deprecation must be done if those old methods are meant to be superseded by the new ones. Javadocs
alone won't help. I rely a lot on deprecation warnings.
> To summarize: Deprecating the methods provides an incentive for developers to
> stop using them. Backwards compatibility can be achieved by supplying some
> form of default objects to the new methods.
That isn't true backward compatibility. As long as old projects need to be changed, not merely
recompiled, then things are simply not backward compatible.
The old methods' implementation can be changed to point to and use the new methods. But the old
method signatures and behaviors must remain for true backward compatibility.
> From my perspective, any argument in support of keeping the older methods is
> an argument against internationalization.
I have no arguments against the new methods.
Jonathon
Jacques Le Roux wrote:
Sorry for my bad english : should be "even in Java very old deprecated methods still
stand"
De : "Jacques Le Roux" <[EMAIL PROTECTED]>
Tim, Adrian, all,
Thanks to Adrian, things are much more clear now and nobody (reading this ML)
can argue that he/her was not aware.
It seems that we got common ground now. I'm quite happy with that. I can help
to document and deprecate (which does not mean remove)
if needed...
It should be noted that even in Java very old deprecated method still stands.
Backwards compatibility is something we can't
seriously ignore.
Jacques
De : "Adrian Crum" <[EMAIL PROTECTED]>
Tim Ruppert <[EMAIL PROTECTED]> wrote:And no - I don't agree with your "leave no
room for discussion" stance on if you
don't go with what you're saying here you're against internationalization.
What I do think is that if people decided not to use the
methods that provide strong Locale and TimeZone dependence, then they open
themselves up to running into issues that they could've
avoided.
I agree with you here. I should have worded that sentence better - "From my
perspective, any argument against deprecating the
older methods is an argument against internationalization."
I'm all for making this a gradual transition. That sentence was intended to
address the notion that the older methods will always
be useful.
-Adrian
----- Message d'origine -----
De : Tim Ruppert
À : [email protected]
Envoyé : samedi 27 octobre 2007 22:44
Objet : Re: Dates, Times, Internationalization, and the UtilDateTime class
Adrian, first of all, I want to thank you for putting all of this information
in one place. it's a great thing for people to be
able to see your thought patterns and understand how all of this fits together.
Here are my pros and cons with what you're saying here:
Pros: You are bettering the project with more consistent and reproduceable
methods and procedures being put in.
Cons: This removes backwards compatibility and for those of us that don't
have one single application to keep track of - but
instead have a large number - this can be a costly modification to make.
So, what I'm saying here is that while I believe that the work that you are
doing here is a great win for the project overall, I
do not agree with breaking backwards compatibility to get there. Leave the
other ones in place - deprecate them for all I care, but
don't go around breaking things that aren't broken for other people.
And no - I don't agree with your "leave no room for discussion" stance on if
you don't go with what you're saying here you're
against internationalization. What I do think is that if people decided not to
use the methods that provide strong Locale and
TimeZone dependence, then they open themselves up to running into issues that
they could've avoided.
This is not a new project and these things are not new concepts - they evolve
and get better - but I see no reason to remove the
other methods at this point - deprecate them, document them, and put the
information explicitly in the Best Practices manual.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Oct 27, 2007, at 2:19 PM, Adrian Crum wrote:
I'm starting this thread in response to Jacques' suggestion that we discuss
date/time calculations, the UtilDateTime class, and
whether or not older methods in that class should be deprecated.
Anyone wanting to follow along or participate in the discussion should
start off by visiting these links:
http://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html
http://www.icu-project.org/docs/papers/international_calendars_in_java.html
http://www-128.ibm.com/developerworks/java/library/j-i18n.html#N1019D
Prior to the recent work done to bring user-selected time zones into the
project, OFBiz pretty much ignored a user's time zone
and locale and performed date/time calculations based upon the server's locale
and time zone. This caused problems for international
users - as the previous links point out.
The source of the problem was the UtilDateTime class, and Vinay Agarwal was
the first developer to address the issue -
https://issues.apache.org/jira/browse/OFBIZ-2. The UtilDateTime class was
updated in June 2007 to support the use of locales and
time zones in date/time calculations. Soon afterwards the framework was changed
to accomodate a user-selected time zone - the user's
java.util.TimeZone object is now available in the service context, the session,
and in the screen rendering context. In addition,
the user's last time zone selection is persisted.
Once all of the infrastructure was in place to support a user-selected time
zone, I worked on the Work Effort calendar to
support the new capability. That work was committed to the project in August
2007. It's important for this discussion that the
international community visit this link:
https://demo.hotwaxmedia.com/workeffort/control/month
and spend some time experimenting with various time zones and locales. This
is important because the server is located in the
central US, and yet the calendar always presents date/time data according to
the user's locale and time zone selections. The Work
Effort calendar is a perfect demonstration of the concepts presented by IBM and
the java community. The success of this effort was
due to using only the newer methods in UtilDateTime, and eliminating all calls
to the older methods.
With a successful working example of the new UtilDateTime methods, the
question comes up: Should we keep the older methods that
ignore the user's time zone and locale? My answer is No. As long as those
methods remain in the class, lazy developers will try to
use them. A perfect example is the commit in rev 586582 and the storm of
controversy that erupted from it.
I submitted a patch to deprecate the UtilDateTime methods that ignore the
user's locale and time zone -
https://issues.apache.org/jira/browse/OFBIZ-1361. That patch is being
challenged based upon the notion that the older methods will
always be useful. I don't agree with that view. Here's why:
Now that we have the capability to better internationalize OFBiz, we should
make efforts to do so. All of OFBiz should make use
of the new UtilDateTime methods so that the user is presented with consistent
date/time data. There will be places in OFBiz that
will have exceptions - places where the server's locale and time zone are
preferred. Let's use the Webtools component for an
example. If Webtools is intended to display date/time data in the server's time
zone and locale, then that component can construct
its own TimeZone and Locale objects to be passed to the new methods. The bottom
line is, if the older methods didn't exist, there
would still be ways to achieve the same results.
It has been suggested that, instead of deprecating the older methods, they
should have JavaDoc comments pointing out that they
shouldn't be used. Well, if they shouldn't be used, then why keep them?
To summarize: Deprecating the methods provides an incentive for developers
to stop using them. Backwards compatibility can be
achieved by supplying some form of default objects to the new methods.
From my perspective, any argument in support of keeping the older methods
is an argument against internationalization.
-Adrian
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
