Please rebase and let's try the CI again. I put Java 21 in the CI on master, it might help. :-)

@fmontesi there seems to have been made a change to the hashCode method of the Value class that makes it loop indefintely, which causes StackOverflow when trying to run the jolie2java tests. I believe it is because the line Objects.requireNonNullElse( valueObject(), UNDEFINED_VALUE ).hashCode() is causing the hashCode method of UNDEFINED_VALUE to be called recursively.

@fmontesi I refactored the tests such that they do not call hashCode on the Value class, if you want I can open an issue about the infinite looping, but now the JavaDoc goal throws an error because I use the tags @apiNote, @implNote, and @implSpec, which apparently aren't standard tags, would you prefer I change the tags to something else or should I just add them as custom tags in the maven-javadoc-plugin?

@Jonaythaz Yes please open an issue for that. @mwallnoefer Perhaps this is caused by the recent patches you made about hashCode for Value? (If I remember correctly, I haven't checked.)

Regarding the javadoc tags, can you point me to an example? Is it in your own code or code that you generate from jolie2java?

@Jonaythaz Yes please open an issue for that. @mwallnoefer Perhaps this is caused by the recent patches you made about hashCode for Value? (If I remember correctly, I haven't checked.)

Regarding the javadoc tags, can you point me to an example? Is it in your own code or code that you generate from jolie2java?

I use the tags in some of the classes in the Jolie module that are used by the generated classes, e.g. in the documentation string for JolieNative I used @apiNote for the section where I explain how to use an enhanced switch expression to access its data. Another example is using @implSpec in JolieValue to document methods that are just shorthands for using a combination of different methods.

These tags are used in the documentation for the Java standard library, although I can't think of an example off the top of my head, so I don't think it's a problem to just add them, but since they aren't standard I figured I shouldn't do it without asking.

@Jonaythaz maybe keep a look for not introducing new CodeQL warnings. I have tried very hard to reduce them to an absolute minimum over the last few months

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

Regarding to the hashCode()refactoring it is a pity, I have tried very hard comply with CodeQL to not break anything. Of course feel free to propose some patch if you see some better solution, here is my commit: c1e90f7

. @mwallnoefer Perhaps this is caused by the recent patches you made about hashCode for Value? (If I remember correctly, I haven't checked.)

Maybe something like this could fix it?

	@Override
	public int hashCode() {
		return isLink() || !isDefined() ? super.hashCode()
			: valueObject().hashCode();
	}

Maybe something like this could fix it?

	@Override
	public int hashCode() {
		return isLink() || !isDefined() ? super.hashCode()
			: valueObject().hashCode();
	}

At the very least this doesn't cause loops with any of the instances of Value I use in the jolie2java tests, although when testing it the hashcodes were different despite the instances containing the same data, is that intentional?

@Jonaythaz maybe keep a look for not introducing new CodeQL warnings. I have tried very hard to reduce them to an absolute minimum over the last few months

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

Regarding to the hashCode()refactoring it is a pity, I have tried very hard comply with CodeQL to not break anything. Of course feel free to propose some patch if you see some better solution, here is my commit: c1e90f7

. @mwallnoefer Perhaps this is caused by the recent patches you made about hashCode for Value? (If I remember correctly, I haven't checked.)

I have some new changes that addresses most of the CodeQL complaints, just waiting for the verdict on the tags before pushing them. Annoyingly CodeQL warns you about unused variable in a switch expression, even though you can't use anonymous variables, i.e. _ instead of a variable name, until Java 22.

Maybe something like this could fix it?

	@Override
	public int hashCode() {
		return isLink() || !isDefined() ? super.hashCode()
			: valueObject().hashCode();
	}

At the very least this doesn't cause loops with any of the instances of Value I use in the jolie2java tests, although when testing it the hashcodes were different despite the instances containing the same data, is that intentional?

Before there was no hashCode() implementation at all, so yes I think so.

@fmontesi What do you think, given the importance of a correct hashCode() implementation which should not end up in a stack recursion overflow, should we apply my patch and roll out a v12.1.0 bug-fix release?
Nevertheless strange that the situation was not covered by the unit tests.

Yes, good idea. Please apply it to both master and release/1.12, I'll make a patch release for 1.12.1.

Would also be good to add a test for this here: https://github.com/jolie/jolie/blob/master/jolie/src/test/java/interpreter/ValueTests.java

Thanks @mwallnoefer!

@Jonaythaz, please rebase once again and let's retry. :-)

@Jonaythaz, please rebase once again and let's retry. :-)

@fmontesi before rebasing, what is the verdict on the non-standard tags, add them to the JavaDoc plugin or replace them with a different tag?

Oh, right, about the tags: as long as we don't force users of Jolie and our tools to have custom javadoc configurations, they're fine!
So, if I understand correctly, having them in our own source code in the jolie repository should be fine. But we shouldn't use them in comments of code generated by jolie2java, otherwise users will need to know about this in order to run javadoc and I suspect most will just get surprised that the toolchain is 'broken'.

Makes sense?

Oh, right, about the tags: as long as we don't force users of Jolie and our tools to have custom javadoc configurations, they're fine! So, if I understand correctly, having them in our own source code in the jolie repository should be fine. But we shouldn't use them in comments of code generated by jolie2java, otherwise users will need to know about this in order to run javadoc and I suspect most will just get surprised that the toolchain is 'broken'.

The only tags used in the generated files is @see so that shouldn't be a problem. While adding the tags it turns out that the plugin doesn't allow the tags I used as custom tags because "they could be overridden by future standard tags", so I had to prefix them with custom., but this can pretty easily be changed back if those tags ever actually get added as standard tags.