Hi guys, I must second Jochen here. That getCallerClass doesn't work anymore in an update release is unacceptable to me. As Jochen explained, there's no suitable replacement so far. We can live with getCallerClass disappearing if there's a replacement, but obviously, the @CallerSensitive "solution" is not one for us. There are additional frames in our runtime. Also we need to support multiple JDKs (5 to 8, but 8 is already broken). Especially, we don't have any replacement for @Grab which makes use of it internally. Furthermore, I suspect Class.forName and ResourceBundle.getBundle are widespread in user code and it used to work. This is not the kind of stuff that people expect to break when upgrading a JDK, and we can't tell them to rewrite their code (especially, finding the right classloader might involve more serious refactoring if it needs to be passed as a method argument).
I would strongly suggest to keep it as is in JDK 7 and discuss an alternative solution for JDK 8 that is suitable for us and the JVM (more flexibility with frame filtering). Cheers, Cédric Le 09/07/2013 08:12, Charles Oliver Nutter a écrit : > We advise our users to pass in a classloader. Class.forName's > stack-based discovery of classloaders is too magic anyway. > > In general, when there's magic happening at the JVM level that is not > possible for us to duplicate in JRuby, we warn our users away from > depending on it. > > - Charlie > > On Mon, Jul 8, 2013 at 3:33 AM, Jochen Theodorou <blackd...@gmx.org> wrote: >> Hi all, >> >> 5 days nothing... Does that mean it is like that, there is no way around >> and I have to explain my users, that Java7/8 is going to break some >> "minor" functionality? >> >> bye blackdrag >> >> -- >> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >> blog: http://blackdragsview.blogspot.com/ >> german groovy discussion newsgroup: de.comp.lang.misc >> For Groovy programming sources visit http://groovy-lang.org >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev -- Cédric Champeau SpringSource - Pivotal http://www.springsource.org/ http://www.gopivotal.com/ http://twitter.com/CedricChampeau _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
