[
https://issues.apache.org/jira/browse/STREAMS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14324813#comment-14324813
]
ASF GitHub Bot commented on STREAMS-288:
----------------------------------------
Github user steveblackmon commented on the pull request:
https://github.com/apache/incubator-streams/pull/187#issuecomment-74744716
So this is just a performance concern? I agree that creating a new Mapper
inside of a loop is obviously a bad idea. That's why :
public class StreamsJacksonMapper extends ObjectMapper {
private static final StreamsJacksonMapper INSTANCE = new
StreamsJacksonMapper();
public static StreamsJacksonMapper getInstance(){ return INSTANCE;
}
Get your mapper this way and only once and problem solved.
I don't think the fact that bad implementations can get slow is a reason to
make the default behavior worse, to make a call that should only happen once
per jvm a bit faster.
> StreamsJacksonModule should not scan for DateTimeFormats by default
> -------------------------------------------------------------------
>
> Key: STREAMS-288
> URL: https://issues.apache.org/jira/browse/STREAMS-288
> Project: Streams
> Issue Type: Bug
> Reporter: Robert Douglas
>
> The StreamsJacksonModule's constructor is called all over the codebase and by
> default, it uses Reflections to scan the classpath for valid DateTimeFormats.
> This is problematic because it will happen multiple times during a Stream's
> runtime, considerably slowing down the execution.
> Instead, we should default to NOT scanning the classpath, but provide a
> constructor where we can pass in a flag dictating whether or not we want to
> scan.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
