Remove serialization workarounds for ie 6/7 and rhino (#9578)

[codemasterover9000]

Removed the workarounds for IE6/7 issues and rhino. IE 6/7 are not relevant anymore today. Not sure if this is the rhino issue referenced in the code: https://bugzilla.mozilla.org/show_bug.cgi?id=179068. But it seems to have been fixed a long time ago.

Fixes #9578

[niloc132]

Thanks for taking this on, legacy code can be a slog to remove... I will note for posterity that at least up to IE9 (and I think 10?) there is some memory leak that occurs in this code as well, but I can't remember the specifics - but since even IE11 is effectively dead, we should go ahead and ignore this.

---

It looks like this still leaves the eval() call in the client code, if the server ends up sending version < 8 (and the default is 7), see

gwt/user/super/com/google/gwt/user/translatable/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java

Lines 61 to 64 in 0654587

	if (readVersion(encoded) < SERIALIZATION_STREAM_JSON_VERSION) {
	// Versions prior to 8 uses almost JSON with Javascript is special cases; e.g., using ].concat([,
	// non-stringified NaN/Infinity or ''+'' concatenated strings.
	results = eval(encoded);

and

gwt/user/src/com/google/gwt/user/client/rpc/impl/AbstractSerializationStream.java

Line 50 in 2b23c5e

public static final int SERIALIZATION_STREAM_VERSION = 7;

I can see an argument for removing this in phases, so that old clients will still work - but if that's the plan, I'd want to consider bumping the SERIALIZATION_STREAM_VERSION to 8, and warning on old versions.

Also: the rhino notes are about the legacy dev mode implementation of gwt-rpc (to avoid needing to emulate all the string operations in JS). It is technically possible that this will break GWTTestCase for htmlunit "hosted mode" tests (hosted mode == legacy dev mode)

gwt/user/src/com/google/gwt/user/client/rpc/impl/ClientSerializationStreamReader.java

Lines 70 to 75 in 2b23c5e

	* The payload is almost a JSON literal except for some nuances, like unicode and array concats.
	* We have a specialized devmode version to decode this payload, because the webmode version
	* requires multiple round-trips between devmode and the JSVM for every single element in the
	* payload. This can require several seconds to decode a single RPC payload. The RpcDecoder
	* operates by doing a limited JS parse on the payload within the devmode VM using Rhino,
	* avoiding the cross-process RPCs.

.

To deal with that and still kill this old code, I'd consider removing the linked file above and replacing it with the supersource version (the second link in this reply, except with the @GwtScriptOnly removed, and javadoc updated to indicate that it is no longer supersourced).

What do you think?

[niloc132]

As long as we're updating this, consider replacing StringBuffer with StringBuilder for better single-threaded performance? From https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StringBuffer.html

As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

[codemasterover9000]

I updated to use StringBuilder instead of StringBuffer and changed the default serialization format to JSON.

I'm not sure how best to implement the rest of your suggestions though. But they seem logical.

[jnehlmeier]

This can be removed. The same loop definition is in the line above.

[codemasterover9000]

Removed the extra loop

[lgemeinhardt]

Any chance to get this PR in the next release (because this enabled a CSP w/o "unsafe-eval")?

[niloc132]

Anyone who wants to pick this up and continue it, removing other related dead code, would be welcome to do so. I don't presently have a plan to take this on, so we're looking for a contributor or sponsor to focus on it. See notes in my review above for other steps that should be taken to correct this more than superficially.