[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] Eclipselink 2.0.1 inject code detected by FindBugs
|
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