Created attachment 70422 [details]
Stacktraces

LanguagesEditorKit comes from Schliemann so I'll let Hanz comment on that one.

The yaml EmbeddingSectionsHighlightingFactory is created because the editor initializes all highlighting factories near
startup. We've discussed this before; this class is reasonably new (for the YAML support) which is why it's showing up
now, but I believe it should be whitelisted.

RubyEmbeddingModel gets loaded because there is an attempt to parse an embedded file (such as a PHP file). In this case,
GSF needs to find an embedding model capable of going from ${source mime type} to ${target mime type}. It does a lookup
on EmbeddingModel to find all the translators. RubyEmbeddingModel is one of them. Arguably, we could use some sort of
mimetype (mime) lookup to declare these things by mimetype in the layer instead - but that isn't done now; instead all
EmbeddingModel implementations are registered in the services/ folder and located using Lookup.

YamlLanguage is loaded because the tasklist is open. The tasklist description takes its name from the registered
languages - thus it iterates over the language names. (This means for example that in the Ruby-only IDE, the task
provider will say "Ruby Hints", whereas in the full IDE it will say something like "Ruby, PHP, Groovy hints". The
display name is provided by the language config object. This could also be converted to a declarative registration in
the layer name.

I suspect the RubyEmbeddingModel class load was fixed by Martin's fix of issue 148179.

The highlighting factory class loading is done by the editor (and it's a known issue that it initializes all
highlighting containers, there is nothing yaml specific about this.)

The YamlLanguage class is loaded because the tasklist is open, which means the YAML filter is enabled and the display
name is called. This cannot be easily fixed in 6.5.

That leaves the LanguagesEditorKit$EditorSettings class. Since that's unrelated to the languages.yaml support I will
reassign this issue for Hanz to evaluate that specific class. The other classes have been evaluated and this issue can
have its milestone set to "future" when Hanz is done (assuming there is nothing to be done about that specific class).

Yes, but one class is still being loaded:
    org.netbeans.modules.languages.yaml.YamlLanguage

Created attachment 71195 [details]
Stacktrace

LanguagesEditorKit$EditorSettings (instance of StorageFilter) is registered in Meta-inf/services in top level lookup.
So, it must be loaded.

Comment from jtulach: "No justifiable reason to load YamlLanguage class exists."

The following classes are loaded again with 081201:

org.netbeans.modules.languages.dataobject.LanguagesEditorKit$EditorSettings
org.netbeans.modules.languages.yaml.EmbeddedSectionsHighlighting$Factory

Is this still a problem?

I don't think so, AFAIK languages.yaml no longer uses Schliemann framework. IMO it can be closed.

OK, thanks -- I'm closing this then.