Hello Emilian, Thanks for your analysis , and new ideas ! Can you clarify: => "The only downside is we have to think about older external JARs that expect the current behaviour. We could use some flag (in MANIFEST perhaps?) to differentiate between them."
=> "many calls of ClassFinder do some filtering, excluding some implementations. This would be simple by just not registering those implementations as a service." My 2 cents with current (partial ?) understanding of your proposal: - The backward compatibility with 3rd party plugins is a critical part. IMO, no change should be made before validating new proposal will work with most popular existing 3rd plugins. - Another critical part is to make it as easy as today to register a plugin which is IMO one of the major reasons for JMeter success. Thanks On Wed, Jul 19, 2017 at 2:16 AM, Emilian Bold <[email protected]> wrote: > Hello, > > I noticed ClassFinder while tweaking ActionRouter and I believe it should > be replace with a proper service declaration and loading. > > I'm a fan of the Lookup API (see [1] [2]) which is a small standalone JAR > used a lot in NetBeans. > > The standard ServiceLoader [3] would also be a better replacement. > > Some remarks: > > * ClassFinder is almost always called with JMeterUtils.getSearchPaths(). > This must be expected to be the class path actually. > * many calls of ClassFinder do some filtering, excluding some > implementations. This would be simple by just not registering those > implementations as a service. > > With the ServiceLoader, ActionRouter would load commands with something > like: > > > ServiceLoader<Command> commands = ServiceLoader.load(Command.class); > > An each command will have to be registered in META-INF/services (for Java > 8) or in the module declaration (for Java 9). > > In NetBeans we have an annotation @ServiceProvider [4] which is simpler and > behind the scenes the build system generates at build time the > META-INF/services registration file. > > Note that service registration and loading would work the same for 3rd > party JARs. > > The only downside is we have to think about older external JARs that expect > the current behaviour. We could use some flag (in MANIFEST perhaps?) to > differentiate between them. > > 1. > http://bits.netbeans.org/8.0/javadoc/org-openide-util- > lookup/org/openide/util/Lookup.html > 2. > http://bits.netbeans.org/8.0/javadoc/org-openide-util- > lookup/org/openide/util/lookup/doc-files/lookup-api.html > 3. http://download.java.net/java/jdk9/docs/api/java/util/ > ServiceLoader.html > 4. > http://bits.netbeans.org/8.0/javadoc/org-openide-util- > lookup/org/openide/util/lookup/ServiceProvider.html > > --emi > -- Cordialement. Philippe Mouawad.
