tpalfy commented on a change in pull request #3894: NIFI-6884 - Native library loading fixed/improved URL: https://github.com/apache/nifi/pull/3894#discussion_r349537862
########## File path: nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-nar-utils/src/main/java/org/apache/nifi/nar/NativeLibFinder.java ########## @@ -0,0 +1,159 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.nifi.nar; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import java.io.File; +import java.nio.file.Files; +import java.nio.file.Path; +import java.nio.file.Paths; +import java.util.Arrays; +import java.util.List; +import java.util.Map; +import java.util.Objects; +import java.util.Optional; +import java.util.Set; +import java.util.function.Function; +import java.util.stream.Collectors; + +import static java.nio.file.StandardCopyOption.REPLACE_EXISTING; + +public interface NativeLibFinder { + Logger LOGGER = LoggerFactory.getLogger(NativeLibFinder.class); + + String OS = System.getProperty("os.name").toLowerCase(); + + List<File> getNativeLibDirs(); + + Map<String, Path> getNativeLibNameToPath(); + + String getTmpLibFilePrefix(); + + default Set<File> getUsrLibDirs() { + Set<File> usrLibDirs = Arrays.stream(getJavaLibraryPath().split(File.pathSeparator)) + .map(String::trim) + .filter(pathAsString -> !pathAsString.isEmpty()) + .map(File::new) + .map(toDir()) + .filter(Objects::nonNull) + .collect(Collectors.toSet()); + + return usrLibDirs; + } + + default String getJavaLibraryPath() { + return System.getProperty("java.library.path", ""); + } + + default Function<File, File> toDir() { + return file -> { + if (file.isFile()) { + return file.getParentFile(); + } else if (file.isDirectory()) { + return file; + } else { + return null; + } + }; + } + + default String findLibrary(String libname) { + Path libLocation = getNativeLibNameToPath().compute( Review comment: In fact I have started with the imperative approach and switched to this style for the very reason that I think it's more understandable and more robust. I guess I got used to this style by now. And although I admit this can be abused (and I'm probably guilty of that sometimes), in my opinion, even considering code quality - readability and robustness-, the functional approach has objective advantage over the imperative one: Functional style forces the divide and conquer strategy on the programmer (which is very helpful when dealing with more complex problems). It's about breaking down a process into sequential phases where each phase is separated from the rest (not unlike how NiFi works). One can understand the logic step by step which helps readability and since the steps are completely isolated from each other and the general flow is more declarative the overall code is less prone to bugs. Also it's easier to write a cleaner code imo as the declarative nature imposes boundaries that guides the flow. As I said I started with an imperative approach which had 3 private methods and about twice as much code as this. _Now_ I _can_ write it almost the same way as the current functional style, but only because _now_ I see the near-optimal solution. Nevertheless I'll commit a change with a more traditional code style and leave the current one as an unused method for all to be able to compare. After taking a look at both we can have a final decision which to use. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
