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_r349570247
########## 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 { Review comment: I think all 3 solutions (member, abstract superclass, trait interface) have their pros and cons. In my opinion the trait interface is the best usually, but it's hard to tell. In this case probably the abstract superclass wins out. **Member (composition)** Pros - Can be reused - Further abstraction and extension not limited - Proper isolation - State code can be written once Cons - More glue code (plus one field, instantiation, data transfer) - Need to make sure states are properly set up in order. (Must not reference the member before it's set up properly. Can be mitigated if immutable/stateless.) **Abstract superclass (Regular inheritance)** Pros - Least amount of glue code - Proper isolation - State setup is usually not an issue - State code can be written once - State can be accessed anywhere Cons - Reusability it very restricted (probably not an issue in this case) - Restricts further abstraction and extension **Trait interface (Behavioural inheritance)** Pros - Minimal/Least amount of glue code - Can be reused - Further abstraction and extension not limited - No issues with state Cons - Isolation is very poor (everything is public) - Can't have state (although can be mitigated by defining and referencing accessors) All in all, abstract superclasses have their well-known issues. Trait interfaces are basically composition 2.0 except Java doesn't really implement this concept very well. The thing is, no matter the use-case, these issues with the trait interfaces will be there. So we basically either accept them with their flaws as a viable approach or never use them at all. I think the cons are not that bad. However in this case adding another classloader superclass fits in the existing picture well so I'll go with that. ---------------------------------------------------------------- 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
