reflect.json: allow for package wildcard my.package.*

[vojkny]

It would be very useful to be able to use wildcards for packages. Consider following reflect.json:

[  
    {  
        "name":"com.maxmind.geoip2.model.ConnectionTypeResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.AsnResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.CountryResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.IspResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.AbstractResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.AbstractCountryResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.CityResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.EnterpriseResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.DomainResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.InsightsResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.AnonymousIpResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    },
    {  
        "name":"com.maxmind.geoip2.model.AbstractCityResponse",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    }
]

Which could just be replaced with:

[
    {  
        "name":"com.maxmind.geoip2.model.*",
        "allPublicMethods":true,
        "allDeclardConstructors":true
    }
]

[jroper]

This would make using protobufs (and grpc) a lot easier, since protobufs use reflection to implement their equals/hashCode/toString methods, so every protobuf class generated must have all fields allowed for reflection. Generally, protobufs all get generated into their own package (or as inner classes of an outer class) so allowing wildcards for everything in a package, and for every inner class of an outerclass, would be very useful.

[taranion]

I could use that too. A am using a XML serializer, who makes use of reflection. I do have approx. 200 classes I would need to the JSON config (or Feature class) manually. Besides, having a static list configured for Graal is prone to fail, when the data model of the serialized classes is extended by getting added more classes.

[cyw3]

Any progress here?

[Legion2]

I have a complex data model with over 100 classes, they are all in one package (and subpackages). It would be so easy if I could just add the whole package for reflection.

[MilosBogi]

I would agree that this feature is required.

[drm]

I would even argue that including reflection metadata for all included classes and their members should be the default and could easily provided by the compiler, I would think. Not including this is a form of premature optimization, imho. It's rather tedious now to convert an existing project to using Graal native-image because of this, while this is really not an optimization I want to worry about right now...

[davidreis97]

@drm I have to agree, this is a major issue for porting apps that heavily rely on reflection. I would love to hear from a maintainer about why this isn't the case by default, I'm sure there must be a good reason.

[amoscatelli]

bump ?

[srnagar]

Any update on this issue? We have many libraries each containing hundreds of models that are reflectively accessed by Jackson serializer. Enumerating every class used in serialization requires a lot of effort and results in a really large reflect-config.json file.

[prasannak-ra]

We've an exact same situation, when using hazelcast I had to add a long list of classes in reflection config, wildcard feature would really help.

[tlf30]

We are working on a large swing application, and due to the way that swing property change listeners work we basically need every class in our app (hundreds of them) to have full reflection, along with several of our dependencies (also several hundred classes) if we could simply specify by package, or even just have a wildcard option that says ALL classes, this would be so much simpler.