Regression in newObject creation.

[ozhelezniak-talend]

I see a class and a method was re-written (com.cedarsoftware.util.ClassUtilities#newInstance)
And it causes a regression when we already relly on the previous behavior of instance creation.
We have a class that has a constructor that initialize a transient field, and its Deprecated, but according to comparator it has higher priority and it's been initialized with an empty string (default non-null arguments first)

My question is, can I somehow overwrite the com.cedarsoftware.util.ClassUtilities#newInstance behavior to enforce it to use a different constructor or even to enforce the use an Unsafe method as it was before?
(or some kind of ignore action for that particular constructor)

[jdereg]

Although you can set ClassUtilities.setUseUnsafe(true) from java-util, I would recommend writing a JsonReader.ClassFactory for your difficult to instantiate class. The great thing about adding a factory class, is that you control both instantiation and populdation. Here is an example of a semi-complex factory class: https://github.com/jdereg/json-io/blob/master/src/test/java/com/cedarsoftware/io/CustomJsonSubObjectTest.java

See https://github.com/jdereg/json-io/blob/master/user-guide-readOptions.md#class-factory for User Guide on how to add the class factory to the ReadOptions.

The scoring algorithm to select constructors is complicated and we have made it more capable, however, because that is an emperical guessing game, it does not always work out for the best. That is why I am recommending using natural class factory. If you feel that we have an error in the constructor selection scoring algorithm, please let me know.

[ozhelezniak-talend]

Thank you for the suggestion with customClassFactory.
Unfortunately, I don't see a better approach than the existing one. Just wanted to highlight that a new one causes regression in behavior.

About setUseUnsafe(true) - it won't help, because the factory can successfully find a constructor and create and instance with it.
so the unsafe try won't be even reached

[jdereg]

I just released a new version of java-utility that may fix the issue you are seeing. Please try java-util 3.1.0 and see if it fixes the issue you had with construtors.

[ozhelezniak-talend]

Hello @jdereg
I checked it didn't fix it, and frankly, I checked sources and didn't get what commit\change should fix it =)

[jdereg]

The source change that should take care of it, was the removal of the "condition" in ReflectionUtils that was preventing setAccessible(true) from being called when it deem the item (Method, Field, Constructor) public. As it turns out, a public Field, Method, Constructor can still fail in a JPMS and OSGi environment, so the conditional had to be removed. We have tests now that will break if the "isPublc()" check is added to ReflectionUtils and prevents setAccessible(true) from being called (on *public*) items. It seems counter intuitive, but it is related to module security.

…

On Tue, Feb 25, 2025 at 3:21 AM Oleksandr Zhelezniak < ***@***.***> wrote: Hello @jdereg <https://github.com/jdereg> I checked it didn't fix it, and frankly, I checked sources and didn't get what commit\change should fix it =) — Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABI76TU6PXQJCCJDWTEBAQD2RQRZXAVCNFSM6AAAAABWOEVIQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA4TAOBSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: ozhelezniak-talend]*ozhelezniak-talend* left a comment (jdereg/java-util#110) <#110 (comment)> Hello @jdereg <https://github.com/jdereg> I checked it didn't fix it, and frankly, I checked sources and didn't get what commit\change should fix it =) — Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABI76TU6PXQJCCJDWTEBAQD2RQRZXAVCNFSM6AAAAABWOEVIQ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBRGA4TAOBSGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ozhelezniak-talend]

Okay, I got it, thank you.
Mine issue different =)

[jdereg]

java-util 3.1.1 and json-io 4.50.0 were released on March 6th. They are available on Maven Central. Lots of improvements were made. Specifically, I wanted to mention that object construction was strengthened. Constructor retrieval and argument matching. Would you mind trying the new versions out and letting me know if your difficult to instantiate class now works (again)?

Thank you,
John

[ozhelezniak-talend]

I checked, and it didn't help, I still need to define a custom ClassFactory.
But I think it's expected in our use case.

By the way, I prepared a PR that fixes FastWriter