Bagaimana Anda menemukan semua subclass dari kelas yang diberikan di Jawa?

Bagaimana caranya dan mencoba menemukan semua subclass dari kelas yang diberikan (atau semua implementator dari antarmuka yang diberikan) di Jawa? Sampai sekarang, saya punya metode untuk melakukan ini, tetapi saya merasa cukup tidak efisien (untuk sedikitnya). Metodenya adalah:

1. Dapatkan daftar semua nama kelas yang ada di jalur kelas
2. Muat masing-masing kelas dan uji untuk melihat apakah itu adalah subclass atau implementor dari kelas atau antarmuka yang diinginkan

Di Eclipse, ada fitur bagus yang disebut Hirarki Tipe yang berhasil menunjukkan ini dengan cukup efisien. Bagaimana caranya dan melakukannya secara terprogram?

Tidak ada cara lain untuk melakukannya selain apa yang Anda gambarkan. Pikirkan tentang hal ini - bagaimana bisa ada yang tahu kelas apa yang memperluas ClassX tanpa memindai setiap kelas di classpath?

Eclipse hanya dapat memberi tahu Anda tentang super dan subclass dalam apa yang tampaknya menjadi jumlah waktu "efisien" karena sudah memiliki semua tipe data yang dimuat pada titik di mana Anda menekan tombol "Tampilan dalam Jenis Hirarki" (karena itu adalah terus mengkompilasi kelas Anda, tahu tentang semua yang ada di classpath, dll).

Memindai kelas tidak mudah dengan Java murni.

Kerangka kerja pegas menawarkan kelas yang disebut ClassPathScanningCandidateComponentProvider yang dapat melakukan apa yang Anda butuhkan. Contoh berikut akan menemukan semua subclass dari MyClass dalam paket org.example.package

ClassPathScanningCandidateComponentProvider provider = new ClassPathScanningCandidateComponentProvider(false);
provider.addIncludeFilter(new AssignableTypeFilter(MyClass.class));

// scan in org.example.package
Set<BeanDefinition> components = provider.findCandidateComponents("org/example/package");
for (BeanDefinition component : components)
{
    Class cls = Class.forName(component.getBeanClassName());
    // use class cls found
}

Metode ini memiliki keuntungan tambahan dari menggunakan analisa bytecode untuk menemukan kandidat yang berarti akan tidak memuat semua kelas scan.

Ini tidak mungkin dilakukan hanya dengan menggunakan Java Reflections API bawaan.

Ada sebuah proyek yang melakukan pemindaian dan pengindeksan classpath Anda yang diperlukan sehingga Anda dapat mengakses informasi ini ...

Refleksi

Analisis metadata runtime Java, dalam semangat Scannotations

Refleksi memindai classpath Anda, mengindeks metadata, memungkinkan Anda untuk menanyakannya saat runtime dan dapat menyimpan dan mengumpulkan informasi tersebut untuk banyak modul dalam proyek Anda.

Menggunakan Refleksi, Anda dapat meminta metadata Anda untuk:

• dapatkan semua subtipe dari beberapa tipe
• dapatkan semua jenis yang dianotasi dengan anotasi
• dapatkan semua jenis yang dianotasi dengan beberapa anotasi, termasuk pencocokan parameter anotasi
• dapatkan semua metode yang dijelaskan dengan beberapa

(Penafian: Saya belum menggunakannya, tetapi deskripsi proyek tampaknya cocok untuk kebutuhan Anda.)

Jangan lupa bahwa Javadoc yang dihasilkan untuk suatu kelas akan mencakup daftar subkelas yang dikenal (dan untuk antarmuka, kelas implementasi yang dikenal).

Coba ClassGraph . (Penafian, saya penulisnya). ClassGraph mendukung pemindaian untuk subclass dari kelas yang diberikan, baik pada saat runtime atau saat membangun, tetapi juga banyak lagi. ClassGraph dapat membangun representasi abstrak dari seluruh grafik kelas (semua kelas, anotasi, metode, parameter metode, dan bidang) dalam memori, untuk semua kelas di classpath, atau untuk kelas dalam paket yang dimasukkan dalam daftar putih, dan Anda dapat meminta grafik kelas itu namun kamu ingin. ClassGraph mendukung lebih banyak mekanisme spesifikasi classpath dan classloader daripada pemindai lain, dan juga bekerja dengan mulus dengan sistem modul JPMS baru, jadi jika Anda mendasarkan kode Anda pada ClassGraph, kode Anda akan portabel secara maksimal. Lihat API di sini.

Saya melakukan ini beberapa tahun yang lalu. Cara yang paling dapat diandalkan untuk melakukan ini (yaitu dengan Java API resmi dan tidak ada dependensi eksternal) adalah dengan menulis dokumen khusus untuk menghasilkan daftar yang dapat dibaca saat runtime.

Anda dapat menjalankannya dari baris perintah seperti ini:

javadoc -d build -doclet com.example.ObjectListDoclet -sourcepath java/src -subpackages com.example

atau jalankan dari semut seperti ini:

<javadoc sourcepath="${src}" packagenames="*" >
  <doclet name="com.example.ObjectListDoclet" path="${build}"/>
</javadoc>

Berikut kode dasarnya:

public final class ObjectListDoclet {
    public static final String TOP_CLASS_NAME =  "com.example.MyClass";        

    /** Doclet entry point. */
    public static boolean start(RootDoc root) throws Exception {
        try {
            ClassDoc topClassDoc = root.classNamed(TOP_CLASS_NAME);
            for (ClassDoc classDoc : root.classes()) {
                if (classDoc.subclassOf(topClassDoc)) {
                    System.out.println(classDoc);
                }
            }
            return true;
        }
        catch (Exception ex) {
            ex.printStackTrace();
            return false;
        }
    }
}

Untuk mempermudah, saya telah menghapus parsing argumen baris perintah dan saya menulis ke System.out daripada file.

Saya tahu saya terlambat beberapa tahun ke pesta ini, tetapi saya menemukan pertanyaan ini mencoba menyelesaikan masalah yang sama. Anda dapat menggunakan pencarian internal Eclipse secara terprogram, jika Anda menulis Plugin Eclipse (dan dengan demikian mengambil keuntungan dari caching mereka, dll), untuk menemukan kelas yang mengimplementasikan antarmuka. Inilah potongan pertama saya (sangat kasar):

  protected void listImplementingClasses( String iface ) throws CoreException
  {
    final IJavaProject project = <get your project here>;
    try
    {
      final IType ifaceType = project.findType( iface );
      final SearchPattern ifacePattern = SearchPattern.createPattern( ifaceType, IJavaSearchConstants.IMPLEMENTORS );
      final IJavaSearchScope scope = SearchEngine.createWorkspaceScope();
      final SearchEngine searchEngine = new SearchEngine();
      final LinkedList<SearchMatch> results = new LinkedList<SearchMatch>();
      searchEngine.search( ifacePattern, 
      new SearchParticipant[]{ SearchEngine.getDefaultSearchParticipant() }, scope, new SearchRequestor() {

        @Override
        public void acceptSearchMatch( SearchMatch match ) throws CoreException
        {
          results.add( match );
        }

      }, new IProgressMonitor() {

        @Override
        public void beginTask( String name, int totalWork )
        {
        }

        @Override
        public void done()
        {
          System.out.println( results );
        }

        @Override
        public void internalWorked( double work )
        {
        }

        @Override
        public boolean isCanceled()
        {
          return false;
        }

        @Override
        public void setCanceled( boolean value )
        {
        }

        @Override
        public void setTaskName( String name )
        {
        }

        @Override
        public void subTask( String name )
        {
        }

        @Override
        public void worked( int work )
        {
        }

      });

    } catch( JavaModelException e )
    {
      e.printStackTrace();
    }
  }

Masalah pertama yang saya lihat sejauh ini adalah bahwa saya hanya menangkap kelas yang secara langsung mengimplementasikan antarmuka, tidak semua subclass mereka - tetapi sedikit rekursi tidak pernah menyakiti siapa pun.

Dengan mengingat keterbatasan yang disebutkan dalam jawaban lain, Anda juga dapat menggunakan openpojoPojoClassFactory ( tersedia di Maven ) dengan cara berikut:

for(PojoClass pojoClass : PojoClassFactory.enumerateClassesByExtendingType(packageRoot, Superclass.class, null)) {
    System.out.println(pojoClass.getClazz());
}

Di mana packageRootString akar dari paket yang ingin Anda cari (misalnya "com.mycompany"atau bahkan hanya "com"), dan Superclassmerupakan supertype Anda (ini juga berfungsi pada antarmuka).

Saya hanya menulis demo sederhana untuk menggunakan org.reflections.Reflectionsuntuk mendapatkan subclass dari kelas abstrak:

https://github.com/xmeng1/ReflectionsDemo

Tergantung pada persyaratan khusus Anda, dalam beberapa kasus mekanisme loader layanan Java mungkin mencapai apa yang Anda cari.

Singkatnya, ini memungkinkan pengembang untuk secara eksplisit menyatakan bahwa suatu kelas mensubklasifikasikan beberapa kelas lain (atau mengimplementasikan beberapa antarmuka) dengan mendaftarkannya dalam file di direktori file JAR / WAR META-INF/services. Kemudian dapat ditemukan menggunakan java.util.ServiceLoaderkelas yang, ketika diberi Classobjek, akan menghasilkan instance dari semua subclass yang dideklarasikan dari kelas itu (atau, jika Classmewakili antarmuka, semua kelas yang mengimplementasikan antarmuka itu).

Keuntungan utama dari pendekatan ini adalah bahwa tidak perlu secara manual memindai seluruh classpath untuk subclass - semua logika penemuan terkandung dalam ServiceLoaderkelas, dan itu hanya memuat kelas yang secara eksplisit dinyatakan dalam META-INF/servicesdirektori (tidak setiap kelas di classpath) .

Namun, ada beberapa kelemahan:

• Itu tidak akan menemukan semua subclass, hanya yang subclass dinyatakan secara eksplisit. Dengan demikian, jika Anda harus benar-benar menemukan semua subclass, pendekatan ini mungkin tidak cukup.
• Ini mengharuskan pengembang untuk secara eksplisit mendeklarasikan kelas di bawah META-INF/servicesdirektori. Ini merupakan beban tambahan bagi pengembang, dan bisa rawan kesalahan.
• The ServiceLoader.iterator()menghasilkan contoh subclass, bukan mereka Classobjek. Ini menyebabkan dua masalah:
  • Anda tidak bisa mengatakan bagaimana subkelas dikonstruksi - konstruktor no-arg digunakan untuk membuat instance.
  • Dengan demikian, subclass harus memiliki konstruktor default, atau harus eksplisit menyatakan konstruktor no-arg.

Rupanya Java 9 akan mengatasi beberapa kekurangan ini (khususnya, yang berkaitan dengan instantiasi subkelas).

Sebuah contoh

Misalkan Anda tertarik menemukan kelas yang mengimplementasikan antarmuka com.example.Example:

package com.example;

public interface Example {
    public String getStr();
}

Kelas com.example.ExampleImplmengimplementasikan antarmuka itu:

package com.example;

public class ExampleImpl implements Example {
    public String getStr() {
        return "ExampleImpl's string.";
    }
}

Anda akan mendeklarasikan kelas ExampleImpladalah implementasi Exampledengan membuat file yang META-INF/services/com.example.Exampleberisi teks com.example.ExampleImpl.

Kemudian, Anda dapat memperoleh instance dari setiap implementasi Example(termasuk instance dari ExampleImpl) sebagai berikut:

ServiceLoader<Example> loader = ServiceLoader.load(Example.class)
for (Example example : loader) {
    System.out.println(example.getStr());
}

// Prints "ExampleImpl's string.", plus whatever is returned
// by other declared implementations of com.example.Example.

Perlu dicatat juga bahwa ini tentu saja hanya akan menemukan semua subclass yang ada di classpath Anda saat ini. Agaknya ini tidak apa-apa untuk apa yang Anda lihat saat ini, dan kemungkinan Anda memang mempertimbangkan hal ini, tetapi jika Anda pernah melepaskan non- finalkelas ke alam bebas (untuk berbagai tingkat "liar") maka sepenuhnya layak bahwa orang lain telah menulis subkelas mereka sendiri yang tidak akan Anda ketahui.

Jadi jika Anda ingin melihat semua subclass karena Anda ingin membuat perubahan dan akan melihat bagaimana hal itu mempengaruhi perilaku subclass - maka ingatlah subclass yang tidak bisa Anda lihat. Idealnya semua metode non-pribadi Anda, dan kelas itu sendiri harus didokumentasikan dengan baik; buat perubahan sesuai dengan dokumentasi ini tanpa mengubah semantik metode / bidang non-pribadi dan perubahan Anda harus kompatibel-mundur, untuk setiap subkelas yang setidaknya mengikuti definisi Anda tentang superclass.

Alasan Anda melihat perbedaan antara implementasi Anda dan Eclipse adalah karena Anda memindai setiap kali, sementara Eclipse (dan alat lainnya) memindai hanya sekali (selama beban proyek sebagian besar waktu) dan membuat indeks. Lain kali Anda meminta data itu tidak memindai lagi, tetapi lihat indeks.

Saya menggunakan lib refleksi, yang memindai classpath Anda untuk semua subclass: https://github.com/ronmamo/reflections

Beginilah caranya:

Reflections reflections = new Reflections("my.project");
Set<Class<? extends SomeType>> subTypes = reflections.getSubTypesOf(SomeType.class);

Tambahkan mereka ke peta statis di dalam (this.getClass (). GetName ()) konstruktor kelas induk (atau buat yang default) tetapi ini akan diperbarui dalam runtime. Jika inisialisasi malas adalah suatu pilihan, Anda dapat mencoba pendekatan ini.

Anda dapat menggunakan perpustakaan org.reflections dan kemudian, membuat objek kelas Refleksi. Menggunakan objek ini, Anda bisa mendapatkan daftar semua subclass dari kelas yang diberikan. https://www.javadoc.io/doc/org.reflections/reflections/0.9.10/org/reflections/Reflections.html

    Reflections reflections = new Reflections("my.project.prefix");
    System.out.println(reflections.getSubTypesOf(A.class)));

Saya perlu melakukan ini sebagai test case, untuk melihat apakah kelas baru telah ditambahkan ke kode. Inilah yang saya lakukan

final static File rootFolder = new File(SuperClass.class.getProtectionDomain().getCodeSource().getLocation().getPath());
private static ArrayList<String> files = new ArrayList<String>();
listFilesForFolder(rootFolder); 

@Test(timeout = 1000)
public void testNumberOfSubclasses(){
    ArrayList<String> listSubclasses = new ArrayList<>(files);
    listSubclasses.removeIf(s -> !s.contains("Superclass.class"));
    for(String subclass : listSubclasses){
        System.out.println(subclass);
    }
    assertTrue("You did not create a new subclass!", listSubclasses.size() >1);     
}

public static void listFilesForFolder(final File folder) {
    for (final File fileEntry : folder.listFiles()) {
        if (fileEntry.isDirectory()) {
            listFilesForFolder(fileEntry);
        } else {
            files.add(fileEntry.getName().toString());
        }
    }
}