Change in Parso Breaks spark-sas7bdat

[saurfang]

Change in Parso Breaks spark-sas7bdat

[xantorohara]

Hi, commit you mentioned is not relevant to this bug.

Actually, SasFileConstants class was refactored two years ago: epam/parso@ee01e3f#diff-746ec30848c9c785bcffda73b685a39ffec656f7bb971f2a2471e50ea92ae89b
In scope of that change the DATE_FORMAT_STRINGS and other date-related constants were moved to the DateTimeConstants class.

Note that you are trying to use internal implementation of the Parso, by exposing of Parso's private methods and fields in your ParsoWrapper class.

Nobody guarantee that internal structure or implementation will be unchangeable. Just because of it is not possible to improve code or add something new without any changes.

API classes and interfaces located in the "com.epam.parso" package supposed to be stable. But internal implementation located in the "com.epam.parso.impl" can be changed at any moment.

[mrugesh1989]

This commit here:

epam/parso@81c6608#diff-746ec30848c9c785bcffda73b685a39ffec656f7bb971f2a2471e50ea92ae89b

Removes DATE_FORMAT_STRINGS, et al which are needed in

com.github.saurfang.sas.parso.ParsoWrapper$.DATE_FORMAT_STRINGS$lzycompute(ParsoWrapper.scala:37) at com.github.saurfang.sas.parso.ParsoWrapper$.DATE_FORMAT_STRINGS(ParsoWrapper.scala:36)

@warrenmsmith - i am getting the same error when i try to run saurfang-3.0.0 with parso-2.0.14. it will be great if you can share the workaround of this issue.

[nbnm]

For future generations, the changes in parso-2.0.12 where SasFileConstants.java was adjusted and the reference for DATE_FORMAT_STRINGS has been removed. As a workaround, you can use parso-2.0.11 which works.

[ahmadmehr40]

I am also facing the same issue. Any workaround available for this issue or share the download link for the parso-2.0.11

[dcephilpott]

I'm also dealing with this issue - getting the error java.lang.NoSuchFieldException: DATE_FORMAT_STRINGS. When I install the 2.0.11 jar from Maven, everything works like a charm but 2.0.11 has a vulnerability that we wouldn't feel comfortable using in a production environment. Can we work to address this dependency issue? Thanks!!!