NoSuchMethodException in HEAD-SNAPSHOT has been removed, breaking knightsoft gwt-bean-validators

[stuckagain]

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 mention that this was discussed:

https://github.com/gwtproject/gwt/commit/329b21962075c675d1a2e2b3d48049ca5e9fe195

This is what I get now when compiling:

[INFO] Compiling module com.swift.cloud.platform.ui.demo.Demo
[INFO]    Tracing compile failure path for type 'org.apache.commons.beanutils.PropertyUtils'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/apache/commons/beanutils/PropertyUtils.java'
[INFO]          [ERROR] Line 56: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    Tracing compile failure path for type 'de.knightsoftnet.validators.shared.util.BeanPropertyReaderUtil'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/mt-bean-validators/1.0.0/mt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/shared/util/BeanPropertyReaderUtil.java'
[INFO]          [ERROR] Line 60: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    Tracing compile failure path for type 'java.net.URL'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/java/net/URL.java'
[INFO]          [ERROR] Line 958: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    Tracing compile failure path for type 'org.hibernate.validator.internal.util.logging.Log'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/hibernate/validator/internal/util/logging/Log.java'
[INFO]          [ERROR] Line 415: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    Tracing compile failure path for type 'de.knightsoftnet.validators.client.impl.AbstractGwtValidator'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/client/impl/AbstractGwtValidator.java'
[INFO]          [ERROR] Line 144: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    Tracing compile failure path for type 'org.apache.commons.beanutils.BeanUtils'
[INFO]       [ERROR] Errors in 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validators/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/supersource/org/apache/commons/beanutils/BeanUtils.java'
[INFO]          [ERROR] Line 48: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module?
[INFO]    [ERROR] Aborting compile due to errors in some input files

I wonder what the impact is of this change to other libraries out there. I'll file a bug report on knightsoft's implementation, but what about libs that are no longer maintained that might refer to this exception class ?

[Jens]

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 emulated apache commons classes they are part of the method signature.

-- J.

[Colin Alworth]

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 throw? It has always had a private constructor to make that completely impossible.

I checked out the project so I could offer a pull request with the two different approaches that could be used to fix this, but it doesnt appear that the project builds out of the box - javadoc errors that are fatal just for a plain mvn install or mvn package. Stepping down to just mvn compile (so I could attempt to build, but never actually use it) then encounters a dependency-check issue. Any advice you can offer on building my own copy to contribute these fixes right away?

Approach one: "super source" this exception - validators already require some super source, so there should already be a clear place to put this in the project.

Approach two: stop indicating that methods could throw this, or that try/catch blocks could catch it, since it wasn't possible to throw anyway. Any emulated java code cannot have this exception naturally (no classloader, no classes loaded from disk, etc), and as I mentioned, it has a private constructor.

Like I said, I'd be very glad to collaborate and build these patches and get them merged so we can get this resolved.

[Colin Alworth]

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?

Or is this a case of "it isn't a runtime exception, so the _calling_ code must then declare the catch statement"? I'm still waking up, might not be fully clear here...

[Jens]

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 other emulated code, then it kind of depends on how JDT behaves I guess.

But honestly, it is just an exception and I would simply add it to GWT emulation. Done. It is always preferable to have a single emulation within GWT proper instead of one emulation per project that needs it with various degrees of implementation quality.

-- J.

[Goktug Gokdogan]

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 corner cases is just a minor inconvenience for the end user.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/188c7862-b408-467c-a140-4383cd619ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Manfred Tremmel]

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 NoSuchMethodException on client side.
Without this emulation I wouldn't be able use validation routines which need
more input fields like MustBeEqual (https://gitlab.com/ManfredTremmel/gwt-bean-validators/blob/master/mt-bean-validators/src/main/java/de/knightsoftnet/
validators/shared/impl/MustBeEqualValidator.java).

cu
Manfred

> > urce/org/apache/commons/beanutils/PropertyUtils.java' [INFO]

> > [ERROR] Line 56: No source code is available for type
> > java.lang.NoSuchMethodException; did you forget to inherit a required
> > module?
> > [INFO] Tracing compile failure path for type
> > 'de.knightsoftnet.validators.shared.util.BeanPropertyReaderUtil'
> > [INFO] [ERROR] Errors in
> > 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/mt-bean-validators
> > /1.0.0/mt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/shared/ut

> > il/BeanPropertyReaderUtil.java' [INFO] [ERROR] Line 60: No source

> > code is available for type java.lang.NoSuchMethodException; did you
> > forget to inherit a required module?
> > [INFO] Tracing compile failure path for type 'java.net.URL'
> > [INFO] [ERROR] Errors in
> > 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validator
> > s/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/superso

> > urce/java/net/URL.java' [INFO] [ERROR] Line 958: No source code

> > is available for type java.lang.NoSuchMethodException; did you forget to
> > inherit a required module?
> > [INFO] Tracing compile failure path for type
> > 'org.hibernate.validator.internal.util.logging.Log'
> > [INFO] [ERROR] Errors in
> > 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validator
> > s/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/superso

> > urce/org/hibernate/validator/internal/util/logging/Log.java' [INFO]

> > [ERROR] Line 415: No source code is available for type
> > java.lang.NoSuchMethodException; did you forget to inherit a required
> > module?
> > [INFO] Tracing compile failure path for type
> > 'de.knightsoftnet.validators.client.impl.AbstractGwtValidator'
> > [INFO] [ERROR] Errors in
> > 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validator
> > s/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/client/

> > impl/AbstractGwtValidator.java' [INFO] [ERROR] Line 144: No

> > source code is available for type java.lang.NoSuchMethodException; did
> > you forget to inherit a required module?
> > [INFO] Tracing compile failure path for type
> > 'org.apache.commons.beanutils.BeanUtils'
> > [INFO] [ERROR] Errors in
> > 'jar:file:/home/dnouls/.m2/repository/de/knightsoft-net/gwt-bean-validator
> > s/1.0.0/gwt-bean-validators-1.0.0.jar!/de/knightsoftnet/validators/superso

> > urce/org/apache/commons/beanutils/BeanUtils.java' [INFO] [ERROR]

[Jens]

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 totally fine with Colins change, because:

1.) It is more correct emulation

2.) It is very simple code, so it is not a maintenance burden

3.) Single source of trust if its inside GWT emulation.

4.) Reflection based code can be emulated to some extend using Generators/APT so it is not super unlikely nobody uses these exceptions. If Google does not use it, fine, others might do and for them it is a real breaking change which stops them from upgrading GWT.

5.) It reduces the noise when using diff tools between GWT emulation and JDK to a.) discover newly added APIs in JDK and b.) verify existing emulated APIs still match JDK APIs.

 

I think IDE warnings in couple of corner cases is just a minor inconvenience for the end user.

I don't think 2 classes with each 3 lines of real code outweighs the happiness of end users.

-- J.

[Jens]

 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.

[Goktug Gokdogan]

It is not a problem of a single class by itself. It is a problem of policy and opening the gate for much more. Without a good justification to make an exception in the policy, we get bombarded with emulation requests (most you don't even see) that have zero or very little value. Inconsistency doesn't help with that. Why do we have NoSuchMethodException but not other dozens of similar classes used in this library?

So why do we have such policy?

 - There is a consistent cost of transpilation, bundling, optimization etc. for having an extra classes in emulation. Currently emulation already reached to 7MBs.

 - Impossible code paths (e.g. catching an exception that will be never thrown from our emulation) are source of potential bugs.

So we usually ask for a good justification to add such emulation.

In this particular case I don't see generators that mimic reflection as such a case - it would need a lot more not only this class and it is fine in such case for them to provide the emulation. 

BTW, I only refer to Google code because it is usually a good reference point from statistical point of view since it includes plenty of common 3rd party GWT libs; not because it is special.

If this removal becomes an upgrade burden, we can consider putting it back but I don't see couple of simple cases as a real upgrade issue. This particular library could either add it, like it is already doing other relevant classes or just change the internal API. We should wait and if there are more concerns.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/86cb9f50-6679-4dc3-b441-c92808726bb9%40googlegroups.com.

[Manfred Tremmel]

For me (and gwt-bean validators) it doesn't matter if I include
NoSuchMethodException myself or if it's part of gwt. I only have to know, how
to handle it for next release.