[ https://issues.apache.org/jira/browse/PARQUET-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17768408#comment-17768408 ]
ASF GitHub Bot commented on PARQUET-2347: ----------------------------------------- amousavigourabi commented on code in PR #1141: URL: https://github.com/apache/parquet-mr/pull/1141#discussion_r1335211048 ########## parquet-avro/src/main/java/org/apache/parquet/avro/AvroWriteSupport.java: ########## @@ -423,7 +435,7 @@ private static GenericData getDataModel(Configuration conf, Schema schema) { Class<? extends AvroDataSupplier> suppClass = conf.getClass( AVRO_DATA_SUPPLIER, SpecificDataSupplier.class, AvroDataSupplier.class); - return ReflectionUtils.newInstance(suppClass, conf).get(); + return ReflectionUtils.newInstance(suppClass, ConfigurationUtil.createHadoopConfiguration(conf)).get(); Review Comment: For now this seems necessary to me in order not to introduce any breaking changes. AFAIK clients _could_ make suppClass be their own implementation, which under Parquet prior to this change would involve invoking setConf(Configuration) if that class were Hadoop Configurable (which is what Hadoop's ReflectionUtils.newInstance(Class, Configuration) also does under the hood). > Add interface layer between Parquet and Hadoop Configuration > ------------------------------------------------------------ > > Key: PARQUET-2347 > URL: https://issues.apache.org/jira/browse/PARQUET-2347 > Project: Parquet > Issue Type: Improvement > Components: parquet-mr > Reporter: Atour Mousavi Gourabi > Priority: Minor > > Parquet relies heavily on a few Hadoop classes, such as its Configuration > class, which is used throughout Parquet's reading and writing logic. If we > include our own interface for this, this could potentially allow users to use > Parquet's readers and writers without the Hadoop dependency later on. > In order to preserve backward compatibility and avoid breaking downstream > projects, the constructors and methods using Hadoop's constructor should be > preserved for the time being, though I would favour deprecation in the near > future. > This is part of an effort that has been [discussed on the dev mailing > list|https://lists.apache.org/thread/4wl0l3d9dkpx4w69jx3rwnjk034dtqr8]. -- This message was sent by Atlassian Jira (v8.20.10#820010)