Published source doesn't match published bytecode

[markslater]

For example, net.snowflake.client.core.SessionUtil in version 3.13.7 has differences between the source and binary jars published in Maven. This makes it very difficult to use with a debugger.

Looking at the differences, it seems perhaps the source goes through some sort of automated optimisation/obfusaction step prior to being compiled, but that the published source is the unmassaged version.

[sfc-gh-mknister]

Hi @markslater, we don't do any obfuscation. The source and binary are published together using regular maven commands. What kind of differences are you referring to?

[markslater]

Hi @sfc-gh-mknister, I can see that the imports are different between the source and the bytecode. A couple of examples from net.snowflake.client.core.SessionUtil:

1. The source code imports org.jsoup.Jsoup whereas the bytecode imports net.client.jdbc.internal.org.jsoup.Jsoup
2. The bytecode imports net.client.jdbc.internal.org.jsoup.nodes.Element but the source code makes no mention of this class.

There may well be other types of difference - my IDE shows 80 differences in that class alone, but I suspect most of them are due to the normal loss of information such as variable names when compiling.

[jhy]

This is coming from the use of the Maven Shade plugin to create a fat jar, which copies dependencies into the these internal packages.

https://github.com/snowflakedb/snowflake-jdbc/blob/master/pom.xml#L596

I was a bit surprised to see a library publishing a far jar to the Maven repo. Generally they're used internally for bundling applications, but as a library it can lead to a lot of duplicative code etc. With a regular jar, users / deployers can shade in different versions of libs if there are version conflicts at their discretion.

And in this implementation it looks like the dependencies are being redistributed without the appropriate attribution and licenses included. Can you fix that? Or let me know if I missed where in the distribution they are located.

[jdimeo]

The fat .jar is useful for contexts/database clients like DBeaver or DataGrip where a JDBC driver needs to be completely "self contained". However, for application development, ideally there would be an unshaded .jar available for us to do the "normal" thing of transient dependency management (attribution, signing, licenses, file sizes, managing versions, etc.).

[jdimeo]

See https://github.com/snowflakedb/snowflake-jdbc/issues/174

[sfc-gh-igarish]

To clean up and re-prioritize more pressing bugs and feature requests we are closing all issues older than 6 months as of March 1, 2023. If there are any issues or feature requests that you would like us to address, please create them according to the new templates we have created. For urgent issues, opening a support case with this link Snowflake Community is the fastest way to get a response.