-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Replaced some array return types #1661
Conversation
@@ -315,11 +315,9 @@ private boolean handleDraggedFilenames(String s, final int dropRow) { | |||
* @return success status for the operation | |||
*/ | |||
private boolean handleDraggedFiles(List<File> files, final int dropRow) { | |||
final String[] fileNames = new String[files.size()]; | |||
int i = 0; | |||
final List<String> fileNames = new ArrayList<>(); |
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.
The loop could be replaced with a nice stream/lamda expression:
fileNames = new ArrayList<>(files.stream().map(f->f.getAbsolutePath()).collect(Collectors.toList());
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.
Yes, but I know that some developers not always appreciate these as they are harder to read. Have not really understood when they are preferred.
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 do not think they are harder to read, it is just some novel style, once you get used to it, it is plain simple and makes programming for fluent. In general I would prefer them if it makes sense.
The functional style makes it easier to crate a kind of Collection-pipelline, e.g. introduce a filter, another transformation or limit the results or just replace the collector. And could be easy parallelized, in cases where needed.
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.
I think we do not have a full consensus on this. But I would agree to @Siedlerchr in that case. :)
Except for the remark LGTM 👍 |
* master: Fixed OO/LO manual connection dialog on Linux Removed thrown Exception declarations (JabRef#1673) Fix JabRef#1288 Newly opened bib-file is not focused (JabRef#1671) Refactor DB loading Fix OutOfBoundsException when importing multiple entries in medline format (JabRef#1611) Removed the possibility to auto show or hide the groups interface (JabRef#1668) Add test to describe workaround for JabRef#1633 Fixed JabRef#1643: Searching with double quotes in a specific field ignores the last character fix build Fixes JabRef#1554: JabRefFrame is set as owner for ImportInspectionDialog Fixed most of the ErrorProne warnings Replaced output of getResolvedField to Optional<String> (JabRef#1650) PushToApplication cleanup and refactoring (JabRef#1659) Replaced Object with appropriate class where possible (JabRef#1660) Replaced some array return types (JabRef#1661) Fix XMP test Localization Moved the main part of XMPUtil to jabref.XMPUtilMain and injected a b… (JabRef#1642) Made possible to make the OO/LO panel a bit more narrow (JabRef#1652) French localization: Jabref_fr: empty strings + some cleaning
No description provided.