On 1.7dr3 and current trunk the same problem and solution will by vaild

Correct patch

private boolean isConversionMatched(String sentinel, Object selectedValue){
boolean match = false;
> if (sentinel!=null && sentinel.length()==0)

else
if (selectedValue instanceof Long){

Alternative code for <f:selectItems> test purpose. Work correct with jsf 1.2.

list = new ArrayList<SelectItem>();
list.add( new SelectItem( null ,"op default",""));
list.add( new SelectItem( new Short((short)0),"op1",""));
list.add( new SelectItem( new Short((short)1),"op2",""));

For the future I suggest to remove jsf 1.1 libraries from Icefaces distribution. Libraries from jsf 1.1 got several problems with converters and validators. People thinking there are icefaces problems.

This behaviour exists in stock JSF, so I've posted this to their mailing list, and am awaiting a reply.

That is, they don't have the NumberFormatException, but when the bean has a null value in the Long getter, it won't make the corresponding empty SelectItem be selected.

My post is about ice:selectOneRadio behaviour and binding beetwen values (not selecting).
Of course sometimes first "null" item is "default" so it may be not selected.

My patch eliminate error message and different behavior of these two cases

Case 1 - this get error

<ice:selectOneRadio id="e2" styleClass="selectTag"
<f:selectItem itemValue="" itemLabel="op default" />
<f:selectItem itemValue="0" itemLabel="op1" />
<f:selectItem itemValue="1" itemLabel="op2" />
</>

Case 2 - this is ok
<ice:selectOneRadio id="e2" styleClass="selectTag"
<f:selectItems value="#

" /

class getValue

There are implications of your patch, which could deviate ICEfaces from the JSF specification, which need to be addressed. Yes, the NumberFormatException should be fixed, but I'm not sure that your patch is the way to do it. For example, you want
<f:selectItem itemValue="" itemLabel="op default" />
to behave like
list.add( new SelectItem( null ,"op default",""));
but the itemValue of case 1 is "" (empty String) and the itemValue of case 2 is null. Those are not the same values, so it's not clear to me that they should behave the same.

True, someone also can say "use converter" but it is not neccesery.

Values from array of selectItems can contain any Objects and null so f:selectItem can expect similar values.
Most users will also expect from <ice:selectItems> behaviour similar to <f:selectItems>.

Sorry if this is any duplicate but in MenuRenderer I see not correct usage of trim.
(package com.icesoft.faces.renderkit.dom_html_basic)

For "select" values users can bind any value like "test", "test ", "test " any string with spaces (especially Hibernate can get strings with spaces)
But in line 85 of MenuRenderer.java someone include trim() and returned values are changed and are not the same as rendered before.

Result of this bug are nulls and validation errors.

In attachment my patch of above two bugs.

Working patch of space and nulls problem.

I checked the EL type conversion rules, and your patch suggestion is consistent with that.

Subversion 16101
icefaces\core\src\com\icesoft\faces\renderkit\dom_html_basic\MenuRenderer.java