Hi Nandor!

Ah, I wasn't aware that the method is new. What I actually meant was that code 
generation that previously worked now generates code that no longer compiles, 
which I would say is a regression. The implementation of customEncode() in the 
class representing the outer record calls the corresponding method on its 
nested records, which won't compile if they are in different packages. This did 
not happen before since the method did not exist, so the code compiled. Here's 
an example schema that reproduces the problem:

{"namespace": "org.apache.avro.codegentest.some",
  "type": "record",
  "name": "NestedSomeNamespaceRecord",
  "doc" : "Test nested types with different namespace than the outer type",
  "fields": [
    {
      "name": "nestedRecord",
      "type": {
        "namespace": "org.apache.avro.codegentest.other",
        "type": "record",
        "name": "NestedOtherNamespaceRecord",
        "fields": [
          {
            "name": "someField",
            "type": "int"
          }
        ]
      }
    }]
}

And an example from the generated code:

  @Override protected void customEncode(org.apache.avro.io.Encoder out)
    throws java.io.IOException
  {
    this.nestedRecord.customEncode(out);

  }

//Katrin


On 2019-05-03, 11:15, "Nandor Kollar" <[email protected]> wrote:

    Hi Katrin,
    
    It appears to me, that these methods didn't exist in previous Avro
    versions, they were added in https://github.com/apache/avro/pull/350 and
    were renamed and reduced their visibility in
    
https://github.com/apache/avro/pull/350/commits/d320b6b536c49b485be45286dbdb73226eef4b35.
    Actually it looks like the version with public visibility wasn't even
    merged to master.
    
    Are you using a fork of Avro where these method were public, or am I
    missing something? I'm not against of making these methods public (however
    I guess the author of the change had some reason to reduce the scope form
    public to protected), however don't think this should be a blocker for the
    release, as this doesn't seem to be a regression.
    
    Thanks,
    Nandor
    
    On Fri, May 3, 2019 at 10:43 AM Katrin Skoglund <[email protected]>
    wrote:
    
    > Hi all,
    >
    > I just managed to test the new RC, specifically the Java code generation,
    > with one of the libraries we use. I then noticed that their generated java
    > code no longer compiles because of a change in access level of two 
methods.
    >
    > The generated methods customEncode and customDecode are protected in this
    > version of Avro. They used to be public. This means that the generated 
java
    > code for schemas using nested records with different namespaces will no
    > longer compile.
    >
    > I think it would be good to fix this before releasing since it is a real
    > easy fix, unless there is a good reason why the access level was changed 
to
    > protected?
    >
    > I'll start a PR for this anyway, please let me know if you want the fix in
    > some other way or if I should create a Jira first (new to the process
    > here).
    >
    > //Katrin
    >
    >
    > On 2019-04-30, 12:55, "Driesprong, Fokko" <[email protected]> wrote:
    >
    >     Hi everyone,
    >
    >     Since the last release of Apache Avro 1.8.2 on May 31, 2017. Two years
    >     later,
    >     I'm thrilled to propose the following RC to be released as official
    > Apache
    >     Avro 1.9.0 release.
    >
    >     The commit id is 24ff48c32d8d13433a1e31e485ef2af187d1eb62
    >     * This corresponds to the tag: release-1.9.0-rc3
    >     * https://github.com/apache/avro/releases/tag/release-1.9.0-rc3/
    >
    >     The release tarball, signature, and checksums are here:
    >     * https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc3/
    >
    >     You can find the KEYS file here:
    >     * https://dist.apache.org/repos/dist/dev/avro/KEYS
    >
    >     Binary artifacts for Java are staged in Nexus here:
    >     *
    >
    > 
https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
    >
    >     This release includes 272 Jira issues:
    >     https://issues.apache.org/jira/projects/AVRO/versions/12333394
    >     * Deprecate Joda-Time in favor of Java8 JSR310 and setting it as
    > default
    >     * Remove support for Hadoop 1.x
    >     * Move from Jackson 1.x to 2.9
    >     * Add ZStandard Codec
    >     * Lots of updates on the dependencies to fix CVE's
    >     * and many, many more!
    >
    >     Since RC1, two commits have been added:
    >     * https://jira.apache.org/jira/browse/AVRO-2381
    >     * https://jira.apache.org/jira/browse/AVRO-2383
    >
    >     Since RC2 the SHA1/MD5 checksums have been replaced with SHA512
    >
    >     Please download, verify, and test. This vote will remain open for at
    > least
    >     72 hours. Given sufficient votes, I would like to close it on or about
    >     midnight
    >     on Saturday, 4th of May 2019.
    >
    >     [ ] +1 Release this as Apache Avro 1.9.0
    >     [ ] +0
    >     [ ] -1 Do not release this because...
    >
    >     Consider this a +1 (non-binding) from my side:
    >     * Compiled the new version of Parquet against the Divolte collector 
and
    >     Apache Parquet
    >
    >     Cheers, Fokko Driesprong
    >
    >
    >
    

Reply via email to