My Google App Engine didn't get around it. Well, I don't think it did. In my app.yaml I have the add-opens:
runtime: java17 instance_class: F1 entrypoint: java --add-opens java.base/java.lang=ALL-UNNAMED -Xms150m -Xmx350m -jar drift-team.war On Monday 24 June 2024 at 2:23:33 am UTC+10 Tim Macpherson wrote: > Thanks Colin, so this is an issue that is ongoing. Still wondering how > app engine deployment get around it. > > Yahoo Mail: Search, Organize, Conquer > <https://mail.onelink.me/107872968?pid=NativePlacement&c=Global_Acquisition_YMktg_315_EmailSignatureGrowth_YahooMail:Search,Organize,Conquer&af_sub1=Acquisition&af_sub2=Global_YMktg&af_sub3=&af_sub4=100000945&af_sub5=OrganizeConquer__Static_> > > On Sat, Jun 22, 2024 at 7:49 PM, Colin Alworth > <[email protected]> wrote: > > GWT-RPC's purpose is to enable serialization of objects to and from the > server. Usually, those types either are written by the application authors, > or have well supported interfaces to interact with them, but there are > exceptions (Throwable, as you first noted, and LinkedHashMap has one of the > other main ones I can think of). > > As we know it today, GWT-RPC was written for around Java 1.5 - reflection > was not desirable even then because it was slow, but JPMS was many years > away from being considered. > > For Throwable, we serialize this in two main cases: sending logs to the > server so client errors can be tracked, solved, and sending errors to the > client so they know an operation has failed in some way. So, we need to > both read and write the `detailMessage` field of throwable - and there is > no guaranteed way to either read _or_ write this without reflection. > Reading example: a custom exception type could override getMessage() and > make use of super.getMessage(), so the private field is needed but cannot > be read directly. Writing example: a custom exception type could exist that > calls super(String) but doesn't pass in a constructor argument directly, so > the detailMessage field can't be reliably written. > > If this is unacceptable, the best option would be to define a > CustomFieldSerializer for Throwable and supported subtypes that have their > own fields, and deal with the exceptions described above as you see fit, by > deciding how to handle the loss of data in those cases. GWT doesn't make > this decision for you. > > For LinkedHashMap the `accessOrder` constructor argument is effectively > hidden state - there is no nice way to interogate a LinkedHashMap to ask if > it is based on insertion or access order directly. There is a not-very-nice > way though, and this is what GWT does if reflection is not available (clone > the collection, clear the clone, insert two keys, access the second, > iterate to see which was first). This is why I was asking about GWT 2.11, > which has this a fix to better handle Java 17 (see > https://github.com/gwtproject/gwt/pull/9791): > > https://github.com/gwtproject/gwt/blob/2.11.0/user/src/com/google/gwt/user/client/rpc/core/java/util/LinkedHashMap_CustomFieldSerializer.java#L107-L152 > > You should not need to apply a workaround via more reflection - this will > fail the first time it is attempted, and track that for future reference, > so the error will only happen once. > > For both of these cases, we have to decide what it means to not have > access to this data, and how likely these internals are to change. Is > Throwable going to lose its detailMessage? Is LinkedHashMap going to change > how accessOrder works? Especially for just two cases, the answer is very > likely no, and we run CI with GWT (including tests for serialization for > these types) against so-called LTS JDKs and the current latest version, so > that if they do change, we know about it. > > > On Saturday, June 22, 2024 at 5:07:19 AM UTC-5 [email protected] > wrote: > > How to solve InaccessibleObjectException ("Unable to make {member} > accessible: module {A} does not 'opens {package}' to {B}") on Java 9? > <https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m> > > touches on the issue: > Using --add-opens should be considered a workaround. > The right thing is for libraries performing illegal access to fix their > issues. > > > https://www.reddit.com/r/java/comments/p9ymhb/what_exactly_is_the_reason_for_denying_reflection > > reflection removes encapsulation: makes every element in a code unit part > of its API > Strong encapsulation aids in maintainability and security. > > > https://blogs.oracle.com/javamagazine/post/a-peek-into-java-17-continuing-the-drive-to-encapsulate-the-java-runtime-internals > > The result is a user class that is tightly coupled to the internal > implementation of the JDK. > If enough developers abuse this openness, this leads to a situation in > which it is difficult or impossible > to make changes to the internals, because to do so would break deployed > libraries and applications. > This is one of the problems that modules were invented to solve. > > > I have found: > > On app engine there's no need for --add-opens > java.base/java.lang=ALL-UNNAMED, only on local jetty. > This java fix for LinkedHashMap reflection failure is probably more > worrying: > ... > Field field = > LinkedHashMap_CustomFieldSerializer.class.getDeclaredField("reflectionHasFailed"); > field.setAccessible(true); > ... > > > > On Saturday 22 June 2024 at 02:53:52 BST, Craig Mitchell < > [email protected]> wrote: > > > This is because, from Java 9, access to the Java classes has been > restricted. More info: > https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m > > In the case of GWT, if you want exceptions passed back via RPC, GWT needs > access to the java.lang classes to serialise them to contain all the Java > class details. > > So, you need to add: --add-opens java.base/java.lang=ALL-UNNAMED when > running. > > I didn't know it was not recommended. Why is it bad to do? > > On Saturday 22 June 2024 at 3:34:59 am UTC+10 Tim Macpherson wrote: > > It happens with the latest tbroyer archetype, just change the server > method so it always throws > > Yahoo Mail: Search, Organize, Conquer > <https://mail.onelink.me/107872968?pid=NativePlacement&c=Global_Acquisition_YMktg_315_EmailSignatureGrowth_YahooMail:Search,Organize,Conquer&af_sub1=Acquisition&af_sub2=Global_YMktg&af_sub3=&af_sub4=100000945&af_sub5=OrganizeConquer__Static_> > > On Fri, Jun 21, 2024 at 4:20 PM, Colin Alworth > <[email protected]> wrote: > > Can you share a little more detail, like the full error message with stack > trace, and the GWT version you're using? Some improvements were made in > this area for GWT 2.11, and some messages of this kind are merely warnings, > indicating that reflection was attempted and some fallback can usually be > used instead. > > On Friday, June 21, 2024 at 8:45:59 AM UTC-5 [email protected] wrote: > > SInce upgrading to Java 11, throwing a new IllegalArgumentException in an > RPC server-side implementation gives InaccessibleObjectException. It can > be stopped by using a VM argument --add-opens, but apparently this is not > recommended. > Can anyone clarify ? > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/google-web-toolkit/6c4d8967-066c-4f36-a95f-9bf8df2e2589n%40googlegroups.com > > <https://groups.google.com/d/msgid/google-web-toolkit/6c4d8967-066c-4f36-a95f-9bf8df2e2589n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/google-web-toolkit/0a0af252-eb15-4c39-9ecb-dc8b1cb09da3n%40googlegroups.com > > <https://groups.google.com/d/msgid/google-web-toolkit/0a0af252-eb15-4c39-9ecb-dc8b1cb09da3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "GWT Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/google-web-toolkit/79fa64e5-29bf-4ab5-becd-b25f0cfbe79bn%40googlegroups.com > > <https://groups.google.com/d/msgid/google-web-toolkit/79fa64e5-29bf-4ab5-becd-b25f0cfbe79bn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/f839b75e-9504-4768-9480-00c6e246f7e3n%40googlegroups.com.
