appulse-projects / encon-java Goto Github PK

It seems there is an error with a downloading and installing the Encon's jar from Maven Central without GPG key.

It seems encon doesn't survive while decoding->encoding+serializing PIDs in format of #PID<0.639.0>

Exception:

io.appulse.encon.terms.exception.IllegalErlangTermTypeException: Class io.appulse.encon.ter
ms.type.ErlangAtom doesn't fit to term type ATOM

Steps to reproduce:

1. In Elixir: File.write!("pid.term", :erlang.term_to_binary(self))
2. On Java side:
   Read the first byte of "pid.term" file (it's 131)
3. Read the rest into ByteBuf
4. Decode bytebuf into proper java class with ErlangTerm/newInstance
5. Encode/serialize it to another ByteBuf. Get the error above.

I suspect that the atom for node name of such PID constructs with incorrect value field:

#object[io.appulse.encon.terms.type.ErlangAtom 0x1c433450 "ErlangAtom(value=nu
ll, bytes=[110, 111, 110, 111, 100, 101, 64, 110, 111, 104, 111, 115, 116], ch
arset=ISO-8859-1)"]

Starting from some point, the encon library decodes PID's incorrectly and returns previously cached PID instead of creating the new one:

"ENCON GOT: [\"#PID<0.671.0>\"]
while
JInterface got: #Pid<[email protected]>

896 is the right id of a PID that was sent from Elixir side.

Could you also ditch the caching function while creating atom return (T) ErlangAtom.cached(type, buffer) in ErlangTerm newInstance function? Just in case.

Since there is an @EqualsAndHashCode(callSuper = true) annotation on ErlangPid, type field is considered for hashcode & equals, which means otherwise identical but different in PID/NEW_PID ErlangPids would be considered different, which means we don't get replies.
I bumped into this by simply launching elixir (iex --sname foo) and then doing ping from JVM.
After building locally with hashcode() defined as

@Override
  public int hashCode() {
    return Objects.hash(descriptor, id, serial, creation);
  }

message exchange works. I can submit a PR if this is the right solution or I would be happy to hear your thoughts on this in general.

When value.length() > 65535 || !is8bitString() consider to encode such string in ErlangBinary (BINARY_EXT) rather than in list. It's way more easier to handle binaries on a erlang/elixir side. Especially when such string is somewhere inside a nested data structure.
Thanks!

The function ErlangInteger::cached is used inside string serialization mechanism. But it's internal hashing mechanism is too weak. For instance hash for ErlangInteger::cached(1273) and ErlangInteger::cached(117) in both cases is equal to 923638.

As a result the resulting string which has both symbols with code 1273 and 117 when in LIST mode becomes corrupted.

Please fix it or rather change string serialization to use non-cached constructor of ErlangInteger

Hey.
Is it possible to bump up netty version to the latest one (4.1.34.Final as for now)?