You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that there is a whole bunch of case classes copied between com.ing.baker.runtime.scaladsl and com.ing.baker.runtime.javadsl.
The only difference seems to be the use of Scala's Option vs Java's Optional.
You could get rid of that by adding a companion object to every case class with a fromJava (or differently named) method which takes Optional arguments but constructs the Scala class with an Option. The corresponding Java getter method could convert back to an Optional.
Example:
/** * Event describing the fact that an event was received for a process. * * @paramtimeStamp The time that the event was received * @paramrecipeName The name of the recipe that interaction is part of * @paramrecipeId The recipe id * @paramrecipeInstanceId The id of the process * @paramcorrelationId The (optional) correlation id of the event * @paramevent The event*/caseclassEventReceived(timeStamp: Long,
recipeName: String,
recipeId: String,
recipeInstanceId: String,
correlationId: Option[String],
event: EventInstance) extendsBakerEventwith common.EventReceived {
defgetTimeStamp:Long= timeStamp
defgetRecipeName:String= recipeName
defgetRecipeId:String= recipeId
defgetRecipeInstanceId:String= recipeInstanceId
defgetCorrelationId:Optional[String] =Optional.ofNullable(correlationId.orNull)
defgetEvent:EventInstance= event
}
objectEventReceived {
deffromJava(timeStamp: Long,
recipeName: String,
recipeId: String,
recipeInstanceId: String,
correlationId: Optional[String],
event: EventInstance
) =newEventReceived(
timeStamp,
recipeName,
recipeId,
recipeInstanceId,
if (correlationId.isPresent) Some(correlationId.get) elseNone,
event: EventInstance
)
}
The same thing would also work the other way round.
This approach would have a minor performance impact for converting back and forth between Option and Optional, but I would assume this is negligible under real-life scenarios.
If this is desirable, I could create a corresponding PR.
Let me know what you think!
The text was updated successfully, but these errors were encountered:
I noticed that there is a whole bunch of
case class
es copied betweencom.ing.baker.runtime.scaladsl
andcom.ing.baker.runtime.javadsl
.The only difference seems to be the use of Scala's
Option
vs Java'sOptional
.You could get rid of that by adding a companion object to every case class with a
fromJava
(or differently named) method which takesOptional
arguments but constructs the Scala class with anOption
. The corresponding Java getter method could convert back to anOptional
.Example:
The same thing would also work the other way round.
This approach would have a minor performance impact for converting back and forth between
Option
andOptional
, but I would assume this is negligible under real-life scenarios.If this is desirable, I could create a corresponding PR.
Let me know what you think!
The text was updated successfully, but these errors were encountered: