> Currently, AnimalSniffer is in place to prevent this very category of
error and I'm wondering why it didn't detect the "usage" of KeySetView.
Looked at this a bit closer. Turns out, AnimalSniffer *will* detect this
issue if it actually is run. The problem is that AS apparently is not
executed by default anymore, due to the recent change to how AS is used [1].
Prior to that change, running AS was done automatically after the compileJava
task and would have reported that usage of KeySetView:
Undefined reference:
java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
in
[...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class
Unfortunately my Gradle Foo is rather limited, so I'm not sure how to
re-establish that behaviour with the new AS plug-in.
--Gunnar
[1]
https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb69d9595004ec4e462f
2015-04-01 9:39 GMT+02:00 Gunnar Morling <gun...@hibernate.org>:
> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <st...@hibernate.org>:
>
>> Just to clarify... I *think* that as long as we run the build with Java 8
>> and set the bootclasspath to 6 or 7 we should be fine.
>>
>
> Yes, setting the boot classpath to 6 (or 7) makes sure you only use
> classes present in that JDK (be it explicitly or implicitly as in the
> ConcurrentHashMap case), because it's that class library which will be used
> for compilation then. It is cumbersome to use though as you need to specify
> the location of a 6 or 7 JDK which makes the build less easily portable
> between machines.
>
> Currently, AnimalSniffer is in place to prevent this very category of
> error and I'm wondering why it didn't detect the "usage" of KeySetView. It
> really should have detected it, assuming it analyses the byte code of
> classes. But this makes me wonder now whether it only analyses the source
> code actually. Then it wouldn't be usable to prevent this sort of issue.
>
> Coding against the ConcurrentMap interface is the best way to avoid the
> issue. But of course there is no guarantee that it happens again, unless
> e.g. having a build on CI which uses 6 or 7 on its boot classpath.
>
>
>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole <st...@hibernate.org>
>> wrote:
>>
>> > Well the idea is to run the Gradle process with Java 8 (the build itself
>> > is a Java process too don't forget). We pass in the older JDK
>> specifically
>> > to be able to set the bootclasspath for compilation and the executable
>> for
>> > running tests. That's the theory.
>> >
>> > Interestingly I developed a simplified project to test these theories:
>> > https://github.com/sebersole/gradle-mixed-jdk And of course this all
>> > works there. As you'd expect right?
>> >
>> > I think the JAXB thing comes into play here as well. Gradle does not
>> have
>> > any XJC support built in, so we have to make use of its Ant support to
>> run
>> > the XJC Ant tasks for JAXB model generation. The problem there is that,
>> > afaik, there is no way to tell Gradle's AntBuilder to use a JDK other
>> than
>> > the one that launched Gradle. I think this is why we see a JAXB model
>> > defined for Java 7, rather than Java 6, because we essentially run XJC
>> with
>> > Java 8.
>> >
>> > Anyway, this certainly makes the build more complex and we definitely
>> have
>> > to think through all these scenarios. In fact after Beta1, one of my
>> todos
>> > is to build up the build "from scratch" using that gradle-mixed-jdk
>> project
>> > as a basis.
>> >
>> > In general the plan though is to run all the tests (other than
>> > hibernate-java8, obviously) with the "baseline JDK, whether that be
>> Java 6
>> > or 7.
>> >
>> > On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero <sa...@hibernate.org>
>> > wrote:
>> >
>> >> There are many similar issues discussed on the Lucene developer's
>> >> mailing list, it's an interesting read:
>> >> -
>> >>
>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>> >>
>> >> I see no alternative than to have those test jobs actually exercising
>> >> ORM with JDK6, or maybe even compile it all with JDK6 except the Java8
>> >> additional module to be compiled with JDK8 ?
>> >>
>> >>
>> >>
>> >> On 1 April 2015 at 00:36, Steve Ebersole <st...@hibernate.org> wrote:
>> >> > Ahh, seems this may be an option to work around it:
>> >> >
>> >> > <quote>
>> >> > Using the general *Map* interface in place of the concrete
>> >> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8
>> >> return
>> >> > type and will allow this code to be compiled with Java 8 and run on
>> >> Java 7.
>> >> > </quote>
>> >> >
>> >> > I had missed that part.
>> >> >
>> >> >
>> >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole <st...@hibernate.org
>> >
>> >> wrote:
>> >> >
>> >> >> When I say "internal" here, I mean internal to java classes.
>> >> >>
>> >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <
>> st...@hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >>> Nope. It just effects any code compiled with Java 8 even though
>> the
>> >> >>> change is internal. The problem is the generated bytecode
>> >> incorporates
>> >> >>> this change. Like I said, this should be compiled with 1.6
>> >> compatibility,
>> >> >>> but that is apparently not working atm. I am having a struggle
>> >> getting a
>> >> >>> mixed JDK build working "just right".
>> >> >>>
>> >> >>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev <
>> >> paranoia...@gmail.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> According to this:
>> >> >>>>
>> >> >>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094
>> >> >>>>
>> >> >>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set<K>
>> >> while
>> >> >>>> the 1.8*ConcurrentHashMap#keySet()* returns a
>> >> >>>> ConcurrentHashMap.KeySetView<K,V>`.
>> >> >>>>
>> >> >>>> I think you're using some Java8 API.
>> >> >>>>
>> >> >>>>
>> >> >>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev <paranoia...@gmail.com>:
>> >> >>>>
>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version
>> >> >>>>> java version "1.7.0_71"
>> >> >>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
>> >> >>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a
>> >> >>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu SMP
>> Thu
>> >> Mar
>> >> >>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> >> >>>>> petar@petar-ThinkPad-X1-Carbon:~$
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <st...@hibernate.org>:
>> >> >>>>>
>> >> >>>>>> What JRE are you trying to use? This error:
>> >> >>>>>>
>> >> >>>>>> java.lang.NoSuchMethodError: java.util.concurrent.
>> >> >>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/
>> >> >>>>>> ConcurrentHashMap$KeySetView;
>> >> >>>>>>
>> >> >>>>>> is indicative of an issue in cross-jre support due to a change
>> >> >>>>>> internal to java classes.
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev <
>> >> paranoia...@gmail.com
>> >> >>>>>> > wrote:
>> >> >>>>>>
>> >> >>>>>>> Thanks Steve,
>> >> >>>>>>>
>> >> >>>>>>> I managed to migrate my configuration to the new
>> >> >>>>>>> MetamodelImplementor. Now when I run the scema export I get a
>> lot
>> >> of these
>> >> >>>>>>> warning:
>> >> >>>>>>>
>> >> >>>>>>> INFO : HHH000400: Using dialect:
>> >> org.hibernate.dialect.MySQL5Dialect
>> >> >>>>>>> WARN : JDBC Driver reports it stores quoted identifiers in both
>> >> mixed
>> >> >>>>>>> and upper case
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>>
>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>>
>> >> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>>
>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel
>> >> >>>>>>> WARN : HHH000072: Duplicate joins for class:
>> >> >>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel
>> >> >>>>>>>
>> >> >>>>>>> and when I run some test I get the following exception:
>> >> >>>>>>> java.lang.NoSuchMethodError:
>> >> >>>>>>>
>> >>
>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85)
>> >> >>>>>>> at
>> >> >>>>>>>
>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882)
>> >> >>>>>>> at
>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864)
>> >> >>>>>>> at
>> >> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104)
>> >> >>>>>>> at
>> >> >>>>>>>
>> >>
>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83)
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole <st...@hibernate.org
>> >:
>> >> >>>>>>>
>> >> >>>>>>>> I am told that the bug does not affect the JBoss->Central sync
>> >> >>>>>>>> process. So at some point the artifacts should all be
>> available
>> >> in Central
>> >> >>>>>>>>
>> >> >>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole <
>> >> st...@hibernate.org
>> >> >>>>>>>> > wrote:
>> >> >>>>>>>>
>> >> >>>>>>>>> hibernate-core seems to be the only artifact that is
>> available
>> >> in
>> >> >>>>>>>>> JBoss Nexus.
>> >> >>>>>>>>>
>> >> >>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole <
>> >> >>>>>>>>> st...@hibernate.org> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>>> So apparently the artifacts / repo issue is a Nexus bug
>> that is
>> >> >>>>>>>>>> effecting the JBoss repo (and therefore us)...
>> >> >>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> As I pointed out in the announcement, I am managing the
>> >> "migration
>> >> >>>>>>>>>> guide" in source repo while I develop the Betas. See
>> >> >>>>>>>>>>
>> >>
>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md
>> >> >>>>>>>>>> As far are the new bootstrapping apis, see
>> >> >>>>>>>>>>
>> >>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>> >> >>>>>>>>>> and
>> >> >>>>>>>>>>
>> >>
>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>> >> >>>>>>>>>> paranoia...@gmail.com> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>> Hi guys,
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> I just tried the latest beta and I cannot compile my
>> project.
>> >> >>>>>>>>>>> With the
>> >> >>>>>>>>>>> latest hibernate 4.3.X I was able to do this:
>> >> >>>>>>>>>>> -------
>> >> >>>>>>>>>>> final org.hibernate.cfg.Configuration
>> configuration =
>> >> >>>>>>>>>>> getHibernateConfiguration();
>> >> >>>>>>>>>>> configuration.buildMappings();
>> >> >>>>>>>>>>> final SchemaUpdate schemaUpdate = new
>> >> >>>>>>>>>>> SchemaUpdate(configuration);
>> >> >>>>>>>>>>> -------
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> however it seems that the SchemaUpdate constructor has been
>> >> >>>>>>>>>>> removed and now
>> >> >>>>>>>>>>> a new one is added:
>> >> >>>>>>>>>>> --------
>> >> >>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) {
>> >> >>>>>>>>>>> this(
>> >> >>>>>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(),
>> >> >>>>>>>>>>> metadata );
>> >> >>>>>>>>>>> }
>> >> >>>>>>>>>>> ---------
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Also the configuration.buildMappings() method has been
>> >> >>>>>>>>>>> deprecated. Where do
>> >> >>>>>>>>>>> I get the MetadataImplementor from? Also is there any
>> >> changelog I
>> >> >>>>>>>>>>> can refer
>> >> >>>>>>>>>>> to?
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Thanks.
>> >> >>>>>>>>>>> --
>> >> >>>>>>>>>>> Regards, Petar!
>> >> >>>>>>>>>>> Karlovo, Bulgaria.
>> >> >>>>>>>>>>> ---
>> >> >>>>>>>>>>> Public PGP Key at:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>>
>> >>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >> >>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550
>> C311
>> >> >>>>>>>>>>> 0611
>> >> >>>>>>>>>>> _______________________________________________
>> >> >>>>>>>>>>> hibernate-dev mailing list
>> >> >>>>>>>>>>> hibernate-dev@lists.jboss.org
>> >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>>
>> >> >>>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> --
>> >> >>>>>>> Regards, Petar!
>> >> >>>>>>> Karlovo, Bulgaria.
>> >> >>>>>>> ---
>> >> >>>>>>> Public PGP Key at:
>> >> >>>>>>>
>> >>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >> >>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311
>> >> 0611
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> Regards, Petar!
>> >> >>>>> Karlovo, Bulgaria.
>> >> >>>>> ---
>> >> >>>>> Public PGP Key at:
>> >> >>>>>
>> >>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311
>> 0611
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Regards, Petar!
>> >> >>>> Karlovo, Bulgaria.
>> >> >>>> ---
>> >> >>>> Public PGP Key at:
>> >> >>>>
>> >>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >> >>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311
>> 0611
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev@lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
