You are continuously posting the same code with just the next set of errors you come across. If you continue to do this, then members are less likely to want to help you, so when you come across a real problem, and reach out for help, no-one will listen to you (Aesop's Fables -
The Boy Who Cried Wolf[
^] )
So here is some more general advice ...
1.
Only read the first compilation error. Ignore the rest for now
MyProgram.java:39: error: class, interface, or enum expected
public static boolean isVowel(char letter)
^
2.
Really read the error - take in
everything it is saying - it is trying to help you solve your problem. See that little ^ character - it is pointing to where the compiler first came across the problem. It's right at the beginning of that line of code. This usually means that the problem is
just above that line. Basically everything is fine until the compiler sees that line - it's saying, "Hm, I wasn't expecting that!"
In your case, you have probably missed out a closing brace or inserted an unnecessary opening brace somewhere. It seems to be a habit of yours.
3.
Work Tidy.
By this I mean - indent your code "properly". What does "properly" mean? You will notice that Solution 1 and Solution 2 use two different styles of indenting.
public static boolean isVowel(char letter) {
but
public static boolean isVowel(char letter)
{
It doesn't matter which one you choose (many, many arguments over the years on this one) but whichever one you choose
be consistent
That means, if you copy and paste some code you have found elsewhere, the first thing you should do is convert it to the style of indentation that you have chosen. That might mean that you have to change the tab sizes or the number of spaces used - whatever it takes, tidy that code up straight away.
Why? Because it is a lot easier to spot errors. Trust me. A LOT easier. That list of links in Solution 1 is great - get your editor to do the hard work.
Work tidy also means don't leave loads of commented-out code lying around in your program. Again, it's all about making your code easier to read which makes it easier to spot errors.
4.
Only read the first compilation error.
Yes, I know I am repeating myself.
Once you have worked out what the fix is for the first one,
recompile. Why? Because Nine Times Out of Ten the rest of the errors will simply just "go away". Especially if the error contains the word "expected".
Never, ever, start looking at compilation faults from the bottom up.
So the corollary to this is ... don't be daunted by a huge list of errors. Just start at the top and deal with one at a time, recompiling after each fix to see what is left.
By the way, if you ever use a compiler that gives warnings as well as errors - treat those compile-time warnings with the same respect as errors. It's a lot easier to fix something that appears at compile time than it is to fix it when it becomes a run-time error!
Finally, please, do start trying to help yourself with this. We really do want to help, but if someone persistently demonstrates that they are not listening to us we very quickly just stop even looking at their posts.