Since JDK-8336856 is integrated, we get the following warning when dumping CDS archive

$ java -Xshare:dump
[0.759s][warning][cds ] Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL: Unsupported location

The reasons is a new $Species_LLLL class is dynamically generated, but CDS can't archive dynamically generated classes.

$ java -Xshare:dump -Xlog:class+load | grep Species
[0.114s][info][class,load] java.lang.invoke.ClassSpecializer$SpeciesData source: jrt:/java.base
[0.114s][info][class,load] java.lang.invoke.BoundMethodHandle$SpeciesData source: jrt:/java.base
[0.114s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_D source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_DL source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_I source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_IL source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_L source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_LL source: jrt:/java.base
[0.115s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_LLL source: jrt:/java.base
[0.311s][info][class,load] java.lang.invoke.BoundMethodHandle$Species_LLLL source: __JVM_LookupDefineClass__
[0.759s][warning][cds ] Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL: Unsupported location

=============
Proposed fix:
It's normal for core libs to generate such species classes dynamically (and different kind of classes may be generated when core libs are updated, e.g., in JDK-8336856).

It's also normal for CDS to refuse to archive dynamically generated classes.

Therefore, we shouldn't print this as a warning. Nothing is wrong here.