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 type).

When doing the same thing with Kotlin Strings, the @Element attribute works as 
expected, so I don’t know if this is an issue purely related to underlying type 
conversions with numeric Kotlin types and what’s the best way to handle this? I 
know using the ProcessContext works just as you’d expect, however for simple 
transforms the @Element approach can be a bit easier to grok.

> On May 27, 2020, at 3:01 PM, Reuven Lax <re...@google.com> wrote:
> 
> 
> 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 <rionmons...@gmail.com> 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 them:
>> 
>> pipeline
>>             .apply(Create.of(1, 2, 3))
>>             .apply(ParDo.of(object: DoFn<Int, Int>(){
>>                     @ProcessElement
>>                     fun processElement(@Element element: Int){
>>                         // Omitted for brevity
>>                     }
>>                 })
>>             )
>> 
>> The issue seems to arise when we use the `@Element` attribute on the element 
>> which fails with the following error:
>> 
>> Exception in thread "main" java.lang.IllegalArgumentException: Type of 
>> @Element must match the DoFn typeCreate.Values/Read(CreateSource).out 
>> [PCollection]
>> 
>> Basically, it seems that the use of the `@Element` attribute isn't able to 
>> properly decode or recognize the Kotlin `Int`, however if we adjust the DoFn 
>> to instead use the ProcessContext argument, which is able to resolve the 
>> element via `context.element()`.
>> 
>> Is there anything that seems wrong here? I'd imagine that this should just 
>> "work", or maybe there's some specific configuration that I might be missing 
>> as this is the first Kotlin issue that I've encountered when interacting 
>> with Beam.
>> 
>> I'll be happy to provide any additional details for this if needed.
>> 
>> Thanks,
>> 
>> Rion
>> 

Reply via email to