This means that the TypeDescriptors don't match. It could be something
weird with the Int type, or it could be Kotlin not propagating the generic
type parameters of the DoFn.
On Thu, May 28, 2020 at 8:03 AM Rion Williams wrote:
> Hi Reuvan,
>
> Here's the complete stack trace:
>
> Exception in
Hi Reuvan,
Here's the complete stack trace:
Exception in thread "main" java.lang.IllegalArgumentException: Type of @Element
must match the DoFn typeCreate.Values/Read(CreateSource).out [PCollection]
at
org.apache.beam.sdk.transforms.ParDo.getDoFnSchemaInformation(ParDo.java:601)
It could also be that Kotlin is defeating Beam's type analysis, if it
changes type-parameter ordering for example. It may also be that the
TypeToken framework we use for analyzing Java types isn't working properly
on these Kotlin types.
On Wed, May 27, 2020 at 1:27 PM Reuven Lax wrote:
> Do you
Do you have the full stack trace from that exception?
On Wed, May 27, 2020 at 1:13 PM Rion Williams wrote:
> Correct, Kotlin uses an Int type as opposed to Java’s integer, however in
> this case I had assumed that since the PCollection being constructed and
> used by the DoFn both use the same
Correct, Kotlin uses an Int type as opposed to Java’s integer, however in this
case I had assumed that since the PCollection being constructed and used by the
DoFn both use the same Kotlin Int type that it would be able to bind properly
(even when explicitly typing the Create to use the Kotlin
I'm assuming that Kotlin has its own type for Int, which is not the same as
Java's Integer type.
On Fri, May 22, 2020 at 8:19 AM Rion Williams wrote:
> Hi all,
>
> I was writing a very simple transform in Kotlin as follows that takes in a
> series of integers and applies a simply DoFn against
Hi all,
I was writing a very simple transform in Kotlin as follows that takes in a
series of integers and applies a simply DoFn against them:
pipeline
.apply(Create.of(1, 2, 3))
.apply(ParDo.of(object: DoFn(){
@ProcessElement
fun
