<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 08:52:07 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[JAVA-366] BSON decoding compiles Java Pattern instances: this is error prone and bad for performance</title>
                <link>https://jira.mongodb.org/browse/JAVA-366</link>
                <project id="10006" key="JAVA">Java Driver</project>
                    <description>&lt;p&gt;In BasicBSONCallback.gotRegEx, Pattern.compile is called on the regular expression that was stored in the BSON structure.&lt;/p&gt;

&lt;p&gt;There are two problems with this:&lt;/p&gt;

&lt;p&gt;1) JavaScript regular expression are not equivalent to Java regular expressions. This means that it is possible that this Pattern.compile would throw a PatternSyntaxException. (Which is not handled here!) This can be very bad, because it would mean that certain MongoDB documents that contain such regular exceptions would simply be un-retrievable via the Java driver.&lt;/p&gt;

&lt;p&gt;2) Pattern.compile is slow, and would currently be done for every single regular expression encountered by the Java driver. However, in many cases the user does not care to &lt;b&gt;use&lt;/b&gt; the compiled regular expression as a Pattern instance, and is only interested in the string content of it. This slow regex compilation is thus superfluous.&lt;/p&gt;

&lt;p&gt;My recommendation is to have a new dedicated class for BSON regular expressions: org.bson.types.RegExp. This class would not normally compile the pattern into a Java Pattern, however it could offer a compile() method to attempt to do this compilation for users who want to use this pattern, with the documented caveat that they might get a PatternSyntaxException if the regular expression is not compatible with Java. (In which case they may want to use Rhino to handle the regular expression.)&lt;/p&gt;

&lt;p&gt;I posted something similar to this to the MongoDB mailing list, and was told that &quot;most users would prefer to use Pattern.&quot; Well, OK for them, not great for users like me who do not want breakage or pay performance costs for a feature they do not use. May I suggest that this could be controlled with a flag? The code would look something like this:&lt;/p&gt;

&lt;p&gt;public void gotRegex( String name , String pattern , String flags ) {&lt;br/&gt;
  RegExp bsonRegExp = new RegExp(pattern , BSON.regexFlags(flags)); // This class does not compile the pattern, simply stores it&lt;br/&gt;
 _put(name, compileRegExpFlag ? bsonRegExp.compile() : bsonRegExp); // The compile() method returns a Java Pattern (though it may throw an exception)&lt;br/&gt;
}&lt;/p&gt;</description>
                <environment></environment>
        <key id="17809">JAVA-366</key>
            <summary>BSON decoding compiles Java Pattern instances: this is error prone and bad for performance</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="4" iconUrl="https://jira.mongodb.org/images/icons/priorities/minor.svg">Minor - P4</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="tal.liron">Tal Liron</reporter>
                        <labels>
                    </labels>
                <created>Thu, 2 Jun 2011 16:23:28 +0000</created>
                <updated>Tue, 31 Mar 2015 20:10:13 +0000</updated>
                            <resolved>Fri, 13 Jun 2014 16:10:55 +0000</resolved>
                                    <version>2.6.1</version>
                                    <fixVersion>3.0.0</fixVersion>
                                    <component>API</component>
                                        <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                <comments>
                            <comment id="869561" author="jeff.yemin" created="Tue, 31 Mar 2015 20:10:13 +0000"  >&lt;p&gt;Closing all resolved 3.0.0 issues, as 3.0.0 has been tagged and released.&lt;/p&gt;</comment>
                            <comment id="615956" author="jeff.yemin" created="Tue, 10 Jun 2014 18:48:51 +0000"  >&lt;p&gt;So as not to break binary compatibility, the default behavior of decoding to a java.util.Pattern will have to remain.&lt;/p&gt;

&lt;p&gt;We will fix this for new users with the introduction of the org.bson.types.RegularExpression, to be used with the new Document class that will serve as a replacement for DBObject.&lt;/p&gt;</comment>
                            <comment id="35834" author="tal.liron" created="Thu, 2 Jun 2011 21:34:24 +0000"  >&lt;p&gt;I agree with you that a RegExp BSON type does not seem necessary. However, it is part of the BSON spec and it is supported by the Java driver. We don&apos;t want broken code in it, do we? It seems like it would be easy to solve. I did set the bug priority on &quot;low.&quot; &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.mongodb.org/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;

&lt;p&gt;I do not personally have an application that uses this, but I am the developer of the Rhino driver for MongoDB, which sits on top of the Java driver, and it also supports RegExp. In writing the unit tests I discovered this part of the code that did not seem right to me.&lt;/p&gt;</comment>
                            <comment id="35832" author="antoine" created="Thu, 2 Jun 2011 21:29:53 +0000"  >&lt;p&gt;I see your point, but so far very few people have actually stored regexp natively in documents.&lt;br/&gt;
regexp are usually only used in queries to the server.&lt;br/&gt;
For storage, you may as well use regular strings that represent a regexp.&lt;br/&gt;
Do you have a use case?&lt;br/&gt;
thx&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                        <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10011"><![CDATA[Minor Change]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrfcyn:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1973</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10557" key="com.pyxis.greenhopper.jira:gh-sprint">
                        <customfieldname>Sprint</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue id="161">Sprint 2 - May 5 - May 23</customfieldvalue>
    <customfieldvalue id="185">Sprint 3 - May 27 - June 13</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>