by Dhruba Bandopadhyay on June 4, 2010
This evening I got the following exception when reflectively instantiating a class.
Caused by: java.lang.IllegalAccessException: Class foo.Baz can not access a member of class foo.Bar with modifiers ""
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) [na:1.6.0_16]
at java.lang.Class.newInstance0(Class.java:349) [na:1.6.0_16]
at java.lang.Class.newInstance(Class.java:308) [na:1.6.0_16]
at foo.bar(Baz.java:126) [build/:na]
... 90 common frames omitted
If you get this all you need to do is to make sure that the constructor of the class you are trying to instantiate is visible to the class that is doing the reflective instantiation. The empty modifier string in the exception message is confusing at first but simply means that your constructor is package private and therefore has no access modifier. If your constructor has an access modifier it will show within that string.
Credits: Troubleshooting the reflective API.
by Dhruba Bandopadhyay on May 21, 2010
There is a free event upcoming in London on Tuesday 29th June 2010 titled ‘In the brain of Greg Luck, the new EhCache 2.0.0 and Hibernate caching SPI provider – boost hibernate performance by 10x’. Although I’m not a big fan of Hibernate – EhCache is a very prevalent open source caching library and given that this talk is by the creator of EhCache it certainly seems worthwhile attending. What has made EhCache more interesting of late is that it has been taken over by Terracotta – the network attached memory vendor. On an unrelated note there also seems to be a new meetup group for Google App Engine.
by Dhruba Bandopadhyay on May 10, 2010
Lately, on the lambda-dev mailing list, dedicated to discussion on closures in jdk7, there’s been an eerie silence. With the feature complete deadline looming in two weeks members of the list have expressed concern at the lack of activity and questioned Oracle’s commitment to the cause. Alex Buckley from Sun has not been forthcoming in his responses which has only served to heighten their concern. Here are a few representative emails the last of which was sent earlier today.
Judging by the lack of activity, the secrecy on the official status and progress of the project, the feature complete deadline looming and the apparent failure to reach consensus on the list despite frenetic discussion on the topic it certainly seems to me that as time goes on it is becoming less and less likely that jdk7 will receive closures in any form whatsoever. If they do not make it into the next version of java it will indeed be a shame as closures were the feature the community was looking forward to the most.
My personal opinion is that in the light of the recent takeover of Sun by Oracle and with the release of JDK7 eagerly awaited by the community (for almost three and a half years I might add) Oracle should, at the very least, offer a degree of transparency on what they are doing and what their plans are for JDK7. As Neal Gafter points out in his most recent post to the list whatever the outcome silence sends the wrong message and I couldn’t agree more.
Update: David Flannagan has published a similar post.
Update: It seems the discussion has once again kicked off with a new proposal by Brian Goetz. However, as Stephen Coulbourne points out, the thought process that Oracle went through to reject other options and come up with this new proposal has not been transparent.
Update: There seems to have been a comment posted on the above linked blog by a member of the Oracle staff saying “There are several resources that are working on closures at Sun/Oracle. We are reviewing schedules for Java 7. As soon as we get done, we will publish those milestones as part of OpenJDK. Java is alive an kicking and so are closures in Java.”. This, if true, is great news.
Update: For those of you coming through from dzone this post is a little out of date. Discussions on closures are in full swing now on the lambda-dev mailing list so there’s less reason for concern.