|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
_______________________________________________ weld-issues mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-issues
I would strongly urge you to reconsider your take on this.
Good frameworks follow the Robustness Principle, aka Postel's Law:
Utilization of Scala and other non-Java languages on the JVM is rapidly growing. If somebody has an isolated little bit of Scala in their application, even if it has nothing to do with any injectable beans, Weld currently fails completely. I would argue that this is a serious flaw in Weld, even if it's being triggered by a serious flaw in these other languages' compilers.
This is doubly true given that, other than Weld, I haven't come across any other tool that has this problem. I can deploy my application fine in TomEE. The rest of JBoss's detection works fine, including Servlets & EJB 3.1. Given that this issue has a pretty big impact and quite a lot of people use Scala these days, it seems that it would be worthwhile for Weld to be robust against this particular issue—even if it shouldn't have to be in an ideal world.
If you look at the code for Java's getSimpleName, it's clear that there is absolutely no danger in catching this error. It seems perfectly reasonable to me to catch this particular Error with this exact message "Malformed class name" and log a warning, treating the class as anonymous. There are some limited cases where catching an Error is both appropriate and safe.![]()
I haven't read the Weld code yet, but I imagine that you want to exclude both anonymous and local classes. There's a simple and reliable test:
clazz.getEnclosingMethodInfo() != null