Skip to main content

[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


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

Unnecessary Table Join in Native Query generated from JPQL

Unnecessary Table Join in Native Many-to-Many Query generated from

JPQL simple Child query generates unnecessary Table Join

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.


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

>Recommend you vote for
>    -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
>eclipselink-users mailing list

Back to the top