[jira] [Created] (AVRO-3755) [Rust] Deserialization fails for reader schema with namespace

[Matthew Cargille (Jira)]

Matthew Cargille created AVRO-3755:
--

 Summary: [Rust] Deserialization fails for reader schema with 
namespace 
 Key: AVRO-3755
 URL: https://issues.apache.org/jira/browse/AVRO-3755
 Project: Apache Avro
  Issue Type: Bug
  Components: rust
Reporter: Matthew Cargille


Deserializing an avro value fails when using a reader schema with a namespace 
in avro 
0.14.0. Probably related to AVRO-3735. May be working in 0.15.0 but it's an 
issue that's impacting our code and we'd like to double-check that a test case 
will cover it.
 
Structs (from rs-gen)
{code:java}
#[derive(
    Debug, PartialEq, Eq, Hash, PartialOrd, Ord, Clone, serde::Deserialize, 
serde::Serialize,
)]
pub enum Bar {
    #[serde(rename = "bar0")]
    Bar0,
    #[serde(rename = "bar1")]
    Bar1,
    #[serde(rename = "bar2")]
    Bar2,
}

#[derive(Debug, PartialEq, Eq, Clone, serde::Deserialize, serde::Serialize)]
pub struct Foo {
    #[serde(rename = "barInit")]
    pub bar_init: Bar,
    #[serde(rename = "barUse")]
    pub bar_use: Bar,
} {code}
 
Writer schema (serializes successfully)
{code:java}
fn get_raw_example_schema() -> String {
    r#"{
    "type": "record",
    "name": "Foo",
    "fields":
    [
        {
            "name": "barInit",
            "type":
            {
                "type": "enum",
                "name": "Bar",
                "symbols":
                [
                    "bar0",
                    "bar1"
                ]
            }
        },
        {
            "name": "barUse",
            "type": "Bar"
        }
    ]
    }"#
    .to_string()
} {code}
Reader Schema
{code:java}
fn get_raw_example_schema_v2() -> String {
    r#"{
    "type": "record",
    "name": "Foo",
    "namespace": "name.space",
    "fields":
    [
        {
            "name": "barInit",
            "type":
            {
                "type": "enum",
                "name": "Bar",
                "symbols":
                [
                    "bar0",
                    "bar1",
                    "bar2"
                ]
            }
        },
        {
            "name": "barUse",
            "type": "Bar"
        }
    ]
}"#
    .to_string()
} {code}
Test code:
{code:java}
#[test]
fn test_deserialize() {
    testing_logger::setup();
    let schema = Schema::parse_str(_raw_example_schema()).unwrap();
    let foo = Foo {
        bar_init: Bar::Bar0,
        bar_use: Bar::Bar1,
    };    let avro_value = to_value(foo).unwrap();
    println!(
        "value is valid for schema: {}",
        avro_value.validate()
    );    let datum = to_avro_datum(, avro_value).unwrap();
    let mut x = [..];
    let read_schema = Schema::parse_str(_raw_example_schema_v2()).unwrap();
    let deser_value = from_avro_datum(,  x, 
Some(_schema)).unwrap();
    testing_logger::validate(|logs| {
        for log in logs {
            println!("{}", log.body)
        }
    });
} {code}
 
error
{code:java}
panicked at 'called `Result::unwrap()` on an `Err` value: 
SchemaResolutionError(Name { name: "Bar", namespace: None }) {code}
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [JAVA] Proposal: Dropping theUnsafe

[Fokko Driesprong]

Hi Niels,

Thanks for raising this. I'm having trouble understanding what you're
running into. Looks like the CI pass on Java 11+
?
Are the Unsafe paths not hit by the tests?

If it helps, four years ago, I also did some similar changes in Parquet
. I think we can port these
changes also to Avro. Unfortunately, we still need to support Java8, since big
projects like Hive  are
still not on Java11. Related to this, I also opened up a PR to bring back
Java 8 support for Thrift , I
don't think that we can drop this soon.

Kind regards,
Fokko Driesprong


Op vr 5 mei 2023 om 15:08 schreef Christophe Le Saëc :

> As far as i understood, MethodHandle is design to replace Unsafe call
> <
> http://mydailyjava.blogspot.com/2018/04/jdk-11-and-proxies-in-world-past.html
> >
> If not, forget my first message.
>
> Le ven. 5 mai 2023 à 14:37, Oscar Westra van Holthe - Kind <
> os...@westravanholthe.nl> a écrit :
>
> > Hi Niels,
> >
> > This is a very good plan. Though personally I prefer using the latest LTS
> > version, I think we should require the oldest, actively supported LST
> > version. For the next 5 months, this means Java 11.
> >
> > This link may be of interest here: https://endoflife.date/java
> >
> >
> > Kind regards,
> > Oscar
> >
> > On Fri, 5 May 2023 at 12:44, Niels Basjes  wrote:
> >
> > > Hi,
> > >
> > > Currently several build plugins cannot be upgraded because the newer
> > > versions require Java 11+.
> > > So I'm working on this and I have a partially working pull request
> > >
> > > https://issues.apache.org/jira/browse/AVRO-3716
> > > https://github.com/apache/avro/pull/2118
> > >
> > > One of the things I ran into is that currently the main library MUST be
> > > built with JDK 8 because otherwise the code referring to theUnsafe
> simply
> > > won't build.
> > > Now there is already special code in place to use a reflection based
> > system
> > > that is used if you are not running on Java 8.
> > >
> > > Since "everyone" I know is already running on Java 11 and 17 I propose
> to
> > > - kick theUnsafe code, making the code in that area a lot simpler.
> > > - Build the entire project with JDK 17 (or 11, but I prefer going to
> the
> > > latest LTS version)
> > > - Make it still produce Java 8 compliant code where possible (so just
> > about
> > > everywhere but not Thrift).
> > > - Have checks in place to do a simple basic test using Java 8
> > (toolchains)
> > >
> > > One of the effects is that the build on Github will no longer use the
> > > "matrix" build and will build the project only once (I expect it to
> > > become faster because of that).
> > >
> > > Your opinions on this?
> > >
> > > --
> > > Best regards / Met vriendelijke groeten,
> > >
> > > Niels Basjes
> > >
> >
> >
> > --
> >
> > ✉️ Oscar Westra van Holthe - Kind 
> >
>

[GitHub] [avro] dependabot[bot] opened a new pull request, #2214: Bump serde from 1.0.160 to 1.0.162 in /lang/rust

[via GitHub]

dependabot[bot] opened a new pull request, #2214:
URL: https://github.com/apache/avro/pull/2214

   Bumps [serde](https://github.com/serde-rs/serde) from 1.0.160 to 1.0.162.
   
   Release notes
   Sourced from https://github.com/serde-rs/serde/releases;>serde's releases.
   
   1.0.162
   
   
   Support deserializing flattened adjacently tagged enums from data formats 
which represent fields as bytes, such as the csv crate (https://redirect.github.com/serde-rs/serde/issues/2377;>#2377, thanks 
https://github.com/mfro;>@​mfro)
   #[derive(Deserialize)]
   pub struct Record {
   common: u64,
   #[serde(flatten)]
   kind: Kind,
   }
   #[derive(Deserialize)]
   #[serde(tag = kind, content = parameter, rename_all 
= lowercase)]
   enum Kind {
   Foo(u64),
   Bar(bool),
   }
   
   common,kind,parameter
   1,foo,42
   2,bar,true
   
   
   
   v1.0.161
   
   Improve error messages produced by serde_test on test failure (https://redirect.github.com/serde-rs/serde/issues/2435;>#2435, thanks 
https://github.com/Mingun;>@​Mingun)
   
   
   
   
   Commits
   
   https://github.com/serde-rs/serde/commit/99f165b45abc05b6104c4eb0dcbc7a2e2c3d821a;>99f165b
 Release 1.0.162
   https://github.com/serde-rs/serde/commit/2fb556074625fc3c97d8fabe026936c0c04e5b6e;>2fb5560
 Attempt to generate just one copy of TagContentOtherFieldVisitor's field 
matc...
   https://github.com/serde-rs/serde/commit/bd653ab30cca7c362660a1f6bb069b7b2a891115;>bd653ab
 Format PR 2377 with rustfmt
   https://github.com/serde-rs/serde/commit/b5d68aedaa85edea926c882df6d3cb9346de9d98;>b5d68ae
 Merge pull request https://redirect.github.com/serde-rs/serde/issues/2377;>#2377 from 
mfro/master
   https://github.com/serde-rs/serde/commit/624879c4c690217101adc9e10fd9ecc5d9ee9708;>624879c
 Merge pull request https://redirect.github.com/serde-rs/serde/issues/2441;>#2441 from 
dtolnay/test
   https://github.com/serde-rs/serde/commit/bd9e9abf352f8cc31cf69309455aa970ab04275a;>bd9e9ab
 Reimplement tests that touched serde_test internal API
   https://github.com/serde-rs/serde/commit/3e4a23cbd064f983e0029404e69b1210d232f94f;>3e4a23c
 Release 1.0.161
   https://github.com/serde-rs/serde/commit/6326ceec3f18fc030f19f5300df18f2a8265df3d;>6326cee
 Don't panic in serde_test on running out of tokens
   https://github.com/serde-rs/serde/commit/8f4d37c7ec696ec5a04202ab14e14b292cc7c8b1;>8f4d37c
 Convert serde_test's assert_next_token from macro to function
   https://github.com/serde-rs/serde/commit/1b8290b3185e00769cbca2abe695aafed153;>1b8290b
 Convert serde_test's unexpected from macro to function
   Additional commits viewable in https://github.com/serde-rs/serde/compare/v1.0.160...1.0.162;>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=serde=cargo=1.0.160=1.0.162)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (AVRO-3754) upgrade to jackson 2.15.0

[PJ Fanning (Jira)]

PJ Fanning created AVRO-3754:


 Summary: upgrade to jackson 2.15.0
 Key: AVRO-3754
 URL: https://issues.apache.org/jira/browse/AVRO-3754
 Project: Apache Avro
  Issue Type: Task
  Components: java
Reporter: PJ Fanning


There is a already a dependabot PR that has been merged.

[https://github.com/apache/avro/pull/2208]

I'm a Jackson committer and I'd like to highlight that there are some big 
changes in Jackson 2.15.0 and unfortunately, they are causing some problems for 
some users.

I have commented on the PR (2208) about my concerns. I would discourage Avro 
team from making an Avro release with Jackson 2.15.0 as a dependency and I 
think you really need to consider the impact of the 
[StreamReadConstraints|https://javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.15.0/com/fasterxml/jackson/core/StreamReadConstraints.html]
 changes in particular.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [avro] RyanSkraba merged pull request #2213: fix(AVRO-3737): fix memcheck test

[via GitHub]

RyanSkraba merged PR #2213:
URL: https://github.com/apache/avro/pull/2213


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [JAVA] Proposal: Dropping theUnsafe

[Christophe Le Saëc]

As far as i understood, MethodHandle is design to replace Unsafe call

If not, forget my first message.

Le ven. 5 mai 2023 à 14:37, Oscar Westra van Holthe - Kind <
os...@westravanholthe.nl> a écrit :

> Hi Niels,
>
> This is a very good plan. Though personally I prefer using the latest LTS
> version, I think we should require the oldest, actively supported LST
> version. For the next 5 months, this means Java 11.
>
> This link may be of interest here: https://endoflife.date/java
>
>
> Kind regards,
> Oscar
>
> On Fri, 5 May 2023 at 12:44, Niels Basjes  wrote:
>
> > Hi,
> >
> > Currently several build plugins cannot be upgraded because the newer
> > versions require Java 11+.
> > So I'm working on this and I have a partially working pull request
> >
> > https://issues.apache.org/jira/browse/AVRO-3716
> > https://github.com/apache/avro/pull/2118
> >
> > One of the things I ran into is that currently the main library MUST be
> > built with JDK 8 because otherwise the code referring to theUnsafe simply
> > won't build.
> > Now there is already special code in place to use a reflection based
> system
> > that is used if you are not running on Java 8.
> >
> > Since "everyone" I know is already running on Java 11 and 17 I propose to
> > - kick theUnsafe code, making the code in that area a lot simpler.
> > - Build the entire project with JDK 17 (or 11, but I prefer going to the
> > latest LTS version)
> > - Make it still produce Java 8 compliant code where possible (so just
> about
> > everywhere but not Thrift).
> > - Have checks in place to do a simple basic test using Java 8
> (toolchains)
> >
> > One of the effects is that the build on Github will no longer use the
> > "matrix" build and will build the project only once (I expect it to
> > become faster because of that).
> >
> > Your opinions on this?
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
> >
>
>
> --
>
> ✉️ Oscar Westra van Holthe - Kind 
>

Re: [JAVA] Proposal: Dropping theUnsafe

[Oscar Westra van Holthe - Kind]

Hi Niels,

This is a very good plan. Though personally I prefer using the latest LTS
version, I think we should require the oldest, actively supported LST
version. For the next 5 months, this means Java 11.

This link may be of interest here: https://endoflife.date/java


Kind regards,
Oscar

On Fri, 5 May 2023 at 12:44, Niels Basjes  wrote:

> Hi,
>
> Currently several build plugins cannot be upgraded because the newer
> versions require Java 11+.
> So I'm working on this and I have a partially working pull request
>
> https://issues.apache.org/jira/browse/AVRO-3716
> https://github.com/apache/avro/pull/2118
>
> One of the things I ran into is that currently the main library MUST be
> built with JDK 8 because otherwise the code referring to theUnsafe simply
> won't build.
> Now there is already special code in place to use a reflection based system
> that is used if you are not running on Java 8.
>
> Since "everyone" I know is already running on Java 11 and 17 I propose to
> - kick theUnsafe code, making the code in that area a lot simpler.
> - Build the entire project with JDK 17 (or 11, but I prefer going to the
> latest LTS version)
> - Make it still produce Java 8 compliant code where possible (so just about
> everywhere but not Thrift).
> - Have checks in place to do a simple basic test using Java 8 (toolchains)
>
> One of the effects is that the build on Github will no longer use the
> "matrix" build and will build the project only once (I expect it to
> become faster because of that).
>
> Your opinions on this?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>


-- 

✉️ Oscar Westra van Holthe - Kind 

[GitHub] [avro] RyanSkraba merged pull request #2204: [hotfix][java][test] RecordWithTimestamps#equals should compare its own localDateTime with that.localDateTime

[via GitHub]

RyanSkraba merged PR #2204:
URL: https://github.com/apache/avro/pull/2204


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [JAVA] Proposal: Dropping theUnsafe

[Niels Basjes]

Hi,

Curious: what is the advantage of the FieldAccessHandle you wrote over the
(now present) FieldAccessReflect?
i.e. : Why did you create this alternative?

Niels

On Fri, May 5, 2023 at 1:47 PM Christophe Le Saëc 
wrote:

> Hello Niels,
> This is a nice idea !!
> In same spirit, few time ago, i wrote class FieldAccessHandle (see joined
> file), another extension of FieldAccess, that use
> "java.lang.invoke.MethodHandle" instead of Unsafe.
> And change ReflectionUtil class with it
>
> final FieldAccess unsafeAccess;
> if (javaVersion != null && javaVersion.startsWith("1.8")) {
>   unsafeAccess = load("org.apache.avro.reflect.FieldAccessUnsafe",
> FieldAccess.class);
> } else {
>   unsafeAccess = load("org.apache.avro.reflect.FieldAccessHandle",
> FieldAccess.class);
>
> }
>
> Hope it could help
>
> Le ven. 5 mai 2023 à 12:45, Niels Basjes  a écrit :
>
>> Hi,
>>
>> Currently several build plugins cannot be upgraded because the newer
>> versions require Java 11+.
>> So I'm working on this and I have a partially working pull request
>>
>> https://issues.apache.org/jira/browse/AVRO-3716
>> https://github.com/apache/avro/pull/2118
>>
>> One of the things I ran into is that currently the main library MUST be
>> built with JDK 8 because otherwise the code referring to theUnsafe simply
>> won't build.
>> Now there is already special code in place to use a reflection based
>> system
>> that is used if you are not running on Java 8.
>>
>> Since "everyone" I know is already running on Java 11 and 17 I propose to
>> - kick theUnsafe code, making the code in that area a lot simpler.
>> - Build the entire project with JDK 17 (or 11, but I prefer going to the
>> latest LTS version)
>> - Make it still produce Java 8 compliant code where possible (so just
>> about
>> everywhere but not Thrift).
>> - Have checks in place to do a simple basic test using Java 8 (toolchains)
>>
>> One of the effects is that the build on Github will no longer use the
>> "matrix" build and will build the project only once (I expect it to
>> become faster because of that).
>>
>> Your opinions on this?
>>
>> --
>> Best regards / Met vriendelijke groeten,
>>
>> Niels Basjes
>>
>

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

Re: [JAVA] Proposal: Dropping theUnsafe

[Christophe Le Saëc]

Hello Niels,
This is a nice idea !!
In same spirit, few time ago, i wrote class FieldAccessHandle (see joined
file), another extension of FieldAccess, that use
"java.lang.invoke.MethodHandle" instead of Unsafe.
And change ReflectionUtil class with it

final FieldAccess unsafeAccess;
if (javaVersion != null && javaVersion.startsWith("1.8")) {
  unsafeAccess = load("org.apache.avro.reflect.FieldAccessUnsafe",
FieldAccess.class);
} else {
  unsafeAccess = load("org.apache.avro.reflect.FieldAccessHandle",
FieldAccess.class);

}

Hope it could help

Le ven. 5 mai 2023 à 12:45, Niels Basjes  a écrit :

> Hi,
>
> Currently several build plugins cannot be upgraded because the newer
> versions require Java 11+.
> So I'm working on this and I have a partially working pull request
>
> https://issues.apache.org/jira/browse/AVRO-3716
> https://github.com/apache/avro/pull/2118
>
> One of the things I ran into is that currently the main library MUST be
> built with JDK 8 because otherwise the code referring to theUnsafe simply
> won't build.
> Now there is already special code in place to use a reflection based system
> that is used if you are not running on Java 8.
>
> Since "everyone" I know is already running on Java 11 and 17 I propose to
> - kick theUnsafe code, making the code in that area a lot simpler.
> - Build the entire project with JDK 17 (or 11, but I prefer going to the
> latest LTS version)
> - Make it still produce Java 8 compliant code where possible (so just about
> everywhere but not Thrift).
> - Have checks in place to do a simple basic test using Java 8 (toolchains)
>
> One of the effects is that the build on Github will no longer use the
> "matrix" build and will build the project only once (I expect it to
> become faster because of that).
>
> Your opinions on this?
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
/*
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * https://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.apache.avro.reflect;

import java.io.IOException;
import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.reflect.Field;

import org.apache.avro.AvroRuntimeException;
import org.apache.avro.io.Decoder;
import org.apache.avro.io.Encoder;

public class FieldAccessHandle extends FieldAccess {

  @Override
  protected FieldAccessor getAccessor(Field field) {
AvroEncode enc = field.getAnnotation(AvroEncode.class);
if (enc != null) {
  try {
final CustomEncoding customEncoding = enc.using().getDeclaredConstructor().newInstance();
return new HandleCustomEncodedFieldAccessor(field, customEncoding);
  } catch (ReflectiveOperationException ex) {
throw new AvroRuntimeException("Could not instantiate custom Encoding for " + enc.using().getName(), ex);
  }
} else {
  return new HandleFieldAccessor(field);
}
  }

  private static class HandleFieldAccessor extends FieldAccessor {

private final Field field;

private final boolean isStringable;

private final MethodHandle getter;

private final MethodHandle setter;

private final ReaderWriter rw;

public HandleFieldAccessor(Field field) {
  this.field = field;
  this.field.setAccessible(true);
  this.isStringable = field.isAnnotationPresent(Stringable.class);

  this.rw = new ReaderWriter(field.getType());
  try {
this.getter = MethodHandles.lookup().unreflectGetter(this.field);
this.setter = MethodHandles.lookup().unreflectSetter(this.field);
  } catch (IllegalAccessException ex) {
throw new AvroRuntimeException("Can't initiate field getter/setter for " + this.getFieldLongName(), ex);
  }

}

@Override
protected Object get(Object object) {
  try {
return this.getter.invoke(object);
  } catch (Throwable ex) {
throw new AvroRuntimeException(
"Can't get value for field " + getFieldLongName() + "for object " + this.getValueObject(object), ex);
  }
}

@Override
protected void set(Object object, Object value) {
  try {
this.setter.invoke(object, value);
  } catch (Throwable ex) {
throw new AvroRuntimeException("Can't set value for field 

[jira] [Created] (AVRO-3753) [Rust] Fix UnionSchema structure visibility

[Fedor Telnov (Jira)]

Fedor Telnov created AVRO-3753:
--

 Summary: [Rust] Fix UnionSchema structure visibility
 Key: AVRO-3753
 URL: https://issues.apache.org/jira/browse/AVRO-3753
 Project: Apache Avro
  Issue Type: Improvement
  Components: rust
Reporter: Fedor Telnov


If you look into `UnionSchema` struct, you'll find out that it both has 
`pub(crate)` constructor field(named "schemas") and `pub(crate)` constructor 
method("new"). Assuming this, it's clear that external user of your library is 
unable to build union by himself. The only thing external user can do is to 
parse unions from str.

This serious limitation could be avoid by simply removing visibility 
modifiers(I think nothing serious would happen).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (AVRO-3752) Logging flood during Union resolving

[Fedor Telnov (Jira)]

Fedor Telnov created AVRO-3752:
--

 Summary: Logging flood during Union resolving
 Key: AVRO-3752
 URL: https://issues.apache.org/jira/browse/AVRO-3752
 Project: Apache Avro
  Issue Type: Improvement
  Components: rust
Reporter: Fedor Telnov


I'm going to speak about Rust implementation(crate) of Avro named 
"apache-avro"([crates.io|[https://crates.io/crates/apache-avro]).]

Currently, union resolving is implemented as "iterate through listed schemas 
and find the first that matches given value". Process of finding requires 
schemas validation against that value. Validation method contains single 
"error!" macro invocation.

So, even if union contains relevant schema as variant, previous bad matches 
would throw error! log macro. In result, with big unions, you get a flooded 
logs.

My proposition is to write separate "validate" method that won't invoke error! 
macro and use it during union resolution.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[JAVA] Proposal: Dropping theUnsafe

[Niels Basjes]

Hi,

Currently several build plugins cannot be upgraded because the newer
versions require Java 11+.
So I'm working on this and I have a partially working pull request

https://issues.apache.org/jira/browse/AVRO-3716
https://github.com/apache/avro/pull/2118

One of the things I ran into is that currently the main library MUST be
built with JDK 8 because otherwise the code referring to theUnsafe simply
won't build.
Now there is already special code in place to use a reflection based system
that is used if you are not running on Java 8.

Since "everyone" I know is already running on Java 11 and 17 I propose to
- kick theUnsafe code, making the code in that area a lot simpler.
- Build the entire project with JDK 17 (or 11, but I prefer going to the
latest LTS version)
- Make it still produce Java 8 compliant code where possible (so just about
everywhere but not Thrift).
- Have checks in place to do a simple basic test using Java 8 (toolchains)

One of the effects is that the build on Github will no longer use the
"matrix" build and will build the project only once (I expect it to
become faster because of that).

Your opinions on this?

-- 
Best regards / Met vriendelijke groeten,

Niels Basjes

[GitHub] [avro] nielsbasjes merged pull request #2189: Bump protobuf-java from 3.22.2 to 3.22.3 in /lang/java

[via GitHub]

nielsbasjes merged PR #2189:
URL: https://github.com/apache/avro/pull/2189


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [avro] nielsbasjes merged pull request #2196: AVRO-3746: Bump grpc.version from 1.54.0 to 1.54.1

[via GitHub]

nielsbasjes merged PR #2196:
URL: https://github.com/apache/avro/pull/2196


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org