Setblock signs with text put "null" on empty lines by reloading the world

For me, it doesn't matter whether the world was already created in a 1.7.x release, a 1.8.x release, a 1.8 snapshot or a 1.9 snapshot version.
In all cases the sign shows "null".

Command used: See my comment 2 above yours.

@unknown what you are asking for rather sounds like MC-85627

Like I said in my comment above commands placed by setblock still default empty lines to "null". This was also the case in 1.8.8

Confirmed for

• 15w47c

@@unknown:
Yes.
Source version: 15w47c
Last version: 15w47c
Command used:

/setblock ~ ~ ~ minecraft:standing_sign 0 replace {Text1:"Hello !"}

Affected world attached: ^sign-null.zip

It now only accepts proper json for each line and each line has to exist.
It will show as an empty sign otherwise.

Grum, that sadly did not solve the problem 😞

The problem is that empty lines are replaced with "null" which is of course not proper json. This means every sign which is placed using /setblock or /fill and that has not all lines set will have its text removed after reloading the world.

Confirmed for

• 15w51b

The reason for this is , that the readFromNBT(NBTTagCompound compound) method of the net.minecraft.tileentity.TileEntitySign class (MCP 1.8 names) receives null as parsed IChatComponent.

public void readFromNBT(NBTTagCompound compound)
{
	this.isEditable = false;
	super.readFromNBT(compound);
	
	//...
	
	for (int var3 = 0; var3 < 4; ++var3)
	{
		String var4 = compound.getString("Text" + (var3 + 1));

		try
		{
			IChatComponent var5 = IChatComponent.Serializer.jsonToComponent(var4);
			
			// Added this
			if (var5 == null) var5 = new ChatComponentText("");

			try
			{
				this.signText[var3] = ChatComponentProcessor.func_179985_a(var2, var5, (Entity)null);
			}
			catch (CommandException var7)
			{
				this.signText[var3] = var5;
			}
		}
		catch (JsonParseException var8)
		{
			this.signText[var3] = new ChatComponentText(var4);
		}
	}
	
	//...
}

@@unknown: Example command?

@unknown That's exactly what Mr. Broes/Grum said though.
Basically: "All sign lines need to exist, or it'll return COMPLETELY EMPTY now instead of that "null" thing". - and that's the fix.

I'm also not happy with the "fix", or rather I can't understand why one has to reference ALL sign lines now; it makes signs too pricey/uses up too many characters.
Is that what "strict JSON" means?

Again, command example; instead of:

setblock ~ ~1 ~ wall_sign 0 replace {
Text2:"{\"text\":\"GREEN\",\"color\":\"dark_green\",\"bold\":true}"}

I've got to insert:

setblock ~ ~1 ~ wall_sign 0 replace {
Text1:"{\"text\":\"\"}",
Text2:"{\"text\":\"GREEN\",\"color\":\"dark_green\",\"bold\":true}",
Text3:"{\"text\":\"\"}",
Text4:"{\"text\":\"\"}"}

Before, if I wouldn't reference all sign lines, (null) would appear on those not referenced lines on relog into the world.
Now it returns the whole sign completely empty on relog.

Pics attached.

Re-emphasized @unknown's comment:

It now only accepts proper json for each line and each line has to exist.
It will show as an empty sign otherwise.

@unknown I'm aware of that, that's exactly what my last comment said, that Mr. Broes said it would return empty if not each line is referenced.
I'll use more direct words to make myself clear:

I was pointing out that it doesn't seem like a >>>real fix<<< to me, but more like a "hack".
And was asking if "strict JSON" means each line MUST be referenced - which would make the "fix" not seem a "hack", but the sole possible solution of that bugfix.

That's the only thing I'd like to know - if there'd be a better bugfix solution which is not done yet due to time or general issues, hence that seemingly "hack".
E.g. preferred outcome: Not all lines have to be referenced, like it was in 1.8.x - or if that's not possible as it would conflict with what "strict JSON" means (about which I don't have a clue at all minecraftcodingwise; I'm only an user of it).

Flagged for review.

Yes, sorry I kind of skipped this part by accident. However this really does not solve the problem, like @unknown said in 1.8 not all lines had to be referenced. This means in 1.9 about 90% of the commands placing signs will not work anymore. The fix provided should solve this.
Edit: This also causes MC-87281

Personally, I'm not so much worried about old 1.8 signs showing up empty all of a sudden in 1.9.
As we got so many new cool commands and additional CommandBlocks, surely many maps have to be redone for 1.9 anyway, just think e.g. of all the laggy fillclocks we can get rid of.
Which means 1.8 maps will remain 1.8 maps, and for 1.9 considerate mapmakers will change their whole machinery/CommandBlocks as well as commands setup to make things easier for them, better, also for the sake of the players of their maps.

My concerns are mainly the "why clog up the commands and use more characters than seemingly needed".
It's bad enough we've got to use strict JSON which uses up already many more characters, so, if possible, it'd be nice if not each line has to be referenced, like in 1.8 - which would, of course, also possibly result in old 1.8 signs still working in 1.9, as @unknown mentioned.

@unknown the amount of characters used should not be the first priority in my opinion. I thought this way before as well, but knowing all exceptions for String escaping in NBT commands is just too complicated so escaping properly is way easier and also produces less problems.

The reason why they made strict JSON necessary is reasonable. This lenient JSON parsing is only something that Gson (Google's JSON parser) supports. It is not defined in the official standard. This means they would be bound to Gson and could never switch the parser they are using (and there are again all kind of exceptions when quotation is needed and when not).

And it also does not affect upgrading from 1.8 to 1.9. This works fine.