Chat Logs

  1. johnjayjreicher: i see there are several distinctions you could make here about what constitutes 'java'
  2. jreicherI think so too.
  3. Parajreicher: early implementations of languages such as Groovy did everything through Object and magic casting, having type erasure be effectively objects everywhere didn't accidentally limit code execution in such case
  4. ParaCLR actually had lots of problems with this, especially when MS was creating F#. The CLR itself was constantly fighting against the dynamic implementation because the code wouldn't even load.
  5. ne555i have a`foo.bar = true;` that throws me «java.lang.VerifyError: Bad type on operand stack». replacing it with `foo.setBar(true);` fixes it, but would want to know if anyone has any idea what the hell may be happening
  6. nimajene555: that seems very strange, can you share some minimal reproducer?
  7. ne555nimaje: the project is an elephant inside a whale, would be hard to isolate the issue. if it helps this is the stack https://bpa.st/D75A
  8. dreamrealsounds like a version mismatch SOMEWHERE - something's compiled against a versin of something that changed. javap may help. Do you agev lombok in the mix? What's the actual type of bar, how is it declared, with no information we're flailing more than you are.
  9. dreamrealAnd your types don't match the signature of the error. Please don't obfuscate your question any more than you ABSOLUTELY have to. It LOOKS like the legajo definition changed from compilation to deployment.
  10. nimajeis foo.bar maybe private and you compiled against some other version where it is public? I fail to see another reason why foo.bar = true; would fail at run/load time instead of at compile time
  11. ne555it's a clean build and i'm changing the setter with the = to reproduce/fix at will. no lombok, but we do have some db magic that creates Proxy classes (altought foo is not marked to be managed by it)
  12. dreamrealI'm throwing a yello card on "foo.bar" as the description.
  13. dreamrealTime to chase those proxy things A LOT. Someone's doing something critically wrong, and I get that it may be privileged information, so the best we can say is *follow that freaking stack trace* with a fine-toothed comb. We'd help but "foo.bar" makes it impossible because we're doing too much assuming to be actually helpful.
  14. ParaVerifyError is also an Error, not an Exception - that implies something's fundamentally broken on a deeper level than just some method calls.
  15. dreamrealDump Legajo, foo.bar is doing direct access whereas setBar() is following a method chain, so something's right and something else is wrong. The short version is "do what works and leave the rval/lval crap to the side" but the problem suggests a more crucial problem.
  16. dreamrealThe "use setBar()" is tactical advice and papers over the problem. It gets you past that specific hump today, but let's be real, the problem's elsewhere and this does not address it at all. Fix yo crap, homes. I wish we could help, but we can't.
  17. ne555«And your types don't match the signature of the error» that bafles me more. this is the function https://bpa.st/ARCA
  18. dreamrealWhy create an OpcionesValidar... but it sounds like bar is at the wrong VISIBILITY in that OpcionesValidarFinalizacion, honestly. That's one thing. And then you have the Legajo not being assignable to the foo *type* - that's not a line 5 error.
  19. dreamrealThis is pretty clear: you may think you have a clean Legajo deployment but you do not.
  20. dreamrealI don't know offhand how you're deploying such that this is happening, or where, or why, but ... there you are. Your classes don't match the bytecode you're running, one way or the other.
  21. ne555what was trying to do. i have a `validate()` function that takes a lot of parameter according to what should and should not validate. so created the OpcionesValidar to store those parameters and simplify and make less error prone the call to the function
  22. pr3d4t0rdreamreal: Check your messages.
  23. Paranooo don't do it, it's a trap
  24. ParaHave a donut instead!
  25. jreicherPara: I'm still not following, sorry. What was "enabled" by this erasure behaviour that wouldn't have been possible without it?