Re: [eclipselink-users] Eclipselink 2.0.1 inject code detected by FindBu

[bht@xxxxxxxxxxxxx]

Thanks.

FindBugs is a good tool, and replacing a Boolean constructor is
certainly cheap and rewarding (low hanging fruit).

So I voted for the 289900 bug.

While we discuss the unnecessary use of resources, I would encourage
you to vote for bugs that highlight great potential performance gain
in the same (code generating) category:

JPQL exists subquery generates unnecessary table join
https://bugs.eclipse.org/bugs/show_bug.cgi?id=298494

Unnecessary Table Join in Native Query generated from JPQL
https://bugs.eclipse.org/bugs/show_bug.cgi?id=300625

Unnecessary Table Join in Native Many-to-Many Query generated from
JPQL
https://bugs.eclipse.org/bugs/show_bug.cgi?id=301599

JPQL simple Child query generates unnecessary Table Join
https://bugs.eclipse.org/bugs/show_bug.cgi?id=304923

We can see that Eclipselink generates awful spaghetti code in so many
scenarios that it is impossible to write efficient JPQL on average.

I find myself between a rock and a hard place trying to stay clear of
native queries.

Bernard




On Sun, 07 Mar 2010 22:23:14 -0800, you wrote:

>Recommend you vote for https://bugs.eclipse.org/bugs/show_bug.cgi?id=289900
>
>    -Len
>
>José Arcángel Salazar Delgado wrote:
>> Hi.
>>
>> I'm using sonar with findbugs to check the sanity of the code. Findbugs 
>> encounter these errors in the code injected by eclipselink:
>>
>> Performance - Method invokes inefficient Number constructor; use static 
>> valueOf instead
>>
>> Bad practice - Comparison of String parameter using == or !=
>>
>> Malicious code vulnerability - May expose internal representation by returning 
>> reference to mutable object 
>>
>> Malicious code vulnerability - May expose internal representation by 
>> incorporating reference to mutable object
>>
>> Bad practice - Transient field that isn't set by deserialization. 
>>
>> Performance - Method invokes inefficient Boolean constructor; use 
>> Boolean.valueOf(...) instead
>>
>> can this be corrected for the next release?
>>
>> thanks for the time.
>>
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>
>>
>>   
>_______________________________________________
>eclipselink-users mailing list
>eclipselink-users@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/eclipselink-users