-
Bug
-
Resolution: Fixed
-
P4
-
jfx12, jfx13
-
x86_64
-
generic
A DESCRIPTION OF THE PROBLEM :
JavaFX still spits out too many false warnings in case you use select-binding
and you have a dynamic model with many properties that can be set to null from time to time.
This is completely normal behaviour and should not cause any warnings at all. It is just annoying
and clutters your log-files so that you do not see real warnings anymore between all that garbage.
See also: https://github.com/javafxports/openjdk-jfx/issues/383
This issue was already addressed a long time ago in
https://bugs.openjdk.java.net/browse/JDK-8097814
but was not solved completely. You still get lots of warnings like this:
Feb. 20, 2019 10:43:05 VORM. com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
WARNING: Exception while evaluating select-binding [viewport]
The problem is here in SelectBinding$SelectBindingHelper.getObservableValue():
} catch (RuntimeException ex) {
final PlatformLogger logger = Logging.getLogger();
if (logger.isLoggable(Level.WARNING)) {
Logging.getLogger().warning("Exception while evaluating select-binding " + stepsToString());
if (ex instanceof IllegalStateException) {
logger.warning("Property '" + propertyNames[i] + "' does not exist in " + obj.getClass(), ex);
} else if (ex instanceof NullPointerException) {
logger.fine("Property '" + propertyNames[i] + "' in " + properties[i] + " is null", ex);
} else {
Logging.getLogger().warning("", ex);
}
}
// return default
updateDependencies();
return null;
}
This should be changed to:
} catch (RuntimeException ex) {
final PlatformLogger logger = Logging.getLogger();
if (logger.isLoggable(Level.WARNING)) {
String msg = "Exception while evaluating select-binding " + stepsToString();
if (ex instanceof IllegalStateException) {
logger.warning(msg);
logger.warning("Property '" + propertyNames[i] + "' does not exist in " + obj.getClass(), ex);
} else if (ex instanceof NullPointerException) {
logger.fine(msg);
logger.fine("Property '" + propertyNames[i] + "' in " + properties[i] + " is null", ex);
} else {
logger.warning(msg, ex);
}
}
// return default
updateDependencies();
return null;
}
I extracted the common message into a String and then moved the actual logging into
the if-block which handles the different exception types so that the logging of the
common message happens with the same level as the rest of the logging for this
exception type. In addition I replaced some useless references to Logging.getLogger()
with just logger because we have that already. Furthermore I combined the log output
of the else branch into a single logger call because having two separate ones does
not seem to be reasonable in this case.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a select-binding to some property and then set the corresponding value to null.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
There should not be any annoying warnings about this completely normal action which is also handled correctly by JavaFX.
ACTUAL -
A bunch of annoying warnings.
CUSTOMER SUBMITTED WORKAROUND :
None but I provided the fix in the bug-description.
FREQUENCY : always
JavaFX still spits out too many false warnings in case you use select-binding
and you have a dynamic model with many properties that can be set to null from time to time.
This is completely normal behaviour and should not cause any warnings at all. It is just annoying
and clutters your log-files so that you do not see real warnings anymore between all that garbage.
See also: https://github.com/javafxports/openjdk-jfx/issues/383
This issue was already addressed a long time ago in
https://bugs.openjdk.java.net/browse/JDK-8097814
but was not solved completely. You still get lots of warnings like this:
Feb. 20, 2019 10:43:05 VORM. com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
WARNING: Exception while evaluating select-binding [viewport]
The problem is here in SelectBinding$SelectBindingHelper.getObservableValue():
} catch (RuntimeException ex) {
final PlatformLogger logger = Logging.getLogger();
if (logger.isLoggable(Level.WARNING)) {
Logging.getLogger().warning("Exception while evaluating select-binding " + stepsToString());
if (ex instanceof IllegalStateException) {
logger.warning("Property '" + propertyNames[i] + "' does not exist in " + obj.getClass(), ex);
} else if (ex instanceof NullPointerException) {
logger.fine("Property '" + propertyNames[i] + "' in " + properties[i] + " is null", ex);
} else {
Logging.getLogger().warning("", ex);
}
}
// return default
updateDependencies();
return null;
}
This should be changed to:
} catch (RuntimeException ex) {
final PlatformLogger logger = Logging.getLogger();
if (logger.isLoggable(Level.WARNING)) {
String msg = "Exception while evaluating select-binding " + stepsToString();
if (ex instanceof IllegalStateException) {
logger.warning(msg);
logger.warning("Property '" + propertyNames[i] + "' does not exist in " + obj.getClass(), ex);
} else if (ex instanceof NullPointerException) {
logger.fine(msg);
logger.fine("Property '" + propertyNames[i] + "' in " + properties[i] + " is null", ex);
} else {
logger.warning(msg, ex);
}
}
// return default
updateDependencies();
return null;
}
I extracted the common message into a String and then moved the actual logging into
the if-block which handles the different exception types so that the logging of the
common message happens with the same level as the rest of the logging for this
exception type. In addition I replaced some useless references to Logging.getLogger()
with just logger because we have that already. Furthermore I combined the log output
of the else branch into a single logger call because having two separate ones does
not seem to be reasonable in this case.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a select-binding to some property and then set the corresponding value to null.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
There should not be any annoying warnings about this completely normal action which is also handled correctly by JavaFX.
ACTUAL -
A bunch of annoying warnings.
CUSTOMER SUBMITTED WORKAROUND :
None but I provided the fix in the bug-description.
FREQUENCY : always