You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Steve Loughran <st...@hortonworks.com> on 2017/06/23 09:29:57 UTC
when did static .* imports fall found of checkstyle
I've justone a patch for HADOOP-15553 -moving Azure module to the parallel integration tests of hadoop-aws, and now checkstyle is telling me off for the same static .* imports as I've been using up till now
org.apache.hadoop.fs.azure.metrics.AzureFileSystemInstrumentation. [UnusedImports]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/AzureTestUtils.java:38:import static org.apache.hadoop.fs.azure.integration.AzureTestConstants.*;: Using the '.*' form of import should be avoided - org.apache.hadoop.fs.azure.integration.AzureTestConstants.*. [AvoidStarImport]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/AzureTestUtils.java:273: return testUniqueForkId == null ? defVal ::46: ':' should be on a new line. [OperatorWrap]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/ITestAzureHugeFiles.java:42:import static org.apache.hadoop.fs.azure.integration.AzureTestUtils.*;: Using the '.*' form of import should be avoided - org.apache.hadoop.fs.azure.integration.AzureTestUtils.*. [AvoidStarImport]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/ITestAzureHugeFiles.java:43:import static org.apache.hadoop.fs.contract.ContractTestUtils.*;: Using the '.*' form of import should be avoided -
I know we mustn't use that for importing all the classes in a package, but we've never had any restrictions on using it for static imports until now
Re: when did static .* imports fall found of checkstyle
Posted by Steve Loughran <st...@hortonworks.com>.
On 23 Jun 2017, at 19:24, Andrew Wang <an...@cloudera.com>> wrote:
This is my personal opinion, but I don't like wildcard imports in general. One example is that it makes it harder to determine the API impact when reviewing a patch that changes the version of a JAR. Given that IDEs manage imports for you, I don't see much benefit from wildcard imports either.
I'm strongly in favour of package imports, as it means that when someone adds a new class to a package, your compilation can actually fail if it clashes with another import. But blocking it for the names of constant strings? Overkill which will only lead to IDe prompts about unknown entry is added, unused imports whenever one is cut. Remember, before there was that constant .* import we used to put them all in interfaces and simply use implements: that strategy also pushes them into subclasses, which is probably more dangerous. Do we want to back to that?
On Fri, Jun 23, 2017 at 2:29 AM, Steve Loughran <st...@hortonworks.com>> wrote:
I've justone a patch for HADOOP-15553 -moving Azure module to the parallel integration tests of hadoop-aws, and now checkstyle is telling me off for the same static .* imports as I've been using up till now
org.apache.hadoop.fs.azure.metrics.AzureFileSystemInstrumentation. [UnusedImports]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/AzureTestUtils.java:38:import static org.apache.hadoop.fs.azure.integration.AzureTestConstants.*;: Using the '.*' form of import should be avoided - org.apache.hadoop.fs.azure.integration.AzureTestConstants.*. [AvoidStarImport]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/AzureTestUtils.java:273: return testUniqueForkId == null ? defVal ::46: ':' should be on a new line. [OperatorWrap]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/ITestAzureHugeFiles.java:42:import static org.apache.hadoop.fs.azure.integration.AzureTestUtils.*;: Using the '.*' form of import should be avoided - org.apache.hadoop.fs.azure.integration.AzureTestUtils.*. [AvoidStarImport]
./hadoop-tools/hadoop-azure/src/test/java/org/apache/hadoop/fs/azure/integration/ITestAzureHugeFiles.java:43:import static org.apache.hadoop.fs.contract.ContractTestUtils.*;: Using the '.*' form of import should be avoided -
I know we mustn't use that for importing all the classes in a package, but we've never had any restrictions on using it for static imports until now
Re: when did static .* imports fall found of checkstyle
Posted by Andrew Wang <an...@cloudera.com>.
This is my personal opinion, but I don't like wildcard imports in general.
One example is that it makes it harder to determine the API impact when
reviewing a patch that changes the version of a JAR. Given that IDEs manage
imports for you, I don't see much benefit from wildcard imports either.
On Fri, Jun 23, 2017 at 2:29 AM, Steve Loughran <st...@hortonworks.com>
wrote:
>
>
> I've justone a patch for HADOOP-15553 -moving Azure module to the parallel
> integration tests of hadoop-aws, and now checkstyle is telling me off for
> the same static .* imports as I've been using up till now
>
>
> org.apache.hadoop.fs.azure.metrics.AzureFileSystemInstrumentation.
> [UnusedImports]
> ./hadoop-tools/hadoop-azure/src/test/java/org/apache/
> hadoop/fs/azure/integration/AzureTestUtils.java:38:import static
> org.apache.hadoop.fs.azure.integration.AzureTestConstants.*;: Using the
> '.*' form of import should be avoided - org.apache.hadoop.fs.azure.
> integration.AzureTestConstants.*. [AvoidStarImport]
> ./hadoop-tools/hadoop-azure/src/test/java/org/apache/
> hadoop/fs/azure/integration/AzureTestUtils.java:273: return
> testUniqueForkId == null ? defVal ::46: ':' should be on a new line.
> [OperatorWrap]
> ./hadoop-tools/hadoop-azure/src/test/java/org/apache/
> hadoop/fs/azure/integration/ITestAzureHugeFiles.java:42:import static
> org.apache.hadoop.fs.azure.integration.AzureTestUtils.*;: Using the '.*'
> form of import should be avoided - org.apache.hadoop.fs.azure.integration.AzureTestUtils.*.
> [AvoidStarImport]
> ./hadoop-tools/hadoop-azure/src/test/java/org/apache/
> hadoop/fs/azure/integration/ITestAzureHugeFiles.java:43:import static
> org.apache.hadoop.fs.contract.ContractTestUtils.*;: Using the '.*' form
> of import should be avoided -
>
> I know we mustn't use that for importing all the classes in a package, but
> we've never had any restrictions on using it for static imports until now
>