Rules for (Boolean) field names

I’m testing out Backendless. I’ve created a class that has several kinds of field types, several of which are boolean types with names like isBold. I’ve uploaded about 20 objects, using async Each field value in each object is explicitly set.

When looking at my uploaded data in the Backendless console I noticed that many, but not all, of my boolean fields had “null” values even though they were explicitly set to ‘false’ in my app. All the other field values (String, float, int) look correct.

On closer inspection, i also found that Backendless had changed my boolean field names by dropping the “is” that was in front of the field name. I then modified all of my boolean field names in my text class by dropping “is”. I then deleted my previously created table in Backendless and re-imported my data. The import now worked as expected.

My question: apparently it is not wise to use boolean field names that start with “is”. Are there other field name conventions that should be avoided?

Hi Loren,

I assume you’re using Java/Android. If not, please let me know.

Here’s a test I just tried:

My data object class:

package com.mbaas;

public class Foo
  private boolean funny;
  public boolean isFunny()
    return funny;

  public void setFunny( boolean funny )
    this.funny = funny;

Code which saves an instance of Foo:

    Foo foo = new Foo();
    foo.setFunny( true );
    Backendless.Data.of( Foo.class ).save( foo );

Finally, the saved object in Backendless data storage:</img>

How different is this from your example?


Mark here’s my Foo class that recreates my question. Also attached is a screenshot of the uploaded data. Notice that Backendless changed my field names by stripping out “is”. And note the “null” entries even though all of the data was explicitly set.

public class Foo {
private boolean isFunny1;
private boolean isFunny2;
private boolean isFunny3;
private boolean isFunny4;
private boolean isFunny5;
private boolean isFunny6;

public Foo() {
    // A default constructor is required.

//region Getters and Setters
public boolean isFunny1() {
    return isFunny1;

public void setIsFunny1(boolean isFunny1) {
    this.isFunny1 = isFunny1;

public boolean isFunny2() {
    return isFunny2;

public void setIsFunny2(boolean isFunny2) {
    this.isFunny2 = isFunny2;

public boolean isFunny3() {
    return isFunny3;

public void setIsFunny3(boolean isFunny3) {
    this.isFunny3 = isFunny3;

public boolean isFunny4() {
    return isFunny4;

public void setIsFunny4(boolean isFunny4) {
    this.isFunny4 = isFunny4;

public boolean isFunny5() {
    return isFunny5;

public void setIsFunny5(boolean isFunny5) {
    this.isFunny5 = isFunny5;

public boolean isFunny6() {
    return isFunny6;

public void setIsFunny6(boolean isFunny6) {
    this.isFunny6 = isFunny6;

public static Foo newInstance(boolean funny1, boolean funny2, boolean funny3,
                              boolean funny4, boolean funny5, boolean funny6) {
    Foo newFoo = new Foo();
    return newFoo;

public static void saveAsync(final Foo foo) {
    // save object asynchronously, new AsyncCallback&lt;Foo&gt;() {
        public void handleResponse(Foo response) {
            // new Contact instance has been saved

        public void handleFault(BackendlessFault fault) {
            // an error has occurred, the error code can be retrieved with fault.


public static void saveFooObjects() {
    ArrayList&lt;Foo&gt; fooArrayList = new ArrayList&lt;&gt;();
    Foo foo = newInstance(false, false, false, false, false, false);

    foo = newInstance(false, true, false, false, false, false);

    foo = newInstance(false, false, true, false, false, false);

    foo = newInstance(false, false, false, true, false, false);

    foo = newInstance(false, false, false, false, true, false);

    foo = newInstance(true, true, true, true, true, true);

    for (Foo fooObject : fooArrayList) {



Stripping out “is” is expected. Just like we strip out “get” from getXXX() to get the property name of “XXX”. These prefixes (“is”, “get”, “set”) are standard Java Bean prefixes added to the bean property names in the getters and setters, hence keeping them in the property name saved in the backend would violate the common naming convention for the Java beans.


Thanks Mark for you prompt reply. One followup question. Is Backendless deriving its field names from the class public getters and setters, or from the private field associated with the getters and setters?


We get the property names from public fields and public getters/setters.