Skip to content
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

Support concurrent on DefaultClassResolver #46

Conversation

kazuki43zoo
Copy link
Contributor

The DefaultClassResolver is not thread-safe.
I will propose to support concurrent using ConcurrentHashMap on the DefaultClassResolver.

WDYT?

@kazuki43zoo kazuki43zoo changed the title Support concurrent on default class resolver Support concurrent on DefaultClassResolver Mar 18, 2018
@@ -41,28 +42,30 @@
*/
public class DefaultClassResolver extends Object implements ClassResolver
{
private Map classes = new HashMap(101);
private Map classes = new ConcurrentHashMap(101);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use generics here? This will reduce casting below.

Copy link
Contributor Author

@kazuki43zoo kazuki43zoo Mar 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed to use generics. and add final.

try {
result = Class.forName(className);
} catch (ClassNotFoundException ex) {
if (className.indexOf('.') == -1) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when we are here, this if clause can be moved out of the catch and implemented as follow (classForName already throws ClassNotFoundException):

if (className.indexOf('.') == -1) {
    result = Class.forName("java.lang." + className);
    classes.put("java.lang." + className, result);
} else {
    classes.put(className, Class.forName(className));
}

then result and additional check for null is not needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I refactored this code with your suggestion as reference.

@kazuki43zoo
Copy link
Contributor Author

@lukaszlenart Thanks for your review!
I've fixed your comments.
Please review again.

Thanks!

} else {
result = Class.forName(className);
}
classes.put(className, result);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will duplicate langClassName, so we will end up with two entries for the same class.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your comment.
I think this behavior is same as the current version. Should change this behavior in this change?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, which means the java.lang. classes will be always located by the short version (Integer instead of java.lang.Integer). I think .put in line 61 can be thrown aways.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've fixed your comment. please review again.
Thanks.

if (result != null) {
return result;
}
result = (className.indexOf('.') == -1) ? Class.forName("java.lang." + className) : Class.forName(className);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do prefer pure if clause but that's ok :)

@lukaszlenart
Copy link
Collaborator

Do you want to port this fix into previous branches?

@lukaszlenart
Copy link
Collaborator

LGTM 👍

@lukaszlenart lukaszlenart merged commit 26f9c15 into orphan-oss:master Mar 19, 2018
@kazuki43zoo
Copy link
Contributor Author

Thanks for merging!

@kazuki43zoo kazuki43zoo deleted the support-concurrent-on-DefaultClassResolver branch March 19, 2018 14:04
@lukaszlenart
Copy link
Collaborator

3.2.5 is out and under way to the Central.

@kazuki43zoo
Copy link
Contributor Author

Wow, It's great!!

JCgH4164838Gh792C124B5 pushed a commit to JCgH4164838Gh792C124B5/ognl that referenced this pull request Sep 29, 2019
…on-DefaultClassResolver

Support concurrent on DefaultClassResolver

(cherry picked from commit 26f9c15)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants