Since upgrading to Grails 5.3.2 which has Groovy 3.0.11 my team has been having issues with StreamingMarkupBuilder not rendering how it used to in 2.5.x(Grails 4) . It seems like when a private method is being called within the StreamingMarkupBuilder, for some reason, it's not finding that method, and treating it as if it were part of the markup. Did anything change around private method handling, or StreamingMarkupBuilder in Groovy 3.0.11. Looking at GitHub it doesn't seem like it. I wrote up some sample code based off the failing code and tried it in the Groovy console of both Groovy 2.5.8 and Groovy 3.0.11, but it works in both versions, but for some reason breaks in Grail 5.3.2. With the sample code if I comment out the private method it act as it does in my app:

import groovy.xml.StreamingMarkupBuilder

class TestMarkup{
    private String toTF(value) {
        return value ? "true" : "false"
    }
    
    Map status = [someBoolean: true]

    
    def getBuilder(){
        return new StreamingMarkupBuilder().bindNode {
            Indicator(toTF(status?.someBoolean || status?.someBoolean))
        }
    }
}

new TestMarkup().getBuilder()

Any Ideas? I just got some steps to reproduce it so I'm going to try debugging it and see where that gets me.

So in debugging this issue, I found that through various method calls, I'm in a StreamingMarkupBuilder within a StreamingMarkupBuilder, and for some reason, it can not see any private methods despite being defined in the same class as the StreamingMarkupBuilder. Dropping the private modifier seems to work.

Probably worth an issue.

I was going to ask that. When I get back to my computer. I'll see if I have a login and write one up.

So I didn't write up an issue because, after lots more debugging, this doesn't happen in a clean 5.3.2 test app. The problem doesn't even seem re-creatable in our app in Bootstrap, so I don't think it's related to dependencies, config, or any of that. Which means somewhere else we are creating a self-inflicted wound. So far I can't tell how or why and this didn't happen under Grails 4.0.11 with Groovy 2.5.8... The only fix I've found is to drop the private modifier on methods called from in the StreamingMarkupBuilder. In my app I have 404(funny) instances across 110 files.

I cross-posted to the Grails slack channels and got this reply: Steve Osguthorpe [5:04 AM] We've had similar things happen and I'm fairly certain it's because of Groovy 3 now enforces visibility whereas before it would allow you to circumvent it. In actuality the current behaviour is more correct, because the closure you have defined there, is executed lazily by the

bindNode

method of the

StreamingMarkupBuilder

class, and that method/class should not be able to see private method. So it effectively calls

owner.toIF( ... )

which you would expect to be an access violation. You can actually evaluate the example you show there before calling the binder, and that value will be in the scope of the builder and so it should be able to see it. Although there may be instances elsewhere in your codebase that you can not do this, in which case the best option is to make the method public (as you have done) as it reflects the usage clearly. Something like the following would work for the example...

class TestMarkup{
    private String toTF(value) {
        return value ? "true" : "false"
    }
    
    Map status = [someBoolean: true]

    
    def getBuilder() {
        // Executed in the scope of `TestMarkup` can see private scoped values.
        final String indicatorVal = toTF(status?.someBoolean || status?.someBoolean)

        return new StreamingMarkupBuilder().bindNode {
            // Executed later by `StreamingMarkupBuilder` shouldn't be able to see values outside the scope of the `getBuilder` inner stanza
            Indicator(indicatorVal)
        }
    }
}

new TestMarkup().getBuilder()

Groovy Duke [6:31 AM] Interesting, this must have been a leak from Groovy 4 to 3 because in the Groovy 4 release notes:

We are currently attempting to improve how Groovy code accesses private fields in certain scenarios where such access is expected but problematic, e.g. within closure definitions where subclasses or inner classes are involved (GROOVY-5438). You may notice breakages in Groovy 4 code in such scenarios until this issue is progressed. As a workaround in the meantime, you may be able to use local variable outside a closure to reference the relevant fields and then reference those local variables in the closure.

However what is weird is in a fresh app the call to the private method will work, In a simple example like the one posted but in the app I'm working on the conditions are right for it to fail... In any case thanks for the insight.

@virtualdogbert If you define a class MyClass and there is a Groovy closure in there somewhere, then what is supposed to be legal is similar for what an inner class can do. A closure should then be able to execute a private method defined in MyClass. This used to work... in the past the biggest problem was that if I have MyOtherClass extends MyClass, that the Groovy closure in MyClass is no longer able to call the private method defined in MyClass if we currently execute an instance of MyOtherClass. I currently do not have the time to properly check what changed here in 2, 3, 4 and 5. That is also what the release notes for Groovy 4 target. But I somehow think that might not be really the problem. There is actually one really unresolved problem in all this. If MyOtherClass defines a public method foo, then a Closure in MyClass is supposed to be able to call it because of multimethods. If MyClass already defines a private method foo, then what method is the Closure supposed to call? Not seeing the public method would in this case mean to leak private abstraction. Letting the public method shadow the private one is breaking encapsulation as well.

class Runner {
  def run(cl) {
    cl()
  }
}

class A {
  private foo() {1}
  def bar() {
   def runner = new Runner()
   runner.run {->foo()}
  }
}

class B extends A {}

def a = new A()
assert a.bar() == 1
def b = new B()
assert a.bar() == 1

This code works with 2.5.22, 3.0.18 and 4.0.13

works also with 3.0.11 and 5.0 alpha 1

Shouldn't the last line be

assert b.bar() == 1

ups

fails in all previously mentioned versions, except Groovy 5

removing the runner and executing the Closure directly makes no difference.

For pre Groovy 4 it behaves as expected, nice to see it works in 5.

but if they fail, then on the last line. This does imho not explain the problem with StreamingMarkupBuilder

How can I annotate with

public <T> T Stub(Closure interactions)

in Java, that the type of the closure delegate is

T

? 😕 Optimally, already with 2.5

Are there

respondsTo

and

hasProperty

variants or siblings that also consider category classes?

I think they are supposed to include currently active categories

Hi, what is the plan for Valhalla objects (value objects) support in Groovy?

@bsdooby what is their current state for the JVM? I don't think it makes sense to have value objects in Groovy that are not also value objects for the JVM, so there would be no backporting I think. But in principle there is nothing but the JVM version trouble preventing us to implement that

They are comming w/ Java 21

...and I was just wondering

I think we will implement them soon. Maybe in Groovy 5, maybe next version. there is afaik no plan yet

@bsdooby If you want to implement them you are welcome

...no chance;

(I am too dumb)

ahh.. no, just may take longer then 😉

When calling, JsonOutput.toJson, I get “no such method” when it hits a closure in a deeply nested map structure. I think I remember reading somewhere that groovy would allow me to override methodMissing, can I do that in a temporary manner just for the duration of the Jason output processing? Of note, I’m stuck on Groovy 2.4.13

Hey! Can someone please look at my PR? 🙂 https://github.com/groovy/GMavenPlus/pull/264 JDK21 support!

I've got what seems like it should be a straightforward problem that is vexing me. I'm modifying an XML document using XmlSlurper. When I turn the

GPathResult

back into a string using

XmlUtil.serialize

, any emoji in the document are getting encoded as surrogate pairs, rather than the valid single character points. That leads to problems for me later when I try to parse the document using Jackson (see https://github.com/FasterXML/woodstox/issues/165 for an example of the error). It seems like I should be able to direct XmlUtil to serialize the unicode points into single entities (e.g.

🎅

instead of

��

). This is one of those things where I know I've dealt with it before and am just not coming up with the solution. Can anyone enlighten me / jog my memory?