Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-48185][SQL] Fix 'symbolic reference class is not accessible: class sun.util.calendar.ZoneInfo' #46457

Closed
wants to merge 2 commits into from

Conversation

yaooqinn
Copy link
Member

@yaooqinn yaooqinn commented May 8, 2024

What changes were proposed in this pull request?

I met the error below while debugging UTs because of loading sun.util.calendar.ZoneInfo eagerly. This PR makes the relevant variables lazy.

Caused by: java.lang.IllegalAccessException: symbolic reference class is not accessible: class sun.util.calendar.ZoneInfo, from interface org.apache.spark.sql.catalyst.util.SparkDateTimeUtils (unnamed module @65d6b83b)
	at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
	at java.base/java.lang.invoke.MethodHandles$Lookup.checkSymbolicClass(MethodHandles.java:3686)
	at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3646)
	at java.base/java.lang.invoke.MethodHandles$Lookup.findVirtual(MethodHandles.java:2680)
	at org.apache.spark.sql.catalyst.util.SparkDateTimeUtils.$init$(SparkDateTimeUtils.scala:206)
	at org.apache.spark.sql.catalyst.util.DateTimeUtils$.<clinit>(DateTimeUtils.scala:41)
	... 82 more

Why are the changes needed?

sun.util.calendar.ZoneInfo is inaccessible in some scenarios.

Does this PR introduce any user-facing change?

Yes, such errors might be delayed from backend-scheduling to job-scheduling

How was this patch tested?

I tested with idea and UT debugging locally

Was this patch authored or co-authored using generative AI tooling?

no

@github-actions github-actions bot added the SQL label May 8, 2024
Copy link
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, it looks like a safe change.

cc @LuciferYang

@@ -197,8 +197,8 @@ trait SparkDateTimeUtils {
rebaseJulianToGregorianDays(julianDays)
}

private val zoneInfoClassName = "sun.util.calendar.ZoneInfo"
private val getOffsetsByWallHandle = {
private lazy val zoneInfoClassName = "sun.util.calendar.ZoneInfo"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to use lazy for this since zoneInfoClassName is just a String? 'Lazy' comes with the cost of locking.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, if TimeZone.getDefault.getOffset(localMillis) can be uniformly used to get timeZoneOffset in the toJavaDate function, then the use of the MethodHandle mechanism can be avoided here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, if TimeZone.getDefault.getOffset(localMillis) can be uniformly used to get timeZoneOffset in the toJavaDate function, then the use of the MethodHandle mechanism can be avoided here.

It seems that ZoneInfo.getOffset doesn't support daylight saving transitions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, but:

  1. Using TimeZone.getDefault.getOffset(localMillis), all tests can pass, perhaps the unit test coverage is not comprehensive, but what would be the counterexample?
  2. Looking at the inverse function fromJavaDate of toJavaDate, it does not take into account the scenario of ZoneInfo

@yaooqinn yaooqinn closed this in fe8b18b May 8, 2024
JacobZheng0927 pushed a commit to JacobZheng0927/spark that referenced this pull request May 11, 2024
…lass sun.util.calendar.ZoneInfo'

### What changes were proposed in this pull request?

I met the error below while debugging UTs because of loading `sun.util.calendar.ZoneInfo` eagerly. This PR makes the relevant variables lazy.

```log
Caused by: java.lang.IllegalAccessException: symbolic reference class is not accessible: class sun.util.calendar.ZoneInfo, from interface org.apache.spark.sql.catalyst.util.SparkDateTimeUtils (unnamed module 65d6b83b)
	at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:955)
	at java.base/java.lang.invoke.MethodHandles$Lookup.checkSymbolicClass(MethodHandles.java:3686)
	at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3646)
	at java.base/java.lang.invoke.MethodHandles$Lookup.findVirtual(MethodHandles.java:2680)
	at org.apache.spark.sql.catalyst.util.SparkDateTimeUtils.$init$(SparkDateTimeUtils.scala:206)
	at org.apache.spark.sql.catalyst.util.DateTimeUtils$.<clinit>(DateTimeUtils.scala:41)
	... 82 more
```

### Why are the changes needed?

sun.util.calendar.ZoneInfo is inaccessible in some scenarios.

### Does this PR introduce _any_ user-facing change?

Yes, such errors might be delayed from backend-scheduling to job-scheduling

### How was this patch tested?

I tested with idea and UT debugging locally

### Was this patch authored or co-authored using generative AI tooling?

no

Closes apache#46457 from yaooqinn/SPARK-48185.

Authored-by: Kent Yao <yao@apache.org>
Signed-off-by: Kent Yao <yao@apache.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants