-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
forced.getProperty () for enum field returns first enum value instead of null #5
Comments
You are right, the last call should return The thing with Btw, try using |
Sharing my thoughts here: the forced mode is mainly for setting properties. Getting properties in forced mode was never in the focus. Maybe getting the property in the forced mode should not create any nested property? |
I have the patch ready, just wondering if getting in forced mode should:
I am leaning towards #2 - reading should not set anything. |
However, I see the tests are showing that option |
I've been working around this last friday and I may add a bit more context about how I use this and why it bothered me. I'm using jodd props to describe beans I want to create or populate, I found it a great fit with all the macros and profiles and so on... I encountered a series of hipcups doing so... Maybe the real trouble here is that hasProperty should return true if the bean's class (and not the bean instance) has the required property, regardless of the bean instance having it's ancestors being set or not, whereas finding if the bean instance has this property set would be a "hasValue"... @Data
public static class Foo {
String foo;
Bar bar;
}
@Data
public static class Bar {
String foo;
MyEnum myEnum;
}
public static enum MyEnum {
VAL1,VAL2,VAL3;
}
Foo bean = new Foo();
Would give:
hasProperty(bean, "bar.myEnum") -> false
getProperty(bean, "bar.myEnum") -> VAL1
hasProperty(bean, "bar.myEnum") -> true Anyway, I think it's disturbing that a getter sets some values, be it the last one or any of it's ancestors. Let me know your thoughts on this, I found a workaround for my use case already so it's not a big problem right now |
Thank you for the detailed use case, now it's much clear to me what's going on. You are right - However,
Thank you again, I will build a snapshot one of these days and would kindly ask to review it if you don't mind :))) |
As always, I'm impressed with your reactivity and continued support on this framework, I'll gladly test the snapshot whenever it's ready |
@tfabien thanks for your kind words, I am really hoping this library helps ppl. Sorry for the late response; work took my December away :( I've just made a SNAPSHOT that should fix both issues: https://oss.sonatype.org/content/repositories/snapshots/org/jodd/jodd-util/6.0.1-SNAPSHOT/ If you have time, would you be able to try it and let me know if it works for you? |
Tested on: jodd-util:6.0.0
I don't know if this is "by design" or a simple mishap, but I found this quite disturbing, I would have expected this to return "null" rather than an arbitrary value
Produces:
I get that you can't instanciate a "new MyEnum", but IMO a "null enum" might be what's closest to an empty Object
"Problem" (if any...) is located in
ClassUtil#newInstance(final Class<T> type)
The text was updated successfully, but these errors were encountered: