I guess the safest alternative would be to lazily initialize the `FastDateFormat#parser` field. Nevertheless, I do not want to miss this deprecation unicorn, and hence, deleted the code <https://github.com/apache/logging-log4j2/commit/f9766bb3b7cf7a914c3ae36358aa053ee088b097> and some tests <https://github.com/apache/logging-log4j2/commit/f9766bb3b7cf7a914c3ae36358aa053ee088b097> .
I ask for your understanding and forgiveness, Piotr. 🙇 On Thu, Nov 2, 2023 at 6:14 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Volkan, > > On Thu, 2 Nov 2023 at 16:16, Volkan Yazıcı <vol...@yazi.ci> wrote: > > I deleted all date parsing functionality in Log4j[1] and the > compilation... > > [drum roll...] succeeded. I am inclined to commit this breaking change. > We > > can refer users who were previously using Log4j to parse dates (ugh!) to > > Commons Lang. The API is identical, they simply need to use a > > separate package. *Objections?* > > I have mixed feelings about that. Technically it is a breaking change > in the API, since the package was never considered as private. > > On the other hand the alternative would be to either to remove the > `parser` field in `FastDateFormat` and change all the `parse` methods > to throw an exception or to rewire everything to use `FastDatePrinter` > instead of `FastDateFormat`. > > Piotr >
