On Wednesday, June 22, 2011 18:51:29 Ian Springer wrote:
By default, when compiling, IntellIJ adds runtime assertions for
Nullable/NotNull annotations via bytecode augmentation. To turn this
off, you can go to File>Settings>Compiler and uncheck "Add @NotNull
assertions". I generally turn it off and just make use of the inspection
in the IDE that reports Nullable/NotNull violations.
http://blogs.jetbrains.com/yole/archives/000043.html
I would be surprised if there are other tools that enforce the
annotations at runtime by default, but you never know.
If I remember correctly, Heiko said that he compiled RHQ from commandline
using just maven. That's why I thought IJ wouldn't have had the chance to
insert those assertions. But you're right that the other options are much less
likely so maybe this is just a case of some stale jar lying around somewhere
in the dev-container...
On 06/22/2011 11:46 AM, Lukas Krejci wrote:
> I always thought that these annotations are only used by IJ IDE, but
> apparently, they can affect runtime, which is kinda cool.
>
> I think there are at least 4 ways how that can happen:
>
> 1) IntelliJ somehow enhances the bytecode of our jars. But you said you
> compile by just using maven so I doubt that would be the case.
>
> 2) There is some java agent used in your RHQ server process that enhances
> the classes when they're loaded. How do you start your dev-container?
>
> 3) There might be some kind of interceptor in play but I'm not
> well-versed in JBoss AS aspects to tell.
>
> 4) This being a JPA entity, even Hibernate might be involved.
>
> But figuring out how this thing is pushed into runtime is definitely
> worth it - maybe we could use it to do more wild checks, wiring,
> whatever if it was sufficiently efficient and reusable.
>
> On Wednesday, June 22, 2011 17:08:39 Ian Springer wrote:
>> On 06/22/2011 09:55 AM, Heiko W.Rupp wrote:
>>> So I am seeing those errors in server log a lot when e.g. scheduling
>>> operations:
>>>
>>> Caused by: java.lang.IllegalArgumentException: Argument 0 for @NotNull
>>>
>>> parameter of org/rhq/core/domain/resource/Resource.setName must
>>> not be null
>>>
>>> at
>>> org.rhq.core.domain.resource.Resource.setName(Resource.java)
>>>
>>> While I am not sure who or what is adding that crazy check to my
>>> classes,
>>
>> I really think it must be IntelliJ. They are JetBrains annotations, so
>> I'd be surprised if things like the maven compiler plugin recognized
>> them.
>>
>>> from the following code:
>>> public void setName(@NotNull String name) {
>>>
>>> this.name = name;
>>>
>>> }
>>>
>>> I think as we do obviously have code parts in the Configuration world
>>> that seem to call this setter with a null argument, we should either
>>>
>>> - remove that annotation, as reality has proven that it is wrong
>>> or
>>> - fix the code that is calling this setter with a null argument
>>
>> Agreed. That's the main point of those annotations - to define a
>> method's contract regarding null parameters, and when the IDE catches
>> callers not following the contract, either change the callers or change
>> the contract.
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/rhq-devel