[
https://issues.apache.org/jira/browse/HIVE-26984?focusedWorklogId=841714&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-841714
]
ASF GitHub Bot logged work on HIVE-26984:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 26/Jan/23 11:22
Start Date: 26/Jan/23 11:22
Worklog Time Spent: 10m
Work Description: zabetak commented on code in PR #3983:
URL: https://github.com/apache/hive/pull/3983#discussion_r1087707504
##########
common/src/java/org/apache/hadoop/hive/conf/HiveConf.java:
##########
@@ -6322,29 +6322,67 @@ public ZooKeeperHiveHelper getZKConfig() {
.trustStorePassword(trustStorePassword).build();
}
+ public static HiveConf create() {
+ return new HiveConf();
+ }
+
+ public static HiveConf create(Class<?> cls) {
+ return new HiveConf(cls);
+ }
+
+ public static HiveConf create(Configuration other, Class<?> cls) {
+ return new HiveConf(other, cls);
+ }
+
+
+ public static HiveConf create(HiveConf other) {
+ return new HiveConf(other);
+ }
+
+ /**
+ * Instantiating HiveConf is deprecated. Please use
+ * HiveConf#create() to construct a Configuration,
+ * this method will become private eventually.
+ * @deprecated Please use create method instead.
+ */
public HiveConf() {
Review Comment:
Please include the `@Deprecated` annotation it is useful for some purposes.
"Instantiating HiveConf is deprecated" phrase is redundant. IDEs and
compilers will generate automatically similar warnings when calling this method.
"Instatiating...eventually" the whole paragraph concerns deprecation so it
should be associated with the `@deprecated` tag.
Based on [1] and the comments above, I would suggest the following:
```java
/**
* @deprecated This method will become private eventually; Use {@link
#create()} instead.
*/
@Deprecated
public HiveConf() {
```
[1]
https://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html
##########
common/src/java/org/apache/hadoop/hive/conf/HiveConf.java:
##########
@@ -6322,29 +6322,67 @@ public ZooKeeperHiveHelper getZKConfig() {
.trustStorePassword(trustStorePassword).build();
}
+ public static HiveConf create() {
+ return new HiveConf();
+ }
+
+ public static HiveConf create(Class<?> cls) {
+ return new HiveConf(cls);
+ }
+
+ public static HiveConf create(Configuration other, Class<?> cls) {
+ return new HiveConf(other, cls);
+ }
+
+
+ public static HiveConf create(HiveConf other) {
+ return new HiveConf(other);
+ }
+
+ /**
+ * Instantiating HiveConf is deprecated. Please use
+ * HiveConf#create() to construct a Configuration,
+ * this method will become private eventually.
Review Comment:
If we make those private then we are breaking inheritance which is fine by
me but wanted to mention it just in case.
For sanity reasons I would also attempt to run the precommit tests with all
the constructors private to see if there are any hidden reflection calls or
other exotic usages.
Issue Time Tracking
-------------------
Worklog Id: (was: 841714)
Time Spent: 40m (was: 0.5h)
> Deprecate public HiveConf constructors
> --------------------------------------
>
> Key: HIVE-26984
> URL: https://issues.apache.org/jira/browse/HIVE-26984
> Project: Hive
> Issue Type: Improvement
> Reporter: László Bodor
> Assignee: László Bodor
> Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> From time to time we investigate configuration object problems that are hard
> to investigate. We can improve this area, e.g. with HIVE-26985, but first, we
> need to introduce a public static factory method to hook into the creation
> process. I can see this pattern in another projects as well, like:
> HBaseConfiguration.
> Creating custom HiveConf subclasses can be useful because putting optional
> (say: if else branches or whatever) stuff into the original HiveConf object's
> hot codepaths can turn it less performant instantly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
