Home » Modeling » EMF » Generated Code - Autoboxing Warnings
| |
| Re: Generated Code - Autoboxing Warnings [message #1613322 is a reply to message #1612072] |
Thu, 12 February 2015 15:20   |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I disagree with your auto-boxing statement - I have also turned on this
as an error in our codebases because the Object => primitive type hides
possible NPEs from you (at least you don't see them immediately).
Unfortunately JDT does not allow me turn Object => primitive to an error
while accepting primitive => Object as ok because this is not a
dangerous operation.
Finally as I understand it autoboxing is nothing more than a compiler
trick who inserts Boolean.valueOf(), .... statements to go from
primitive to object type so performance and bytecode sizewise generating
this into the java code should not matter (at least until we get more
speciliazed warnings from JDT).
Tom
On 11.02.15 21:20, Ed Merks wrote:
> Stefan,
>
> If you generate for Java 1.5 as supported by newer EMF runtimes, it will
> make use of features of Java 1.5 such as autoboxing (and generics).
> There's nothing wrong with autoboxing so just turn off the warning or
> target 1.4 and stop using generics (which is unlikely your goal).
>
>
> On 11.02.2015 15:46, Stefan Lauchenauer wrote:
>> Since I switched to a newer Eclipse (and EMF Runtime Version from 2.4 to
>> 2.6) generated Code differs in its Boxing handling:
>>
>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>> return isDefaultObject();
>>
>> used to be
>>
>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>> return isDefaultObject() ? Boolean.TRUE : Boolean.FALSE;
>>
>> isDefaultObject() in both cases returns boolean. My Problem is that I
>> have Warnings for Autoboxing enabled - now I get lots of those warnings
>> which I didn't have when I generated code in the old Eclipse.
>>
>> How can I change EMFs Code generation to box variables (again)?
>
|
|
|
| Re: Generated Code - Autoboxing Warnings [message #1613734 is a reply to message #1613322] |
Thu, 12 February 2015 21:40 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Tom,
Of course there are many dozens of options and in the ideal world one
would generate code that respects each and every one. But the
complexity of implementing and maintaining that is high, and certainly
to high for me. I imagine this is an option that can be suppressed with
a Java annotation so one could turn it off selectively for generated code...
On 12.02.2015 16:20, Tom Schindl wrote:
> Hi Ed,
>
> I disagree with your auto-boxing statement - I have also turned on this
> as an error in our codebases because the Object => primitive type hides
> possible NPEs from you (at least you don't see them immediately).
>
> Unfortunately JDT does not allow me turn Object => primitive to an error
> while accepting primitive => Object as ok because this is not a
> dangerous operation.
>
> Finally as I understand it autoboxing is nothing more than a compiler
> trick who inserts Boolean.valueOf(), .... statements to go from
> primitive to object type so performance and bytecode sizewise generating
> this into the java code should not matter (at least until we get more
> speciliazed warnings from JDT).
>
> Tom
>
> On 11.02.15 21:20, Ed Merks wrote:
>> Stefan,
>>
>> If you generate for Java 1.5 as supported by newer EMF runtimes, it will
>> make use of features of Java 1.5 such as autoboxing (and generics).
>> There's nothing wrong with autoboxing so just turn off the warning or
>> target 1.4 and stop using generics (which is unlikely your goal).
>>
>>
>> On 11.02.2015 15:46, Stefan Lauchenauer wrote:
>>> Since I switched to a newer Eclipse (and EMF Runtime Version from 2.4 to
>>> 2.6) generated Code differs in its Boxing handling:
>>>
>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>> return isDefaultObject();
>>>
>>> used to be
>>>
>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>> return isDefaultObject() ? Boolean.TRUE : Boolean.FALSE;
>>>
>>> isDefaultObject() in both cases returns boolean. My Problem is that I
>>> have Warnings for Autoboxing enabled - now I get lots of those warnings
>>> which I didn't have when I generated code in the old Eclipse.
>>>
>>> How can I change EMFs Code generation to box variables (again)?
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generated Code - Autoboxing Warnings [message #1614769 is a reply to message #1613734] |
Fri, 13 February 2015 13:36 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
believe it or not you can do that just generate the method with
@SuppressWarnings("boxing")
Tom
On 12.02.15 22:40, Ed Merks wrote:
> Tom,
>
> Of course there are many dozens of options and in the ideal world one
> would generate code that respects each and every one. But the
> complexity of implementing and maintaining that is high, and certainly
> to high for me. I imagine this is an option that can be suppressed with
> a Java annotation so one could turn it off selectively for generated
> code...
>
>
> On 12.02.2015 16:20, Tom Schindl wrote:
>> Hi Ed,
>>
>> I disagree with your auto-boxing statement - I have also turned on this
>> as an error in our codebases because the Object => primitive type hides
>> possible NPEs from you (at least you don't see them immediately).
>>
>> Unfortunately JDT does not allow me turn Object => primitive to an error
>> while accepting primitive => Object as ok because this is not a
>> dangerous operation.
>>
>> Finally as I understand it autoboxing is nothing more than a compiler
>> trick who inserts Boolean.valueOf(), .... statements to go from
>> primitive to object type so performance and bytecode sizewise generating
>> this into the java code should not matter (at least until we get more
>> speciliazed warnings from JDT).
>>
>> Tom
>>
>> On 11.02.15 21:20, Ed Merks wrote:
>>> Stefan,
>>>
>>> If you generate for Java 1.5 as supported by newer EMF runtimes, it will
>>> make use of features of Java 1.5 such as autoboxing (and generics).
>>> There's nothing wrong with autoboxing so just turn off the warning or
>>> target 1.4 and stop using generics (which is unlikely your goal).
>>>
>>>
>>> On 11.02.2015 15:46, Stefan Lauchenauer wrote:
>>>> Since I switched to a newer Eclipse (and EMF Runtime Version from
>>>> 2.4 to
>>>> 2.6) generated Code differs in its Boxing handling:
>>>>
>>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>>> return isDefaultObject();
>>>>
>>>> used to be
>>>>
>>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>>> return isDefaultObject() ? Boolean.TRUE : Boolean.FALSE;
>>>>
>>>> isDefaultObject() in both cases returns boolean. My Problem is that I
>>>> have Warnings for Autoboxing enabled - now I get lots of those warnings
>>>> which I didn't have when I generated code in the old Eclipse.
>>>>
>>>> How can I change EMFs Code generation to box variables (again)?
>>>
>>
>
|
|
|
| Re: Generated Code - Autoboxing Warnings [message #1615300 is a reply to message #1614769] |
Fri, 13 February 2015 21:12 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Tom,
That's what I figured, so if one were very concerned/fussy, one could
manually add these to the generated code to the few methods affected or
to the whole class, if one didn't want to do it for the whole project.
On 13.02.2015 14:36, Tom Schindl wrote:
> believe it or not you can do that just generate the method with
>
> @SuppressWarnings("boxing")
>
> Tom
>
> On 12.02.15 22:40, Ed Merks wrote:
>> Tom,
>>
>> Of course there are many dozens of options and in the ideal world one
>> would generate code that respects each and every one. But the
>> complexity of implementing and maintaining that is high, and certainly
>> to high for me. I imagine this is an option that can be suppressed with
>> a Java annotation so one could turn it off selectively for generated
>> code...
>>
>>
>> On 12.02.2015 16:20, Tom Schindl wrote:
>>> Hi Ed,
>>>
>>> I disagree with your auto-boxing statement - I have also turned on this
>>> as an error in our codebases because the Object => primitive type hides
>>> possible NPEs from you (at least you don't see them immediately).
>>>
>>> Unfortunately JDT does not allow me turn Object => primitive to an error
>>> while accepting primitive => Object as ok because this is not a
>>> dangerous operation.
>>>
>>> Finally as I understand it autoboxing is nothing more than a compiler
>>> trick who inserts Boolean.valueOf(), .... statements to go from
>>> primitive to object type so performance and bytecode sizewise generating
>>> this into the java code should not matter (at least until we get more
>>> speciliazed warnings from JDT).
>>>
>>> Tom
>>>
>>> On 11.02.15 21:20, Ed Merks wrote:
>>>> Stefan,
>>>>
>>>> If you generate for Java 1.5 as supported by newer EMF runtimes, it will
>>>> make use of features of Java 1.5 such as autoboxing (and generics).
>>>> There's nothing wrong with autoboxing so just turn off the warning or
>>>> target 1.4 and stop using generics (which is unlikely your goal).
>>>>
>>>>
>>>> On 11.02.2015 15:46, Stefan Lauchenauer wrote:
>>>>> Since I switched to a newer Eclipse (and EMF Runtime Version from
>>>>> 2.4 to
>>>>> 2.6) generated Code differs in its Boxing handling:
>>>>>
>>>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>>>> return isDefaultObject();
>>>>>
>>>>> used to be
>>>>>
>>>>> public Object eGet(int featureID, boolean resolve, boolean coreType) {
>>>>> return isDefaultObject() ? Boolean.TRUE : Boolean.FALSE;
>>>>>
>>>>> isDefaultObject() in both cases returns boolean. My Problem is that I
>>>>> have Warnings for Autoboxing enabled - now I get lots of those warnings
>>>>> which I didn't have when I generated code in the old Eclipse.
>>>>>
>>>>> How can I change EMFs Code generation to box variables (again)?
>>>>
>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 03:59:23 GMT 2024
Powered by FUDForum. Page generated in 0.02852 seconds |
] 
Search
Help
Register
Login
Home
