You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Richard von Keyserling (JIRA)" <mi...@james.apache.org> on 2010/03/04 20:39:27 UTC
[jira] Created: (MIME4J-174) Refactor org.mime4j.util.CharsetUtil
to lazily determine supported encodings/decodings
Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
--------------------------------------------------------------------------------------
Key: MIME4J-174
URL: https://issues.apache.org/jira/browse/MIME4J-174
Project: JAMES Mime4j
Issue Type: Improvement
Reporter: Richard von Keyserling
On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MIME4J-174) Refactor org.mime4j.util.CharsetUtil
to lazily determine supported encodings/decodings
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841528#action_12841528 ]
Stefano Bagnara commented on MIME4J-174:
----------------------------------------
Forgot to say that patches are welcome :-)
> Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
> --------------------------------------------------------------------------------------
>
> Key: MIME4J-174
> URL: https://issues.apache.org/jira/browse/MIME4J-174
> Project: JAMES Mime4j
> Issue Type: Improvement
> Reporter: Richard von Keyserling
>
> On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
> Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MIME4J-174) Refactor
org.mime4j.util.CharsetUtil to lazily determine supported
encodings/decodings
Posted by "Richard von Keyserling (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842881#action_12842881 ]
Richard von Keyserling edited comment on MIME4J-174 at 3/9/10 4:19 AM:
-----------------------------------------------------------------------
Attached a patch for http://svn.apache.org/repos/asf/james/mime4j/tags/apache-mime4j-0.6 with the suggested refactoring to lazily determine supported encodings/decodings in CharsetUtil.java.
was (Author: rvonkeys):
This is a patch for http://svn.apache.org/repos/asf/james/mime4j/tags/apache-mime4j-0.6 with the suggested refactoring to lazily determine supported encodings/decodings in CharsetUtil.java.
> Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
> --------------------------------------------------------------------------------------
>
> Key: MIME4J-174
> URL: https://issues.apache.org/jira/browse/MIME4J-174
> Project: JAMES Mime4j
> Issue Type: Improvement
> Reporter: Richard von Keyserling
> Attachments: charset_util_refactor.diff
>
>
> On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
> Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MIME4J-174) Refactor org.mime4j.util.CharsetUtil
to lazily determine supported encodings/decodings
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-174.
------------------------------------
Resolution: Fixed
Fix Version/s: 0.7
Assignee: Stefano Bagnara
Committed, thanx.
> Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
> --------------------------------------------------------------------------------------
>
> Key: MIME4J-174
> URL: https://issues.apache.org/jira/browse/MIME4J-174
> Project: JAMES Mime4j
> Issue Type: Improvement
> Reporter: Richard von Keyserling
> Assignee: Stefano Bagnara
> Fix For: 0.7
>
> Attachments: charset_util_refactor.diff
>
>
> On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
> Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MIME4J-174) Refactor org.mime4j.util.CharsetUtil
to lazily determine supported encodings/decodings
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841527#action_12841527 ]
Stefano Bagnara commented on MIME4J-174:
----------------------------------------
Linking this one to MIME4J-159 as this issue is probably fixed moving to java5 Charset methods.
> Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
> --------------------------------------------------------------------------------------
>
> Key: MIME4J-174
> URL: https://issues.apache.org/jira/browse/MIME4J-174
> Project: JAMES Mime4j
> Issue Type: Improvement
> Reporter: Richard von Keyserling
>
> On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
> Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MIME4J-174) Refactor org.mime4j.util.CharsetUtil
to lazily determine supported encodings/decodings
Posted by "Richard von Keyserling (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard von Keyserling updated MIME4J-174:
------------------------------------------
Attachment: charset_util_refactor.diff
This is a patch for http://svn.apache.org/repos/asf/james/mime4j/tags/apache-mime4j-0.6 with the suggested refactoring to lazily determine supported encodings/decodings in CharsetUtil.java.
> Refactor org.mime4j.util.CharsetUtil to lazily determine supported encodings/decodings
> --------------------------------------------------------------------------------------
>
> Key: MIME4J-174
> URL: https://issues.apache.org/jira/browse/MIME4J-174
> Project: JAMES Mime4j
> Issue Type: Improvement
> Reporter: Richard von Keyserling
> Attachments: charset_util_refactor.diff
>
>
> On initialization CharsetUtil determines all supported endcodings and decodings by attempting to encode and decode a dummy string with every entry in JAVA_CHARSETS. This loads a lot of classes into the JVM which in turn uses up a lot of permGen.
> Moving the decoding and encoding tests into isDecodingSupported() and isEncodingSupported() and adding positive results to the decodingSupported and encodingSupported treeSets from those methods would allow the class to only load encoders and decoders the application needs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.