Hi Samir,
Thank you very much for finding this reproducible case *(mailing list: the
case was reported off-list)*. I have used your instructions to further
reduce the problem to type inference in context with overloading. The
following class compiles in 20 seconds, which is way too slow:
*import* *static* org.jooq.impl.DSL.*field*;
*import* org.jooq.SQLDialect;
*import* org.jooq.impl.DSL;
*public* *class* JooqQuerySnippets {
*public* *void* checkAccessToProviders() {
DSL.*using*(SQLDialect.*MYSQL*)
.select()
.where(*true*)
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
.and(*field*("client.id").eq(*field*("client_id")))
;
}
}
The problem appears to be that the many overloads of “and()” together with
the many overloads of “field()” and “eq()” seem to cause problems with
javac (but not with Eclipse!) The following snippet compiles much much
faster:
*import* *static* org.jooq.impl.DSL.*field*;
*import* org.jooq.Field;
*import* org.jooq.SQLDialect;
*import* org.jooq.impl.DSL;
*public* *class* JooqQuerySnippets {
*public* *void* checkAccessToProviders() {
Field<Object> f1 = *field*("client.id");
Field<Object> f2 = *field*("client_id");
DSL.*using*(SQLDialect.*MYSQL*)
.select()
.where(*true*)
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
.and(f1.eq(f2))
;
}
}
So, as a workaround, you could assign Field<?> references to local
variables to prevent the compiler from doing “unnecessary” type inference.
I will report these findings also to Stack Overflow, and further
investigate this in order to file a bug to Oracle. This should definitely
be fixed. I’m sure the compiler explores too big of a potential application
space during type inference phases, when it isn’t really necessary.
Thanks a lot for reporting this issue! This will bring jOOQ (and Java)
ahead in a very important area.
Best Regards,
Lukas
2015-12-07 18:14 GMT+01:00 Lukas Eder <[email protected]>:
> Thank you very much for all the additional information. I was somewhat
> hoping that you were using Eclipse, as there is a known issue in Eclipse
> related to Java 8's new type inference implementation and excessive use of
> generics (which can happen at times with the jOOQ API):
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=434326
>
> It is a rare condition, and I'm not aware of any users having run into it,
> but we have - although not with javac and/or IntelliJ
>
> Another thing that would be worth tracking down is whether the issue is
> related to any specific API usage. One approach to track down such an issue
> would be to remove half of your code to see if the issue persists. As long
> as it persists, keep removing half of your code. Once the issue disappears,
> look in the other half, until you are able to track down the issue to
> perhaps an individual statement or set of statements. If there isn't any
> such issue in the javac related to specific API usage, I'd expect
> compilation time decrease to be directly proportional to code size
>
>
>
> 2015-12-07 9:45 GMT+01:00 Samir Faci <[email protected]>:
>
>> To answer your other questions I missed earlier.
>>
>> Digging a bit deeper into this.
>>
>> mip-service-container contains a db-schema artifact.
>>
>> db-schema essentially inspects the DB schema and autogenerates the java
>> classes and packages everything up.
>>
>> That project seems to work just fine.
>>
>> Then when I try to build mip-service container (both of projects are
>> naturally on the same version of jooq) it gives me the excessively long
>> compilation times.
>>
>> The mip-service container essentially defines the core of our services,
>> brings in some spring magic, jersey server and such. guava, apache
>> commons, and a bunch of open source libraries that are fairly typical.
>>
>> as far as where it freezes, it's a the compilation step as seen below.
>> That's the last line I see 'till it catches up again.
>>
>> [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @
>> mip-service-container ---
>> [INFO] Compiling 44 source files to
>> /home/user/projects/work/neuak/mip-service-container/target/classes
>>
>>
>>
>> On Sun, Dec 6, 2015 at 11:42 PM, Lukas Eder <[email protected]> wrote:
>>
>>> Hi Samir,
>>>
>>> That is indeed very weird, and the first time I hear this kind of issue.
>>> 1:30 minutes is certainly far from an acceptable compilation time, even for
>>> larger projects. How do you build your project (Maven version, IDE version,
>>> Java version, pom.xml config)? And what part of building takes so long
>>> (e.g. is code generation involved)? Does this happen both when building on
>>> the command line (mvn clean install) *and* in your IDE?
>>>
>>> Best,
>>> Lukas
>>>
>>> 2015-12-06 20:59 GMT+01:00 Samir Faci <[email protected]>:
>>>
>>>> I'm experiencing a very odd behavior when trying to upgrade the jooq
>>>> version in a small project, and I was wondering if anyone could provide any
>>>> insight.
>>>>
>>>> I am currently using Jooq verion 3.5.1 without any problems and I tried
>>>> to update to the latest 3.7.1 (seemed worthwhile lots of great features
>>>> listed).
>>>>
>>>> When I bump up the version maven fails to return on the compilation
>>>> step. It takes an abnormally long time to complete.
>>>>
>>>>
>>>> For example:
>>>> My project has 66 java files, there aren't really any class files that
>>>> are 10K lines of code or anything out there.
>>>>
>>>> - with 3.7.1, Total time: 01:31 min
>>>> - with 3.5.1 Total time: 2.144 s
>>>>
>>>> This behavior has started with Jooq 3.6.0, I can bump up the version
>>>> all the way up to 3.5.4 and the project is still responsive, but when I go
>>>> to 3.6 it completely unreasonable.
>>>>
>>>> I'm trying to pull jooq into a 'core' component that will be consumed
>>>> by a larger project. So if the core just went from 3 seconds to 1.5
>>>> minutes I can't imagine being able to make this upgrade as it stands.
>>>>
>>>> Does anyone have any insights on what could be causing this, or any
>>>> assistance in helping me debug this. As I said the only change I'm making
>>>> is the version number on jooq, so I have a feeling something
>>>> between what my project is using (lib wise), JVM version and Jooq
>>>> itself is causing this, but I'd love some ideas on how to resolve this.
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you
>>>> Samir Faci
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "jOOQ User Group" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "jOOQ User Group" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Thank you
>> Samir Faci
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
