Fix for issue 969 and issue 986 #990
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…eturn type that is not a constructor returns "void" in the generated output. This fixes issue 969 -Modified SampleFileWriter_Code.ump so that expected and actual output is compared properly during assertUmpleTemplateFor(). This fixes issue 984, but is included in this commit because the fix is also necessary to fix issue 969 as the two issues share many test cases (JUnit can't be green for either issue unless they are both fixed).
…issue 969 (984 and 969 don't need to be worked on together after all).
… Java sense of the term) are correctly generated by Umple. - Removed the "is this a main method check" from UmpleInternalParser_CodeClass.ump. Since what it means to have a "main function" varies from language to language (e.g. compare Java where the main method is the main entry point into a program and PhP where it's just another method) this check should be done and the results processed during code generation. - Changed the "is this a main method check" in class_MethodDeclaration.ump to include a check for "void" and "String[] args" - Added several new test cases to verify the main check and subsequent code generation is behaving correctly - Added a "tearDown" method to DistributedClassTest.java that cleans up the mainMainClass static variable before moving to the next test set. Without the tearDown method the state from DistributedClassTest.java was being carried over to JavaClassTemplateTest.java, which was causing intermittent code generation issues.
… the user explicitly includes "void" in the .ump file.
…erated3.ump (it was identical to ClassTemplateTest_Generated2.java.txt and ClassTemplateTest_Generated2.ump
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes the "Not having return types for methods" issue (969) for Java and Php (not for C++, I've created a seperate issue for the C++ guys).
As part of the investigating 969, I uncovered issues relating to the generation of "main" methods and associated threading code in Java (the investigation formed its own issue, (986)). Essentially, the test to determine if a method was a Java main method wasn't rigorous enough. This has been fixed and the threading code is generating properly now (i.e. only if
public static (void) main(String[] args)is present)Additionally, I looked into why the threading code being generated for a Java main method wasn't consistent from run to run. The problem was that a JUnit test wasn't cleaning up after itself, and has also been fixed.
Tests
Several tests have been added (and a few existing tests have been modified) to fully verify the correctness of the generated
mainmethods and associated threading code, as well as to verify thatvoidis being added to Java methods that don't specify a return type.Closes #969, #968