> It has always had a private constructor to make that completely
> impossible.
>
Private constructor? Looks like it always was public as it should.
https://github.com/gwtproject/gwt/blob/2.8.2/user/super/com/google/gwt/emul/java/lang/NoSuchMethodException.java
-- J.
--
You received this
> I agree this is mostly a misuse like you said. We don't have any internal
> usage in all Google either so I would rather push users to not
> declare/catch such exceptions. Keeping such classes opens the door for
> more: https://gwt-review.googlesource.com/c/gwt/+/21320
>
Actually I am total
Hi together,
the original validation code has no reflection emulation for accessing getters.
In gwt-bean-validators you can simply use
org.apache.commons.beanutils.PropertyUtils.getProperty(Object, String) and
org.apache.commons.beanutils.BeanUtils.getProperty(Object, String) which both
throw
I agree this is mostly a misuse like you said. We don't have any internal
usage in all Google either so I would rather push users to not
declare/catch such exceptions. Keeping such classes opens the door for
more: https://gwt-review.googlesource.com/c/gwt/+/21320
I think IDE warnings in couple of c
It is not a RuntimeException so even though you might be able to remove it
from GWT emulation code, your IDE will still annoy you in calling code to
either catch that exception or redeclare it because your IDE does not know
that GWT emul is cheating. If that calling code is exclusively within ot
I believe that the reason this class existed to begin with was to allow
(for some reason..) RPC to serialize that exception and pass it to client
code. But emulation that "needs" it to match the correct signature can
safely remove it from a "throws" clause without breaking the contract,
correct
Thanks for the heads up - it was removed since it isn't possible to throw
in client code anyway, and projects could emulate it themselves if
necessary. I'm curious about why gwt-bean-validators must have it, as the
original validator code did not have it - is it expecting it to be possible
to t
I would say this change should be reverted in GWT then. Personally I would
never ever delete any already emulated class in GWT.
While this exception has been misused in some of the above code (e.g.
URL.openStream() should not be emulated at all or throw
UnsupportedOperationException), in the em
Hi,
I just noticed this morning that our project fails to build this morning
due to a change in HEAD-SNAPSHOT.
We are using knightsoft gwt-bean-validators and its source is apparently
depending on the fact that GWT is emulating the NoSuchMethodException.
I saw this commit where there is a ment
