public static void test(Vector<metadb_handle> items) {
        for(metadb_handle item : items) {
            file_info_impl finfo = new file_info_impl();
            item.get_info(finfo);
            finfo.meta_set("JAVA", "java");
            _metadb_io.update_info(item, finfo, (int)_mainwin_handle, false);
        }
}

public static void on_playback_new_track(metadb_handle item) {
        file_info_impl finfo = new file_info_impl();
        item.get_info(finfo);
        label.setText(finfo.meta_get("ARTIST", 0) + " - " + finfo.meta_get("TITLE", 0));
}

I was able to do a lot in binding foobar2000 SDK to .NET technology in foo_title. You can take a look at it for inspiration.

The foobar2000 core scans the list of service factories in a component DLL at startup; service factories that are added later on will not be recognized. In theory any service factories that are created before foobar2000_client::get_service_list() returns will be recognized by the core. However to make this work, you cannot use the default implementation of foobar2000_component_client. You would have to make a copy of that library, modify it, and link against the modified library - or just add the modified source file (component_client.cpp) to your project. Unless the dynamically created service factories have member variables that need some clean-up, you don't need to bother about deleting them. Since you component is only unloaded when foobar2000 exits, the memory will be automatically freed by the OS.

This leaves the problem of finding the Java classes for which you need a service factory wrapper. I don't know (yet) how you have currently solved this, but I would try to use a manifest.

Interesting info. At what point is get_sevice_list() called ? After all plugins static global variables (containing factories among other) are initialized ? what need to be modified in component_client.cpp so it can see services created dynamically in let's say, initquit_factory::on_load() ?

So we've got a fb2k_java_api.dll that calls and links with SDK code but is not a plugin ! How can this work then ? It works because it lives in the main foobar thread. So if you try to direclty get services in this DLL, they do not exist, but pointers passed from the real plugin loader dll are valid. It's also passed a pointer to the plugin loader dll main struct containg pointer to the JVM, some static api ptr etc.

Ok, after some testing I understood the modification to make to component_client.cpp to dynamicaly instanciate factories. Now as yo said there's still the issue to find the factories to instanciate but i have some ideas about that.

• The core loads the component DLL using LoadLibrary().
• The core retrieves a pointer to the foobar2000_get_interface() function and calls it to obtain a pointer to the DLL's foobar2000_client object.
• After checking that the component's version is compatible with the core, the core calls foobar2000_client::get_service_list(). It also sets the component DLL's path and sets the stored configuration data (if any).
  
  Side note: The cfg_var mechanism is completely implemented on the component's side. For the core, a component's configuration data is just a block (or stream) of binary data. So in theory you could implement a custom configuration mechanism.
• The main user interface is created. Also the contents of media library and the stored playlists are loaded.
• The core calls initquit::on_init() for all initquit instances (in undefined order).

That sounds like a big headache to me.  Here is an idea you could try: Treat fb2k_java_api.dll as a normal foobar2000 component. However you first load it using System.loadLibrary() to satisfy constraints on the Java side. Then you load it from you wrapper component and initialize it like the core would (see below for a rough outline of the component loading process). fb2k_java_api.dll can then create and use foobar2000 services like any other component.

For future reference, this is how component DLLs are loaded:

• The core loads the component DLL using LoadLibrary().
• The core retrieves a pointer to the foobar2000_get_interface() function and calls it to obtain a pointer to the DLL's foobar2000_client object.
• After checking that the component's version is compatible with the core, the core calls foobar2000_client::get_service_list(). It also sets the component DLL's path and sets the stored configuration data (if any).
  
  Side note: The cfg_var mechanism is completely implemented on the component's side. For the core, a component's configuration data is just a block (or stream) of binary data. So in theory you could implement a custom configuration mechanism.
• The main user interface is created. Also the contents of media library and the stored playlists are loaded.
• The core calls initquit::on_init() for all initquit instances (in undefined order).

class java_main_thread_callback : public main_thread_callback {

public:
    
    void callback_run() {

                callMainJavaThreadCallback();
    
        jvm_ctx->main_thread_cb_manager->add_callback(this);
    }

};

public void mainThreadCallback() {
            while(display.readAndDispatch());
            display.sleep();
    };

public void mainThreadCallback() {
                if(!display.readAndDispatch())
                           display.sleep();
    };