-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix 2701 too may files found #2732
Fix 2701 too may files found #2732
Conversation
-- this fixes incorrect match of multiple files caused by a (masked) "null pointer exception".
Thank you very much for your contribution 👍 . Codewise it looks very good to me. If the test passes and another dev gives his okay, we can merge it. |
Thanks for the contribution @sauliusg . Great, when users find an issue and even fix it themselves (;
I will investigate this tomorrow, because I'm not entirely sure if your fix solves the symptoms or we should dig a bit deeper and eliminate the main problem, which could be that bloody 'null' database. |
second 'if' branch in the 2701 fix.
Dear Siedlerchr, dear Lynyus, thank you for the instant reply! I have got feedback from Codacy and fixed: removed an unused variable from the new unit test. Also, I added another second unit test to cover the second 'if' statement added by me. Sorry if it breaks the "changes approved" status...
Please have a look. It seems to me that the 'null' can be traced to the explicit 'null' argument passed to it from the 'private static List findFile(BibEntry entry, File directory, String file, String extensionRegExp, Character keywordDelimiter)' method (line 250, String filenameToLookFor = expandBrackets(filePart, entry, null, keywordDelimiter).replaceAll(EXT_MARKER, extensionRegExp);). Regards, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say, that the call structure of this functionality should be refactored.
There are two calls in https://github.com/JabRef/jabref/blob/master/src/main/java/org/jabref/logic/util/io/RegExpFileSearch.java
that use null
as argument for the database in expandBrackets()
. (Line 195 and 250)
I would argue that we thus need two expandBrackets()
methods, one that uses a database argument, and one that doesn't.
Naturally, this cascades and several called methods have to be changed as well, but it would improve the code w.r.t. extensibility and we would not need to write such workarounds as @sauliusg did. (Which indeed would fix the problem, though)
@tobiasdiez What do you think about this?
@lynyus your suggestions sounds reasonable. We should try to not pass null as an argument. Moreover, the label generation code probably needs a complete refactoring (especially, get rid of the huge amount of static methods). But this will be probably a bigger project. While I would welcome PRs from you or @sauliusg in this direction, I think the current PR is an acceptable workaround within the boundaries of the current code infrastructure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just two minor remarks and then this can be merged in my opinion.
@Test | ||
public void makeLabelForFileSearch() { | ||
String label = BibtexKeyPatternUtil.makeLabel(entry, | ||
/*value=*/ "auth", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we never used comments to indicate the name of the argument and thus would prefer that you remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, indicating “Named Function Parameter” Comments is a recommended practice from the Dustin Boswell, Trevor Foucher "The Art of Readable Code", for languages that do not support named parameters. I personally find such code easier to read. But if this is not used on JabRef and you do not find them useful, then, sure, please just remove them. Should I make the requested changes and recommit, or will you handle these issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, both issues fixed, please find a new push.
|
||
public class MakeLabelWithoutDatabaseTest { | ||
|
||
// private GlobalBibtexKeyPattern pattern; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use remove the unused variable completely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this var will probably never be needed.
MakeLabelWithoutDatabaseTest.java, since IntelliJ handles them automagically.
Okay, lgtm! I merge it in! Thank you very much for your contribution! 👍 Feel free to take a look at other issues |
Thanks! |
* upstream/master: Speedup start by improving Application Insights configuration (#2737) Localization: French: Menu: Translation of new entries (#2735) Localization: French: General: Translation of new entries (#2736) Update Chinese translation. (#2734) Fix 2701 too may files found (#2732) Update errorprone from 0.0.8 to 0.0.10, because of update of Gradle to 3.5 Update gradle from 3.4.1 to 3.5
I would like to offer my fix for the issue 2701: JabRef would find too many files when they are search with the [year]_[auth].* pattern. The reason seems to be a 'null' database passed to the BibtexKeyPatternUtil.makeLabel(BibEntry, String, Character, BibDatabase) method, and a null pointer exception is triggered. As a result, the '[auth]' part of the pattern was erased and ignored. With the suggested fix, JabRef uses the '[auth]' part of the pattern and finds just the files with the matching author, as expected. A relevant unit test was added; no other tests were broken.
gradle localizationUpdate
? -- no localisation changes.