Github user michalklempa commented on the issue:
https://github.com/apache/nifi/pull/675
@trixpan regarding any "defaultCharset" issues, I guess, that author was
thinking about what Java process sees as the default charset of the system it
runs on. I have seen it couple of times, that Java developers tend to set the
charset (see http://stackoverflow.com/a/31644153). It is mainly because Java
writers let those methods like String.getBytes() to behave not statically ->
said in documentation it will return always UTF-8 transformation to bytes, but
these argless functions behave 'system-dependent' way - Java tries to figure
out the Locale on the system it is running... you know. It causes o lot of
headaches, mainly for Java newbies.
But if NiFi is coded properly, and every such function call is used only in
argument-aware version, default charset is not even used inside JVM at runtime,
nobody simply ask for it by calling Charset.defaultCharset or String.getBytes
or other Java gotchas String>byte manipulation function.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
