[jira] [Commented] (AVRO-2336) Use Java Standard Charsets - Part 2

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804450#comment-16804450
 ] 

Hudson commented on AVRO-2336:
--

FAILURE: Integrated in Jenkins build AvroJava #630 (See 
[https://builds.apache.org/job/AvroJava/630/])
AVRO-2336: Use Java Standard Charsets - Part 2 (iemejia: 
[https://github.com/apache/avro/commit/c552c1746ff9bac97512fc7db2523f3cff1bd15d])
* (edit) 
lang/java/ipc-netty/src/test/java/org/apache/avro/ipc/netty/TestNettyServer.java
* (edit) lang/java/ipc/src/test/java/org/apache/avro/RPCMetaTestPlugin.java
* (edit) lang/java/avro/src/test/java/org/apache/avro/TestNestedRecords.java
* (edit) 
lang/java/tools/src/main/java/org/apache/avro/tool/SchemaNormalizationTool.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/SchemaBuilder.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/file/DataFileWriter.java
* (edit) 
lang/java/ipc/src/main/java/org/apache/avro/ipc/SaslSocketTransceiver.java
* (edit) 
lang/java/trevni/avro/src/main/java/org/apache/trevni/avro/AvroTrevniOutputFormat.java
* (edit) 
lang/java/trevni/avro/src/main/java/org/apache/trevni/avro/mapreduce/AvroTrevniRecordWriterBase.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/io/JsonDecoder.java
* (edit) 
lang/java/avro/src/test/java/org/apache/avro/TestReadingWritingDataInEvolvedSchemas.java
* (edit) lang/java/trevni/core/src/main/java/org/apache/trevni/OutputBuffer.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/io/JsonEncoder.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/io/BinaryEncoder.java
* (edit) 
lang/java/mapred/src/main/java/org/apache/avro/mapred/AvroTextOutputFormat.java
* (edit) 
lang/java/tools/src/main/java/org/apache/avro/tool/TrevniMetadataTool.java
* (edit) lang/java/tools/src/main/java/org/apache/avro/tool/ToTextTool.java
* (edit) 
lang/java/avro/src/main/java/org/apache/avro/io/parsing/ResolvingGrammarGenerator.java
* (edit) 
lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestFsInput.java
* (edit) lang/java/avro/src/test/java/org/apache/avro/io/TestBlockingIO.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/Protocol.java
* (edit) lang/java/ipc/src/main/java/org/apache/avro/ipc/SaslSocketServer.java
* (edit) 
lang/java/tools/src/test/java/org/apache/avro/tool/TestTextFileTools.java
* (edit) lang/java/trevni/core/src/main/java/org/apache/trevni/MetaData.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/io/ResolvingDecoder.java


> Use Java Standard Charsets - Part 2
> ---
>
> Key: AVRO-2336
> URL: https://issues.apache.org/jira/browse/AVRO-2336
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #630

[Apache Jenkins Server]

See 

Changes:

[iemejia] AVRO-2336: Use Java Standard Charsets - Part 2

--
[...truncated 265.87 KB...]
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position [implements org.apache.avro.generic.GenericEnumSymbol {  P, 
C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  
public org.apache.avro.Schema get]Schema() { return SC...> but was:<...ublic 
enum Position [{  P, C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClass]Schema() { return SC...>
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.avro.tool.TestSpecificCompilerTool.assertFileMatch(TestSpecificCompilerTool.java:133)
at 
org.apache.avro.tool.TestSpecificCompilerTool.testCompileSchemaTwoFiles(TestSpecificCompilerTool.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)

[ERROR] 
testCompileSchemaSingleFile(org.apache.avro.tool.TestSpecificCompilerTool)  
Time elapsed: 0.016 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position 

[jira] [Resolved] (AVRO-2336) Use Java Standard Charsets - Part 2

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía resolved AVRO-2336.

   Resolution: Fixed
Fix Version/s: 1.9.0

> Use Java Standard Charsets - Part 2
> ---
>
> Key: AVRO-2336
> URL: https://issues.apache.org/jira/browse/AVRO-2336
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Fix For: 1.9.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2336) Use Java Standard Charsets - Part 2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804405#comment-16804405
 ] 

ASF subversion and git services commented on AVRO-2336:
---

Commit c552c1746ff9bac97512fc7db2523f3cff1bd15d in avro's branch 
refs/heads/master from Beluga Behr
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=c552c17 ]

AVRO-2336: Use Java Standard Charsets - Part 2


> Use Java Standard Charsets - Part 2
> ---
>
> Key: AVRO-2336
> URL: https://issues.apache.org/jira/browse/AVRO-2336
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2362) Cannot Run spotless:apply From Root Pom

[JIRA]

[ 
https://issues.apache.org/jira/browse/AVRO-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804394#comment-16804394
 ] 

Ismaël Mejía commented on AVRO-2362:


I had not found a fix for this until now. I will update the 'How to contribute' 
page once this get merged..

> Cannot Run spotless:apply From Root Pom
> ---
>
> Key: AVRO-2362
> URL: https://issues.apache.org/jira/browse/AVRO-2362
> Project: Apache Avro
>  Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: Ismaël Mejía
>Priority: Major
>
> I was running {{mvn install}} from the root directory and it failed because 
> some of my code was not 'spotless'.  In response, I ran {{mvn 
> spotless:apply}} but it fails to run from the root avro project directory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (AVRO-2362) Cannot Run spotless:apply From Root Pom

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía reassigned AVRO-2362:
--

Assignee: Ismaël Mejía

> Cannot Run spotless:apply From Root Pom
> ---
>
> Key: AVRO-2362
> URL: https://issues.apache.org/jira/browse/AVRO-2362
> Project: Apache Avro
>  Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: Ismaël Mejía
>Priority: Major
>
> I was running {{mvn install}} from the root directory and it failed because 
> some of my code was not 'spotless'.  In response, I ran {{mvn 
> spotless:apply}} but it fails to run from the root avro project directory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2360) Java 8 timestamp-millis / timestamp-micros type inconsistency

[Raman Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804203#comment-16804203
 ] 

Raman Gupta commented on AVRO-2360:
---

Awesome, thanks for the quick resolution to both problems. Looking forward to 
the 1.9.0 release.

> Java 8 timestamp-millis / timestamp-micros type inconsistency
> -
>
> Key: AVRO-2360
> URL: https://issues.apache.org/jira/browse/AVRO-2360
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.9.0
> Environment: JDK 11.0.2 on Linux
>Reporter: Raman Gupta
>Assignee: Daniel Kulp
>Priority: Blocker
> Fix For: 1.9.0
>
>
> I am trying the new JSR 310 date/time types with a snapshot of 1.9.0.
> I see what seems to be an inconsistency. If I generate my code with a logical 
> type of "timestamp-millis", then the code is generated with `Instant`, as 
> expected. However, on JDK11 on Linux, if I do `Instant.now()` the Instant 
> value created contains microseconds. When setting this Instant on an instance 
> of the generated Avro SpecificRecord, I am unable to round-trip the data:
> Before serialization to bytes:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665308Z
> After serializing to bytes, and then back into a specific record the 
> microseconds are now truncated:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665Z
> I believe the compiler should generate a class that truncates the 
> microseconds at `setter` time for "timestamp-millis", so that the value 
> before serialization, and after deserialization, are the same. This can be 
> done with a call to the method `truncatedTo(ChronoUnit.MILLIS)`.
> Another, possibly related, oddity is that the "timestamp-micros" type 
> generates a class with `long` as the type of the field. Since Instant can 
> support both milli and micro-second precision, I don't see the reason for 
> this behavior.
> Followup on AVRO-2079.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #629

[Apache Jenkins Server]

See 

Changes:

[dkulp] [AVRO-2630] Part 2 - allow the JSR310 conversions to truncate at the

--
[...truncated 255.23 KB...]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.31 s - 
in org.apache.avro.tool.TestRpcReceiveAndSendTools
[INFO] Running org.apache.avro.tool.TestIdlToSchemataTool
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.472 s 
- in org.apache.avro.tool.TestIdlToSchemataTool
[INFO] Running org.apache.avro.tool.TestRecodecTool
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.622 s 
- in org.apache.avro.tool.TestRecodecTool
[INFO] Running org.apache.avro.tool.TestTetherTool
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.963 s 
- in org.apache.avro.tool.TestTetherTool
[INFO] Running org.apache.avro.tool.TestTextFileTools
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.325 s 
- in org.apache.avro.tool.TestTextFileTools
[INFO] Running org.apache.avro.tool.TestDataFileRepairTool
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.109 s 
- in org.apache.avro.tool.TestDataFileRepairTool
[INFO] Running org.apache.avro.tool.TestMain
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.083 s 
- in org.apache.avro.tool.TestMain
[INFO] Running org.apache.avro.tool.TestRpcProtocolTool
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.81 s - 
in org.apache.avro.tool.TestRpcProtocolTool
[INFO] Running org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] Tests run: 5, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 1.837 s 
<<< FAILURE! - in org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] 
testCompileSchemaTwoFiles(org.apache.avro.tool.TestSpecificCompilerTool)  Time 
elapsed: 1.232 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position [implements org.apache.avro.generic.GenericEnumSymbol {  P, 
C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  
public org.apache.avro.Schema get]Schema() { return SC...> but was:<...ublic 
enum Position [{  P, C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClass]Schema() { return SC...>
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.avro.tool.TestSpecificCompilerTool.assertFileMatch(TestSpecificCompilerTool.java:133)
at 
org.apache.avro.tool.TestSpecificCompilerTool.testCompileSchemaTwoFiles(TestSpecificCompilerTool.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunn

[jira] [Commented] (AVRO-2362) Cannot Run spotless:apply From Root Pom

[David Mollitor (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804185#comment-16804185
 ] 

David Mollitor commented on AVRO-2362:
--

[~nkollar] That works, but certainly not ideal :)

> Cannot Run spotless:apply From Root Pom
> ---
>
> Key: AVRO-2362
> URL: https://issues.apache.org/jira/browse/AVRO-2362
> Project: Apache Avro
>  Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Priority: Major
>
> I was running {{mvn install}} from the root directory and it failed because 
> some of my code was not 'spotless'.  In response, I ran {{mvn 
> spotless:apply}} but it fails to run from the root avro project directory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (AVRO-2360) Java 8 timestamp-millis / timestamp-micros type inconsistency

[Daniel Kulp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kulp resolved AVRO-2360.
---
   Resolution: Fixed
 Assignee: Daniel Kulp
 Hadoop Flags: Incompatible change
Fix Version/s: 1.9.0

> Java 8 timestamp-millis / timestamp-micros type inconsistency
> -
>
> Key: AVRO-2360
> URL: https://issues.apache.org/jira/browse/AVRO-2360
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.9.0
> Environment: JDK 11.0.2 on Linux
>Reporter: Raman Gupta
>Assignee: Daniel Kulp
>Priority: Blocker
> Fix For: 1.9.0
>
>
> I am trying the new JSR 310 date/time types with a snapshot of 1.9.0.
> I see what seems to be an inconsistency. If I generate my code with a logical 
> type of "timestamp-millis", then the code is generated with `Instant`, as 
> expected. However, on JDK11 on Linux, if I do `Instant.now()` the Instant 
> value created contains microseconds. When setting this Instant on an instance 
> of the generated Avro SpecificRecord, I am unable to round-trip the data:
> Before serialization to bytes:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665308Z
> After serializing to bytes, and then back into a specific record the 
> microseconds are now truncated:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665Z
> I believe the compiler should generate a class that truncates the 
> microseconds at `setter` time for "timestamp-millis", so that the value 
> before serialization, and after deserialization, are the same. This can be 
> done with a call to the method `truncatedTo(ChronoUnit.MILLIS)`.
> Another, possibly related, oddity is that the "timestamp-micros" type 
> generates a class with `long` as the type of the field. Since Instant can 
> support both milli and micro-second precision, I don't see the reason for 
> this behavior.
> Followup on AVRO-2079.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Feature freeze Apache Avro 1.9

[Daniel Kulp]

I made few commits today that change the generated code from the Schema 
compiler a bit….  The changes make Avro 1.9 a bit more incompatible with 1.8, 
but since they are going to have to migrate anyway, I thought it would be 
important to make the changes now rather then forcing everyone to do so in 
1.10.   The changes:

1) Default for “time” classes change from Joda to JSR310.  There is a flag to 
specify joda if they need/want it, but I think the “default” should be what we 
plan on supporting going forward, and I don’t think joda should be it. At 
this point, joda should go away.  :)

2) Private fields  - we were, by default, generating “@Deprecated public” 
fields.   The idea of generating deprecated code by default annoys me.   Thus, 
I changed the default to “private”.  Again, there is a setting to make them 
public (or deprecated/public) if they want it, but for the default, I believe 
private is what we want.

While those will increase the effort to migrate from 1.8 to 1.9, I think it’s 
better to do that now than waiting any longer.   

Thoughts?
Dan


> On Mar 26, 2019, at 9:31 AM, Driesprong, Fokko  wrote:
> 
> Hi all,
> 
> I'd like to cut the branch for Apache Avro 1.9 release this Friday, and
> start moving to a release candidate so we can test. If there are any
> features that you would like to get in, please let me know.
> 
> Cheers, Fokko

-- 
Daniel Kulp
dk...@apache.org  - http://dankulp.com/blog 

Talend Community Coder - http://talend.com 

[jira] [Commented] (AVRO-2362) Cannot Run spotless:apply From Root Pom

[Nandor Kollar (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804136#comment-16804136
 ] 

Nandor Kollar commented on AVRO-2362:
-

Try with {{mvn com.diffplug.spotless:spotless-maven-plugin:1.20.0:apply}}

> Cannot Run spotless:apply From Root Pom
> ---
>
> Key: AVRO-2362
> URL: https://issues.apache.org/jira/browse/AVRO-2362
> Project: Apache Avro
>  Issue Type: Improvement
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Priority: Major
>
> I was running {{mvn install}} from the root directory and it failed because 
> some of my code was not 'spotless'.  In response, I ran {{mvn 
> spotless:apply}} but it fails to run from the root avro project directory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (AVRO-2362) Cannot Run spotless:apply From Root Pom

[David Mollitor (JIRA)]

David Mollitor created AVRO-2362:


 Summary: Cannot Run spotless:apply From Root Pom
 Key: AVRO-2362
 URL: https://issues.apache.org/jira/browse/AVRO-2362
 Project: Apache Avro
  Issue Type: Improvement
Affects Versions: 1.9.0
Reporter: David Mollitor


I was running {{mvn install}} from the root directory and it failed because 
some of my code was not 'spotless'.  In response, I ran {{mvn spotless:apply}} 
but it fails to run from the root avro project directory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #628

[Apache Jenkins Server]

See 

Changes:

[dkulp] Change the default for generated fields to "private" so we aren't

[dkulp] [AVRO-2630] Part 1 - for JDR310, time-micros and timestamp-micros can be

[iemejia] AVRO-2346: Introduce JMH Performance Testing Framework

--
[...truncated 256.41 KB...]
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.avro.tool.TestSpecificCompilerTool.assertFileMatch(TestSpecificCompilerTool.java:121)
at 
org.apache.avro.tool.TestSpecificCompilerTool.testCompileSchemaTwoFiles(TestSpecificCompilerTool.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at 
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)

[ERROR] 
testCompileSchemaSingleFile(org.apache.avro.tool.TestSpecificCompilerTool)  
Time elapsed: 0.044 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position [implements org.apache.avro.generic.GenericEnumSymbol {  P, 
C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  
public org.apache.avro.Schema get]Schema() { return SC...> but was:<...ublic 
enum Position [{  P, C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClass]Schema() { return SC...>
at org.junit.Assert.assertEquals(

[jira] [Commented] (AVRO-2346) Introduce JMH Performance Testing Framework

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804105#comment-16804105
 ] 

Hudson commented on AVRO-2346:
--

FAILURE: Integrated in Jenkins build AvroJava #628 (See 
[https://builds.apache.org/job/AvroJava/628/])
AVRO-2346: Introduce JMH Performance Testing Framework (iemejia: 
[https://github.com/apache/avro/commit/48ed810a0d1352adcb3f608ff33b186ed433e784])
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/MapTest.java
* (edit) pom.xml
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/basic/ExtendedEnumTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/BigRecord.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/StringTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/record/ValidatingRecordTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/record/RecordWithDefaultTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectLongArrayTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/BasicRecord.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericStringTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/IntTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/basic/UnchangedUnionTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/BooleanTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectLargeFloatArrayTest.java
* (add) lang/java/perf/pom.xml
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/record/ResolvingRecordTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectNestedFloatArrayTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/DoubleTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/LongTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericWithDefaultTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/ArrayTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectDoubleArrayTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/basic/SmallLongTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/BytesTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/basic/FloatTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectBigRecordTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/record/RecordWithOutOfOrderTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericNestedFakeTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectLargeFloatArrayBlockedTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/record/RecordWithPromotionTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectIntArrayTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectRecordTest.java
* (edit) lang/java/pom.xml
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectFloatArrayTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/Perf.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericWithPromotionTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericNestedTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/record/RecordTest.java
* (add) lang/java/perf/src/main/java/org/apache/avro/test/BasicState.java
* (edit) lang/java/ipc/src/test/java/org/apache/avro/io/Perf.java
* (add) lang/java/perf/README.md
* (add) lang/java/perf/src/main/java/org/apache/avro/test/BasicArrayState.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/reflect/ReflectNestedObjectArrayTest.java
* (add) 
lang/java/perf/src/main/java/org/apache/avro/test/generic/GenericWithOutOfOrderTest.java


> Introduce JMH Performance Testing Framework
> ---
>
> Key: AVRO-2346
> URL: https://issues.apache.org/jira/browse/AVRO-2346
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Fix For: 1.9.0
>
>
> There exists already a {{org.apache.avro.io.Perf.java}} testing framework.  
> Very well done.
> However, I would like to introduce a new module to the Avro Java project that 
> leverages the OpenJDK JMH performance testing framework.  The framework will 
> allow the testing performance harness to keep up with the latest in 
> performance testing.
> https://openjdk.java.ne

[jira] [Resolved] (AVRO-2346) Introduce JMH Performance Testing Framework

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía resolved AVRO-2346.

   Resolution: Fixed
Fix Version/s: 1.9.0

> Introduce JMH Performance Testing Framework
> ---
>
> Key: AVRO-2346
> URL: https://issues.apache.org/jira/browse/AVRO-2346
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Fix For: 1.9.0
>
>
> There exists already a {{org.apache.avro.io.Perf.java}} testing framework.  
> Very well done.
> However, I would like to introduce a new module to the Avro Java project that 
> leverages the OpenJDK JMH performance testing framework.  The framework will 
> allow the testing performance harness to keep up with the latest in 
> performance testing.
> https://openjdk.java.net/projects/code-tools/jmh/
> I expect that this testing framework will require a few revisions to get it 
> "right," meaning producing actionable information.  This will require a hard 
> look by some domain experts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2346) Introduce JMH Performance Testing Framework

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804087#comment-16804087
 ] 

ASF subversion and git services commented on AVRO-2346:
---

Commit 48ed810a0d1352adcb3f608ff33b186ed433e784 in avro's branch 
refs/heads/master from Beluga Behr
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=48ed810 ]

AVRO-2346: Introduce JMH Performance Testing Framework


> Introduce JMH Performance Testing Framework
> ---
>
> Key: AVRO-2346
> URL: https://issues.apache.org/jira/browse/AVRO-2346
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
>
> There exists already a {{org.apache.avro.io.Perf.java}} testing framework.  
> Very well done.
> However, I would like to introduce a new module to the Avro Java project that 
> leverages the OpenJDK JMH performance testing framework.  The framework will 
> allow the testing performance harness to keep up with the latest in 
> performance testing.
> https://openjdk.java.net/projects/code-tools/jmh/
> I expect that this testing framework will require a few revisions to get it 
> "right," meaning producing actionable information.  This will require a hard 
> look by some domain experts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (AVRO-2361) Deprecate java-mapred Module

[David Mollitor (JIRA)]

David Mollitor created AVRO-2361:


 Summary: Deprecate java-mapred Module
 Key: AVRO-2361
 URL: https://issues.apache.org/jira/browse/AVRO-2361
 Project: Apache Avro
  Issue Type: Task
  Components: java
Affects Versions: 1.9.0
Reporter: David Mollitor
 Fix For: 1.10.0


MapReduce is deprecated in Hadoop 3.  Avro should do the same.  The future is 
Spark (and a splash of Tez/Impala).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #627

[Apache Jenkins Server]

See 

Changes:

[dkulp] Change default from joda to jsr310... no sense promoting the use of joda

--
[...truncated 516.90 KB...]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.074 s 
- in org.apache.avro.tool.TestMain
[INFO] Running org.apache.avro.tool.TestIdlToSchemataTool
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.371 s 
- in org.apache.avro.tool.TestIdlToSchemataTool
[INFO] Running org.apache.avro.tool.TestDataFileTools
[INFO] Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.756 s 
- in org.apache.avro.tool.TestDataFileTools
[INFO] Running org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 1.359 s 
<<< FAILURE! - in org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] 
testCompileSchemaTwoFiles(org.apache.avro.tool.TestSpecificCompilerTool)  Time 
elapsed: 0.928 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position [implements org.apache.avro.generic.GenericEnumSymbol {  P, 
C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  
public org.apache.avro.Schema get]Schema() { return SC...> but was:<...ublic 
enum Position [{  P, C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClass]Schema() { return SC...>
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.avro.tool.TestSpecificCompilerTool.assertFileMatch(TestSpecificCompilerTool.java:121)
at 
org.apache.avro.tool.TestSpecificCompilerTool.testCompileSchemaTwoFiles(TestSpecificCompilerTool.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapp

[jira] [Comment Edited] (AVRO-2359) Support Logical Types in C#

[Tim Roberts (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804008#comment-16804008
 ] 

Tim Roberts edited comment on AVRO-2359 at 3/28/19 3:06 PM:


I've opened an early PR (see Issue Links) for on-going review. The work is not 
complete but I'd appreciate early feedback in order to determine if there are 
things that I've missed or overlooked.

I believe that I've covered the 'core' of the changes needed to support logical 
types in C#, but all of the logical types outlined in the current specification 
need implementations (I currently only have "date").


was (Author: timjroberts):
I've opened an early PR (see Issue Links) for on-going review. The work is not 
complete but I'd appreciate early feedback in order to determine if there are 
things that I've missed or overlooked.

I believe that I've covered the 'core' of the changes needed to support logical 
types in C#, and the logical types outlined in the current specification need 
implementations.

> Support Logical Types in C#
> ---
>
> Key: AVRO-2359
> URL: https://issues.apache.org/jira/browse/AVRO-2359
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: csharp
>Reporter: Tim Roberts
>Priority: Critical
>
> By not supporting Logical Types, the C# Avro implementation is severely 
> limited in terms of its interoperability in heterogeneous environments. While 
> the implementation will safely ignore logical type declarations in processed 
> schemas; at runtime the semantics of a "date" for example, will be lost when 
> receiving an Avro payload that was encoded by the Java platform using the 
> same schema. The C# implementation will never be able to retrieve the date 
> value from the encoded int.
> I propose that the C# Avro implementation be extended to support the Logical 
> Types as defined by the current specification. I have also explored the 
> lang/csharp codebase and believe that I could produce a PR to support this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2359) Support Logical Types in C#

[Tim Roberts (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804008#comment-16804008
 ] 

Tim Roberts commented on AVRO-2359:
---

I've opened an early PR (see Issue Links) for on-going review. The work is not 
complete but I'd appreciate early feedback in order to determine if there are 
things that I've missed or overlooked.

I believe that I've covered the 'core' of the changes needed to support logical 
types in C#, and the logical types outlined in the current specification need 
implementations.

> Support Logical Types in C#
> ---
>
> Key: AVRO-2359
> URL: https://issues.apache.org/jira/browse/AVRO-2359
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: csharp
>Reporter: Tim Roberts
>Priority: Critical
>
> By not supporting Logical Types, the C# Avro implementation is severely 
> limited in terms of its interoperability in heterogeneous environments. While 
> the implementation will safely ignore logical type declarations in processed 
> schemas; at runtime the semantics of a "date" for example, will be lost when 
> receiving an Avro payload that was encoded by the Java platform using the 
> same schema. The C# implementation will never be able to retrieve the date 
> value from the encoded int.
> I propose that the C# Avro implementation be extended to support the Logical 
> Types as defined by the current specification. I have also explored the 
> lang/csharp codebase and believe that I could produce a PR to support this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Jenkins build is back to normal : AvroJava #626

[Apache Jenkins Server]

See 

[jira] [Resolved] (AVRO-2355) Add compressionLevel to ZStandard compression

[Daniel Kulp (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kulp resolved AVRO-2355.
---
Resolution: Fixed
  Assignee: Daniel Kulp

> Add compressionLevel to ZStandard compression
> -
>
> Key: AVRO-2355
> URL: https://issues.apache.org/jira/browse/AVRO-2355
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Reporter: Scott Carey
>Assignee: Daniel Kulp
>Priority: Major
> Fix For: 1.9.0
>
>
> ZStandard compression should not be released without support for compression 
> level selection.
> Its biggest advantage is the massive range by which you can select the 
> compression level, all while keeping decompression throughput very high.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2355) Add compressionLevel to ZStandard compression

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803893#comment-16803893
 ] 

Hudson commented on AVRO-2355:
--

FAILURE: Integrated in Jenkins build AvroJava #625 (See 
[https://builds.apache.org/job/AvroJava/625/])
AVRO-2355 [java] Add level and checksum options to ZStandard compression (dan: 
[https://github.com/apache/avro/commit/d81bffd41c348d8ffe11506fe26c66c58a37a580])
* (edit) lang/java/mapred/pom.xml
* (edit) lang/java/avro/src/main/java/org/apache/avro/file/ZstandardCodec.java
* (add) lang/java/avro/src/main/java/org/apache/avro/file/ZstandardLoader.java
* (edit) lang/java/avro/src/test/java/org/apache/avro/TestDataFile.java
* (edit) 
lang/java/mapred/src/test/java/org/apache/avro/mapreduce/TestAvroKeyOutputFormat.java
* (add) 
lang/java/avro/src/test/java/org/apache/avro/file/TestZstandardCodec.java
* (edit) lang/java/avro/src/main/java/org/apache/avro/file/CodecFactory.java


> Add compressionLevel to ZStandard compression
> -
>
> Key: AVRO-2355
> URL: https://issues.apache.org/jira/browse/AVRO-2355
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Reporter: Scott Carey
>Priority: Major
> Fix For: 1.9.0
>
>
> ZStandard compression should not be released without support for compression 
> level selection.
> Its biggest advantage is the massive range by which you can select the 
> compression level, all while keeping decompression throughput very high.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2360) Java 8 timestamp-millis / timestamp-micros type inconsistency

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía updated AVRO-2360:
---
Priority: Blocker  (was: Critical)

> Java 8 timestamp-millis / timestamp-micros type inconsistency
> -
>
> Key: AVRO-2360
> URL: https://issues.apache.org/jira/browse/AVRO-2360
> Project: Apache Avro
>  Issue Type: Bug
>  Components: java
>Affects Versions: 1.9.0
> Environment: JDK 11.0.2 on Linux
>Reporter: Raman Gupta
>Priority: Blocker
>
> I am trying the new JSR 310 date/time types with a snapshot of 1.9.0.
> I see what seems to be an inconsistency. If I generate my code with a logical 
> type of "timestamp-millis", then the code is generated with `Instant`, as 
> expected. However, on JDK11 on Linux, if I do `Instant.now()` the Instant 
> value created contains microseconds. When setting this Instant on an instance 
> of the generated Avro SpecificRecord, I am unable to round-trip the data:
> Before serialization to bytes:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665308Z
> After serializing to bytes, and then back into a specific record the 
> microseconds are now truncated:
> System.out.println(mySpecificRecord.tsMillis()) // 2019-03-27T23:16:09.665Z
> I believe the compiler should generate a class that truncates the 
> microseconds at `setter` time for "timestamp-millis", so that the value 
> before serialization, and after deserialization, are the same. This can be 
> done with a call to the method `truncatedTo(ChronoUnit.MILLIS)`.
> Another, possibly related, oddity is that the "timestamp-micros" type 
> generates a class with `long` as the type of the field. Since Instant can 
> support both milli and micro-second precision, I don't see the reason for 
> this behavior.
> Followup on AVRO-2079.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #625

[Apache Jenkins Server]

See 

Changes:

[dan] AVRO-2355 [java] Add level and checksum options to ZStandard compression

--
[...truncated 250.72 KB...]
[INFO] Running org.apache.avro.tool.TestConcatTool
[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.486 s 
- in org.apache.avro.tool.TestConcatTool
[INFO] Running org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.91 s 
<<< FAILURE! - in org.apache.avro.tool.TestSpecificCompilerTool
[ERROR] 
testCompileSchemaTwoFiles(org.apache.avro.tool.TestSpecificCompilerTool)  Time 
elapsed: 0.712 s  <<< FAILURE!
org.junit.ComparisonFailure: Found file: 
target/compiler/output/avro/examples/baseball/Position.java does not match 
expected file: src/test/compiler/output/Position.java expected:<...ublic enum 
Position [implements org.apache.avro.generic.GenericEnumSymbol {  P, 
C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClassSchema() { return SCHEMA$; }  
public org.apache.avro.Schema get]Schema() { return SC...> but was:<...ublic 
enum Position [{  P, C, B1, B2, B3, SS, LF, CF, RF, DH  ;  public static final 
org.apache.avro.Schema SCHEMA$ = new 
org.apache.avro.Schema.Parser().parse("{\"type\":\"enum\",\"name\":\"Position\",\"namespace\":\"avro.examples.baseball\",\"symbols\":[\"P\",\"C\",\"B1\",\"B2\",\"B3\",\"SS\",\"LF\",\"CF\",\"RF\",\"DH\"]}");
  public static org.apache.avro.Schema getClass]Schema() { return SC...>
at org.junit.Assert.assertEquals(Assert.java:115)
at 
org.apache.avro.tool.TestSpecificCompilerTool.assertFileMatch(TestSpecificCompilerTool.java:121)
at 
org.apache.avro.tool.TestSpecificCompilerTool.testCompileSchemaTwoFiles(TestSpecificCompilerTool.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at 
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at 
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBo

[jira] [Commented] (AVRO-2355) Add compressionLevel to ZStandard compression

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803863#comment-16803863
 ] 

ASF subversion and git services commented on AVRO-2355:
---

Commit d81bffd41c348d8ffe11506fe26c66c58a37a580 in avro's branch 
refs/heads/master from Scott Carey
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=d81bffd ]

AVRO-2355 [java] Add level and checksum options to ZStandard compression


> Add compressionLevel to ZStandard compression
> -
>
> Key: AVRO-2355
> URL: https://issues.apache.org/jira/browse/AVRO-2355
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: java
>Reporter: Scott Carey
>Priority: Major
> Fix For: 1.9.0
>
>
> ZStandard compression should not be released without support for compression 
> level selection.
> Its biggest advantage is the massive range by which you can select the 
> compression level, all while keeping decompression throughput very high.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (AVRO-2144) 404 - Not found - Invalid Url for CSharp documentation

[Nandor Kollar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nandor Kollar resolved AVRO-2144.
-
   Resolution: Fixed
Fix Version/s: 1.9.0

> 404 - Not found - Invalid Url for CSharp documentation
> --
>
> Key: AVRO-2144
> URL: https://issues.apache.org/jira/browse/AVRO-2144
> Project: Apache Avro
>  Issue Type: Bug
>  Components: doc
>Affects Versions: 1.8.2
>Reporter: Selva Chinnasamy
>Assignee: Selva Chinnasamy
>Priority: Minor
> Fix For: 1.9.0
>
>
> Invalid Url for C# Api documentation
> Selecting the below link
> [C# API|http://avro.apache.org/docs/current/api/csharp/index.html]
> leads to 404. Below is the current result:
> h1. Not Found
> The requested URL /docs/current/api/csharp/index.html was not found on this 
> server.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Build failed in Jenkins: AvroJava #624

[Apache Jenkins Server]

See 

Changes:

[iemejia] AVRO-2356: Encoder Cannot Be Null

--
[...truncated 252.76 KB...]
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ avro-maven-plugin ---
[INFO] 
[INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ 
avro-maven-plugin ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ 
avro-maven-plugin ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 6 source files to 

[INFO] 
:
 

 uses unchecked or unsafe operations.
[INFO] 
:
 Recompile with -Xlint:unchecked for details.
[INFO] 
[INFO] --- spotless-maven-plugin:1.20.0:check (spotless-check) @ 
avro-maven-plugin ---
[INFO] 
[INFO] --- maven-plugin-plugin:3.6.0:descriptor (default-descriptor) @ 
avro-maven-plugin ---
[INFO] Using 'UTF-8' encoding to read mojo source files.
[INFO] java-javadoc mojo extractor found 5 mojo descriptors.
[INFO] java-annotations mojo extractor found 0 mojo descriptor.
[INFO] 
[INFO] --- maven-bundle-plugin:4.1.0:manifest (bundle-manifest) @ 
avro-maven-plugin ---
[WARNING] Ignoring project type maven-plugin - supportedProjectTypes = [bundle]
[INFO] 
[INFO] --- maven-resources-plugin:3.1.0:testResources (default-testResources) @ 
avro-maven-plugin ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 8 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ 
avro-maven-plugin ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 7 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ 
avro-maven-plugin ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running org.apache.avro.mojo.TestSchemaMojo
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.991 s 
- in org.apache.avro.mojo.TestSchemaMojo
[INFO] Running org.apache.avro.mojo.TestProtocolMojo
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.204 s 
- in org.apache.avro.mojo.TestProtocolMojo
[INFO] Running org.apache.avro.mojo.TestInduceMojo
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.179 s 
- in org.apache.avro.mojo.TestInduceMojo
[INFO] Running org.apache.avro.mojo.TestIDLProtocolMojo
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.367 s 
- in org.apache.avro.mojo.TestIDLProtocolMojo
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] --- maven-checkstyle-plugin:3.0.0:check (checkstyle-check) @ 
avro-maven-plugin ---
[INFO] Starting audit...
Audit done.
[INFO] 
[INFO] --- maven-jar-plugin:3.1.1:jar (default-jar) @ avro-maven-plugin ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-plugin-plugin:3.6.0:addPluginArtifactMetadata 
(default-addPluginArtifactMetadata) @ avro-maven-plugin ---
[INFO] 
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ 
avro-maven-plugin ---
[INFO] Skipping because packaging 'maven-plugin' is not pom.
[INFO] 
[INFO] --- maven-jar-plugin:3.1.1:test-jar (default) @ avro-maven-plugin ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
avro-maven-plugin ---
[INFO] Installing 

 to 
/home/jenkins/.m2/repository/org/apache/avro/avro-maven-plugin/1.9.0-SNAPSHOT/avro-maven-plugin-1.9.0-SNAPSHOT.jar
[INFO] Installing 
 to 
/home/jenkins/.m2/repository/org/apache/avro/avro-maven-plugin/1.9.0-SNAPSHOT/avro-maven-plugin-1.9.0-SNAPSHOT.pom
[INFO] Installing 

[jira] [Commented] (AVRO-2356) GenericDatumWriter.write must require encoder to be not null

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803750#comment-16803750
 ] 

Hudson commented on AVRO-2356:
--

FAILURE: Integrated in Jenkins build AvroJava #624 (See 
[https://builds.apache.org/job/AvroJava/624/])
AVRO-2356: Encoder Cannot Be Null (iemejia: 
[https://github.com/apache/avro/commit/8f0eca6990a584707c0cc7690fc1d325803a5287])
* (edit) 
lang/java/avro/src/main/java/org/apache/avro/generic/GenericDatumWriter.java


> GenericDatumWriter.write must require encoder to be not null
> 
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 1.9.0
>
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (AVRO-2356) GenericDatumWriter.write must require encoder to be not null

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía resolved AVRO-2356.

Resolution: Fixed

> GenericDatumWriter.write must require encoder to be not null
> 
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 1.9.0
>
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2356) GenericDatumWriter.write must require encoder to be not null

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía updated AVRO-2356:
---
Summary: GenericDatumWriter.write must require encoder to be not null  
(was: Encoder Cannot Be Null)

> GenericDatumWriter.write must require encoder to be not null
> 
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 1.9.0
>
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AVRO-2356) Encoder Cannot Be Null

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803724#comment-16803724
 ] 

ASF subversion and git services commented on AVRO-2356:
---

Commit 8f0eca6990a584707c0cc7690fc1d325803a5287 in avro's branch 
refs/heads/master from Beluga Behr
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=8f0eca6 ]

AVRO-2356: Encoder Cannot Be Null


> Encoder Cannot Be Null
> --
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.9.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2356) Encoder Cannot Be Null

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía updated AVRO-2356:
---
Fix Version/s: 1.9.0

> Encoder Cannot Be Null
> --
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 1.9.0
>
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (AVRO-2356) Encoder Cannot Be Null

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AVRO-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismaël Mejía updated AVRO-2356:
---
Affects Version/s: (was: 1.9.0)

> Encoder Cannot Be Null
> --
>
> Key: AVRO-2356
> URL: https://issues.apache.org/jira/browse/AVRO-2356
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
>
> I was recently doing some debugging and writing tests for Avro and I received 
> the following stack trace:
> {code}
> java.lang.NullPointerException: null of E in field f of R
>   at 
> org.apache.avro.generic.GenericDatumWriter.npe(GenericDatumWriter.java:147)
>   at 
> org.apache.avro.generic.GenericDatumWriter.writeWithoutConversion(GenericDatumWriter.java:141)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:77)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:64)
> {code}
> That took me quite awhile to decipher.  How about me Avro a library for 
> laypeople.  I propose:
> {code}
> java.lang.NullPointerException: Encoder cannot be null
>   at java.util.Objects.requireNonNull(Objects.java:228)
>   at 
> org.apache.avro.generic.GenericDatumWriter.write(GenericDatumWriter.java:63)
>   at 
> org.apache.avro.test.basic.ExtendedEnumPerf.encode(ExtendedEnumPerf.java:26)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)