Oh, the source is not a problem. It is part of the open-source project -
https://github.com/croz-ltd/klokwrk-project
Previously, I mentioned only one occurrence of the problem, but I have two
actually. I did some refactorings in the
meantime, so one of the stack traces differs from the previous
set. After those changes, the created native image no longer
throws the
exception mentioned above.
I hope this description will be helpful to anyone encountering similar issues.
Best regards,
Damir Murat
Tnx Jochen for the comment :-)
I've created the issue in Groovy JIRA:
https://issues.apache.org/jira/browse/GROOVY-10878
I forgot to explicitly mention the primary motivation for doing this.
At the moment, there is no way to have full branch coverage for Groovy assert
statements.
In a larger project, this is very distractive when trying to find the pieces of
actual logic that
should be better covered with tests.
JaCoCo has long-standing issues with covering calls of methods that throw
exceptions.
When such methods are called inside of, if/else branches for example, the
result is
partial coverage reported for those branches.
However, there is a JaCoCo idiom
Hi all,
I will like to know if it is possible to get deprecation warnings displayed
when compiling Groovy code. For example, when using Java deprecated APIs from
Groovy code.
I tried many variations in my Gradle scripts, but none worked. I'm unsure if
the problem is with Gradle or Groovy, so
Hi all,
I will like to ask a favor from the community. If anybody wants to vote for
Groovy support in the new IDEA plugin targeting Axon Framework, please give a
thumbs up to this issue:
https://github.com/AxonFramework/IdeaPlugin/issues/64
Thank you
Tnx Szymon. I opted for the first solution without CompileStatic.
annot return value of type java.util.List on method returning type java.lang.Class []"
I tried several things but failed. Is there a way to do this in Groovy, or
should I just create the annotation in Java?
Tnx,
Damir Murat
.
Regards,
Damir Murat
On 1 Feb 2021, 10:02 +0100, MG , wrote:
Hi Damir,
great work, and another step towards putting (statically compiled) Groovy on
the map as a OS level scripting language with startup times as fast as Python,
Perl, Ruby, ...
My feedback would be:
1. Give changes
Thank you for your kind words, Remko.
I think the best way to submit the feedback is via GitHub facilities.
If it is something in general, go with Discussions, and if you found
some concrete errors, you can use Issues, possibly followed by
Pull requests.
Tnx,
Damir Murat
On 31 Jan 2021, 13:22
://github.com/croz-ltd/klokwrk-project/blob/master/support/documentation/article/groovy-graalvm-native-image/groovy-graalvm-native-image.md
Tnx,
Damir Murat
It looks like I managed to create a working solution, but I also have several
questions :-)
Regarding the solution, it was not too complicated. I modified ClosureWriter
and StaticTypesClosureWriter
to annotate generated call methods with @Generated.
Regarding questions. Modification started to
Here is an issue: https://issues.apache.org/jira/browse/GROOVY-9858
I can try to do something about PR, but will need some starting pointers if
possible :-)
Tnx.
Any thought on this?
I can see that many false negatives from my code could disappear from a code
coverage report. But I might be missing something.
Tnx
As far as I understand, closures generated by the Groovy compiler contain
both doCall() and call() methods, where call() always delegate to doCall().
Typically, users will use a short form of closure invocation, which Groovy
translates to direct call of doCall(). This means that in a typical
ing PR for this issue, I am interested in doing it.
> Let me know if you are handling it already.
>
> Thanks,
> Kishore
>
> On 2020/10/08 18:46:37, Damir Murat wrote:
> > Here is reported issue: https://issues.apache.org/jira/browse/GROOVY-9772>
> >
> > Tn
Thank you for your help. You are most kind, sir :-)
I ended up creating a helper AST transform. If you are interested, you can see
it here:
https://github.com/croz-ltd/klokwrk-project/commit/6f297c96db900d8dabffb45f2a5a38c60e442418
To complete my @Immutable customization story, I also created
AnnotationCollectorTransform generates an inner helper class CollectorHelper
with a method value().
Since it is not marked with @Generated, the value() method pops up in the
JaCoCo coverage report.
Is it possible to mark the value() method, or whole inner helper class, with
@Generated?
Tnx,
> It's a little strange in that the visibilityId would control visibility for
> both the map and no-arg variations
> unless the noArgVisibilityId attribute was set.
Yes, it is strange a little, but not unbearable :-)
> Also, if you set noArg=false for @MapConstructor and defaults=true for
>
Yes, I could benefit from static factory methods. Thanks for giving me an idea.
But I was thinking only about restricting the visibility of the default no-arg
constructor.
As both @MapConstructor and @TupleConstructor have a visibilityId parameter used
for fine-grained tuning of visibility, I
I can't find an option with @MapConstructor/@Immutable to modify the visibility
of the generated public no-arg constructor. Is it possible to add it if it
makes sense?
The idea is to prevent application code from using it unintentionally, while
still
allowing frameworks to access it via
Sure, here it is: https://issues.apache.org/jira/browse/GROOVY-9770
I noticed that JaCoCo does not include in the coverage report Groovy 3 lambdas
(contrary to closures).
After asking on the JaCoCo group, the JaCoCo maintainer suggested me to ask on
the Groovy side.
The problem is that the generated class for lambda is marked as synthetic,
which is not the
Tnx for replaying, Paul
I'm cheering for API as a bonus :-) Comparing to assert statements, I found it
a bit more
expressive for DBC context. But it can be considered just a stylistic issue.
My biggest complaint about "assert" statements is the lack of complete support
for them
in Jacoco code
messages that should include real expressions used in code.
Please, take into consideration that I didn't yet look at Groovy 4. I only read
release notes.
Tnx,
Damir Murat
26 matches
Mail list logo
