-1

I tried to create a way to compare any two any Objects and its fields, with the option to exclude fields when needed.

It works but when I tested it its 30 times slower than a equals Method (in which i can't exclude fields).

Is there a way to make the reflection faster ?

Or is it generally bad to use it at all ? And if so, is there a way to make a dynamical but genereic compare option so that I can exclude fields? I genereally Use miltiple comperators for issues like that, but I want to make it more "easy" if thats a good idea. 

    private static boolean compareFieldsWithBlacklist(Class clazz, Object o1, Object o2, List<String> blackList)
            throws IllegalAccessException {

        Field[] fields = clazz.getDeclaredFields();
        for (Field field : fields) {

            if (!blackList.contains(field.getName())) {
                field.setAccessible(true);
                Object value1 = field.get(o1);
                Object value2 = field.get(o2);


                if (!value1.equals(value2))
                    return false;
            }

        }

        return true;
    }

I also tried to instanciate the Fields Array only once when i try to compare a collection. But it only made it a little bit faster.

Luxusproblem
  • 1,913
  • 11
  • 23
  • 1
    Why you can't override equals? About reflection check http://thefinestartist.com/effective-java/53 – Woland Sep 27 '19 at 08:51
  • 2
    Why do you need this to be done via reflection? And why does it need to be especially fast? – Thilo Sep 27 '19 at 08:51
  • 1
    Using reflection is usually bad design. – Paul Sep 27 '19 at 08:52
  • I can. But I want to exclude fields when needed. It is not the end of the world. But I wanted a "easy" and "fast" way to compare 2 Objects and exlucede fields without writing a comparator everytime, I want to compare other values. I could override equals and have params for field names and a switch case or a if cascade etc. – Luxusproblem Sep 27 '19 at 08:55
  • 1
    So, if you could – just do it :) Reflection is slow. – Woland Sep 27 '19 at 08:56
  • 2
    Possible duplicate of [Faster alternatives to Java's reflection](https://stackoverflow.com/questions/19557829/faster-alternatives-to-javas-reflection) – Orace Sep 27 '19 at 08:57
  • @Thilo I kind of phrased it wrong. I need dynamic Compare-Mechanisms and I wanted to provide a way to not generate Multiple Equals clauses for Objects or Multiple comperators. And it needs to be fast because there are a lot of objects. And it needs to be dynamic because the "rules" could change during the runtime. – Luxusproblem Sep 27 '19 at 09:20
  • Ok, maybe some caching will help. For example, cache clazz.getDeclaredFields() (with .setAccessible(true)). – Woland Sep 27 '19 at 09:29

2 Answers2

0

Yes, reflection in general is at least an order of magnitude slower than using the normal methods. You should only ever use it if it's necessary because the normal methods can't do something at all.

Moreover, this is not likely to change; the JVM works the way it does, and Java considers backward compatibility so important that it's hard to see how it would ever change to favor speedier reflection.

Kilian Foth
  • 13,904
  • 5
  • 39
  • 57
0

Reflection is a bad idea and slow. Also inheritance would make it even more cumbersome.

You want equality on some field values.

Let the IDE generate an equals method, uncheck those fields you do consider irrelevant.

If it intended for external usage only, extract it to a Comparator or such.

The disadvantage:

  • Maintenance on class changes
  • Not a generic solution for all classes, but a blacklist is not very generic too
Joop Eggen
  • 107,315
  • 7
  • 83
  • 138
  • That is reasonable. But for example i want to compare the same Object multiple times for different entries, depending on whats happening on runtime. I generally Use Comperators for that, to specify the fields. I personally feel this is the safest way to do. Or with equals. But with equals i need to do more Mainenance for the nessesary fields. But it will be more Maintainable. – Luxusproblem Sep 27 '19 at 09:14
  • I mentioned Comparator. _Equality_ with respect to some feature, or _grouping_ like in a SQL GROUP BY, or a Stream grouping. You are right not to put value based equality in classes, if those concerned fields are not **final**. – Joop Eggen Sep 27 '19 at 09:25