qishibo/AnotherRedisDesktopManager · warning

Java unserialization is readonly now!

Error message

Java unserialization is readonly now!

What it means

Element UI toast deliberately returned by the Java serialization viewer's getContent() — the viewer is read-only by design. Java serialized streams (AC ED 00 05 magic) encode class descriptors and object graphs tied to specific Java classes on the JVM that wrote them; re-serializing an edited structure without the original classes is not possible from JavaScript, so the component blocks writes: getContent() always toasts 'Java unserialization is readonly now!' and returns false. Decoding for display (newContent, returning 'Java unserialize failed!' on failure) and copying raw bytes still work.

Source

Thrown at src/components/viewers/ViewerJavaSerialize.vue:31

    newContent() {
      try {
        // ref RedisInsight
        const result = (new ObjectInputStream(this.content)).readObject();

        if (typeof result !== 'object') {
          return result;
        }

        const fields = Array.from(result.fields, ([key, value]) => ({ [key]: value }));
        return { ...result, fields };
      } catch (e) {
        return 'Java unserialize failed!';
      }
    },
  },
  methods: {
    getContent() {
      this.$message.error('Java unserialization is readonly now!');
      return false;
    },
    copyContent() {
      return this.$refs.editor.getRawContent();
    },
  },
};
</script>

View on GitHub (pinned to c149855106)

Solutions

1. Treat the Java-serialize view as read-only; change the value in the Java application that owns it
2. If you must replace the value, delete the key and write new bytes produced by the JVM
3. If the payload is actually JSON or another writable format, switch the viewer mode and edit there
4. Long-term: prefer storing JSON/POJO-as-text in Redis if you need in-place edits

// viewer contract: getContent() === false blocks the write; check readonly flag first

const isWritableViewer = (viewer) => viewer.isReadOnly !== true && typeof viewer.getContent === 'function';

When it happens

Trigger: Opening a key detected as Java-serialized (e.g. written by a Java service via Jedis/Lettuce sessions or Spring Session), editing the decoded tree, and clicking save — getContent() unconditionally rejects; no input makes the write succeed.

Common situations: Java/Spring developers inspecting session or cache payloads expecting inline editing like the JSON viewer; users trying to patch a serialized enum value by hand.

Related errors

• Pickle is readonly now!
• Select a correct .proto file
• Zlib Gzip Parse Failed!
• Zlib Deflate Parse Failed!
• Zlib DeflateRaw Parse Failed!

AI-assisted analysis of qishibo/AnotherRedisDesktopManager@c149855106 (2026-08-22). Data as JSON: /api/errors/58ef6f4987bea5ff. Report an issue: GitHub.