You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Blake Watson <bl...@pnmac.com> on 2018/01/05 21:36:14 UTC
Can't compile EvaluationConditionalFormatRule
When I try to compile EvaluationConditionalFormatRule.java I get an error:
**************************
Error:(348, 40) java: method isValid in enum
org.apache.poi.ss.formula.EvaluationConditionalFormatRule.OperatorEnum
cannot be applied to given types;
required: C,C,C
found: java.lang.Double,java.lang.Double,java.lang.Comparable
reason: inference variable C has incompatible bounds
equality constraints: java.lang.Double
lower bounds: java.lang.Comparable,java.lang.Double
**************************
Am I missing a compile switch somewhere? I'm just trying to compile that
particular file from inside IntelliJ.
--
*Blake Watson*
*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.watson@pnmac.com
www.PennyMacUSA.com <http://www.pennymacusa.com/>
Re: Can't compile EvaluationConditionalFormatRule
Posted by Greg Woolsey <gr...@gmail.com>.
Looks like I should update my local JDK anyway, it's out of date, I'll see
what that says Monday.
As for asking the conditional rules what cells they cover, and then only
checking those cells, that may be faster. I tried to have it fail fast if
the cell in question is not in a range covered by a rule, but perhaps there
is more to it than that. I've seen some interesting performance things pop
up when digging into POI execution timing in the past, wouldn't surprise me
to find out there is room for optimization somewhere in this part too.
On Fri, Jan 5, 2018 at 8:29 PM Blake Watson <bl...@pnmac.com> wrote:
> For completeness purposes, I should say that the language level in IntelliJ
> is 8. The JDK in use is 1.8.0_131 which I believe is the official Oracle
> release.
>
> And this is line being objected to:
>
> return op != null && op.isValid(val, comp, (Comparable)null);
>
>
> On Fri, Jan 5, 2018 at 8:05 PM, Blake Watson <bl...@pnmac.com>
> wrote:
>
> > On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey <gr...@gmail.com>
> > wrote:
> >
> >> for getRules() you can just create your own subclass and override it
> with
> >> a
> >> public version that returns super.getRules()
> >>
> >
> > That is precisely what I did, yes. And then I hit the matches thing.
> >
> > for matches, I don't see a quick easy way to override. What rule
> >
> >> definition seems to be slow, and what range does it cover? There are
> >> definitely some formulas that take longer to evaluate than others -
> >> especially things that do lookups or evaluate over an entire column
> range.
> >> Could be something else as well.
> >>
> >
> > Well, I don't know. I'm not working in Java so I was trying to bring as
> > much as possible into Clojure (in which I am working, to state the
> > implicitly obvious).
> >
> >
> >> Right now there is no easy way to shortcut the logic for a range when
> the
> >> formula is static (has no references relative to the specific range cell
> >> being evaluated, meaning the formula has the same result independent of
> >> "current" range cell). That kind of optimization hasn't even been
> >> discussed yet, and reliably guaranteeing the code wouldn't miss a case
> is
> >> probably non-trivial. Might even make it more expensive than it's worth
> >> unless the range is large and has a large number of non-empty cells.
> >> Patches welcome, of course ;D
> >
> >
> > If I had a set up with profiler working in Java and moved the Clojure
> > code into Java I could maybe work out the precise problem but I'm kind
> of
> > under the gun on this one. I =am= working on getting a good Java set up
> and
> > burnishing my Java skills because I do want to contribute back to POI.
> That
> > said, this probably isn't the issue.
> >
> > I came up with an alternate plan which I had temporarily forgotten in
> > trying to get all this other stuff to work: Instead of asking each cell
> > what conditionals apply, asking the sheet about all the conditionals that
> > apply and getting back a list of those conditionals with the cells
> > affected . I'm guessing that would be (could be?) a lot faster.
> >
> > ===Blake===
> >
> >
>
>
> --
>
> *Blake Watson*
>
> *PNMAC*
> Application Development Manager
> 5898 Condor Drive
> Moorpark, CA 93021
> (805) 330.4911 x7742 <(805)%20330-4911>
> blake.watson@pnmac.com
> www.PennyMacUSA.com <http://www.pennymacusa.com/>
>
Re: Can't compile EvaluationConditionalFormatRule
Posted by Blake Watson <bl...@pnmac.com>.
For completeness purposes, I should say that the language level in IntelliJ
is 8. The JDK in use is 1.8.0_131 which I believe is the official Oracle
release.
And this is line being objected to:
return op != null && op.isValid(val, comp, (Comparable)null);
On Fri, Jan 5, 2018 at 8:05 PM, Blake Watson <bl...@pnmac.com> wrote:
> On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey <gr...@gmail.com>
> wrote:
>
>> for getRules() you can just create your own subclass and override it with
>> a
>> public version that returns super.getRules()
>>
>
> That is precisely what I did, yes. And then I hit the matches thing.
>
> for matches, I don't see a quick easy way to override. What rule
>
>> definition seems to be slow, and what range does it cover? There are
>> definitely some formulas that take longer to evaluate than others -
>> especially things that do lookups or evaluate over an entire column range.
>> Could be something else as well.
>>
>
> Well, I don't know. I'm not working in Java so I was trying to bring as
> much as possible into Clojure (in which I am working, to state the
> implicitly obvious).
>
>
>> Right now there is no easy way to shortcut the logic for a range when the
>> formula is static (has no references relative to the specific range cell
>> being evaluated, meaning the formula has the same result independent of
>> "current" range cell). That kind of optimization hasn't even been
>> discussed yet, and reliably guaranteeing the code wouldn't miss a case is
>> probably non-trivial. Might even make it more expensive than it's worth
>> unless the range is large and has a large number of non-empty cells.
>> Patches welcome, of course ;D
>
>
> If I had a set up with profiler working in Java and moved the Clojure
> code into Java I could maybe work out the precise problem but I'm kind of
> under the gun on this one. I =am= working on getting a good Java set up and
> burnishing my Java skills because I do want to contribute back to POI. That
> said, this probably isn't the issue.
>
> I came up with an alternate plan which I had temporarily forgotten in
> trying to get all this other stuff to work: Instead of asking each cell
> what conditionals apply, asking the sheet about all the conditionals that
> apply and getting back a list of those conditionals with the cells
> affected . I'm guessing that would be (could be?) a lot faster.
>
> ===Blake===
>
>
--
*Blake Watson*
*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.watson@pnmac.com
www.PennyMacUSA.com <http://www.pennymacusa.com/>
Re: Can't compile EvaluationConditionalFormatRule
Posted by Blake Watson <bl...@pnmac.com>.
On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey <gr...@gmail.com> wrote:
> for getRules() you can just create your own subclass and override it with a
> public version that returns super.getRules()
>
That is precisely what I did, yes. And then I hit the matches thing.
for matches, I don't see a quick easy way to override. What rule
> definition seems to be slow, and what range does it cover? There are
> definitely some formulas that take longer to evaluate than others -
> especially things that do lookups or evaluate over an entire column range.
> Could be something else as well.
>
Well, I don't know. I'm not working in Java so I was trying to bring as
much as possible into Clojure (in which I am working, to state the
implicitly obvious).
> Right now there is no easy way to shortcut the logic for a range when the
> formula is static (has no references relative to the specific range cell
> being evaluated, meaning the formula has the same result independent of
> "current" range cell). That kind of optimization hasn't even been
> discussed yet, and reliably guaranteeing the code wouldn't miss a case is
> probably non-trivial. Might even make it more expensive than it's worth
> unless the range is large and has a large number of non-empty cells.
> Patches welcome, of course ;D
If I had a set up with profiler working in Java and moved the Clojure code
into Java I could maybe work out the precise problem but I'm kind of under
the gun on this one. I =am= working on getting a good Java set up and
burnishing my Java skills because I do want to contribute back to POI. That
said, this probably isn't the issue.
I came up with an alternate plan which I had temporarily forgotten in
trying to get all this other stuff to work: Instead of asking each cell
what conditionals apply, asking the sheet about all the conditionals that
apply and getting back a list of those conditionals with the cells
affected . I'm guessing that would be (could be?) a lot faster.
===Blake===
Re: Can't compile EvaluationConditionalFormatRule
Posted by Greg Woolsey <gr...@gmail.com>.
for getRules() you can just create your own subclass and override it with a
public version that returns super.getRules()
for matches, I don't see a quick easy way to override. What rule
definition seems to be slow, and what range does it cover? There are
definitely some formulas that take longer to evaluate than others -
especially things that do lookups or evaluate over an entire column range.
Could be something else as well.
Right now there is no easy way to shortcut the logic for a range when the
formula is static (has no references relative to the specific range cell
being evaluated, meaning the formula has the same result independent of
"current" range cell). That kind of optimization hasn't even been
discussed yet, and reliably guaranteeing the code wouldn't miss a case is
probably non-trivial. Might even make it more expensive than it's worth
unless the range is large and has a large number of non-empty cells.
Patches welcome, of course ;D
On Fri, Jan 5, 2018 at 4:10 PM Greg Woolsey <gr...@gmail.com> wrote:
> Which Java version is your compiler compatibility set to? POI 4.0
> requires Java 8.
>
> On Fri, Jan 5, 2018 at 3:14 PM Blake Watson <bl...@pnmac.com>
> wrote:
>
>> I am trying to =just= recompile two classes:
>> ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm
>> trying
>> to expose ConditionalFormattingEvaluator.getRules and
>> EvaluationConditionalFormatRule.matches. I think the latter is the source
>> of the slowness I'm experiencing.
>>
>> On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning <fa...@yahoo.com> wrote:
>>
>> > I use IntelliJ and it handles the poi repo well, in my experience.
>> > I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the
>> SDK.
>> >
>> >
>> >
>> > --
>> > Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
>> > 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
>> > dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
>> > 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
>> > 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
>> > For additional commands, e-mail: dev-help@poi.apache.org
>> >
>> >
>>
>>
>> --
>>
>> *Blake Watson*
>>
>> *PNMAC*
>> Application Development Manager
>> 5898 Condor Drive
>> Moorpark, CA 93021
>> (805) 330.4911 x7742 <(805)%20330-4911>
>> blake.watson@pnmac.com
>> www.PennyMacUSA.com <http://www.pennymacusa.com/>
>>
>
Re: Can't compile EvaluationConditionalFormatRule
Posted by Greg Woolsey <gr...@gmail.com>.
Which Java version is your compiler compatibility set to? POI 4.0 requires
Java 8.
On Fri, Jan 5, 2018 at 3:14 PM Blake Watson <bl...@pnmac.com> wrote:
> I am trying to =just= recompile two classes:
> ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm trying
> to expose ConditionalFormattingEvaluator.getRules and
> EvaluationConditionalFormatRule.matches. I think the latter is the source
> of the slowness I'm experiencing.
>
> On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning <fa...@yahoo.com> wrote:
>
> > I use IntelliJ and it handles the poi repo well, in my experience.
> > I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
> >
> >
> >
> > --
> > Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
> > 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
> > dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
> > 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
> > 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> > For additional commands, e-mail: dev-help@poi.apache.org
> >
> >
>
>
> --
>
> *Blake Watson*
>
> *PNMAC*
> Application Development Manager
> 5898 Condor Drive
> Moorpark, CA 93021
> (805) 330.4911 x7742 <(805)%20330-4911>
> blake.watson@pnmac.com
> www.PennyMacUSA.com <http://www.pennymacusa.com/>
>
Re: Can't compile EvaluationConditionalFormatRule
Posted by Blake Watson <bl...@pnmac.com>.
I am trying to =just= recompile two classes:
ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm trying
to expose ConditionalFormattingEvaluator.getRules and
EvaluationConditionalFormatRule.matches. I think the latter is the source
of the slowness I'm experiencing.
On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning <fa...@yahoo.com> wrote:
> I use IntelliJ and it handles the poi repo well, in my experience.
> I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
>
>
>
> --
> Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
> 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
> dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
> 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
> 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>
--
*Blake Watson*
*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.watson@pnmac.com
www.PennyMacUSA.com <http://www.pennymacusa.com/>
Re: Can't compile EvaluationConditionalFormatRule
Posted by "pj.fanning" <fa...@yahoo.com>.
I use IntelliJ and it handles the poi repo well, in my experience.
I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org