The graphics will be simple. Avatars will be 2D images as opposed to 3D character models.
I'd favour Java personally given my background experience.
Well, I think nowadays Java is quite viable as a game dev language... it might just be that you need to work a little bit harder to get acceptable performance from it, and you most probably will never quite reach C++ levels of performance.
Usually I would say don't worry about it, but with a client / server system, at least the server parts performance might directly influence your profit margin (as in, 20% less performance means 20% more resources needed on the server, which might increase cost)d.
Still, starting in Java now for a prototype doesn't mean you cannot rewrite the game for release in C++, or maybe even create a second prototype in it. Never be shy to refactor your code. It might seem like a waste of time now, your future self will certainly thank you for it! And maybe it turns out your code runs perfectly fine, some Java Game Dev crack tunes into the discussion to give you helpful hints or whatever, and you don't need to rewrite in a different language... who knows?
I am a Java Programmer for Business Apps, I use C# and the Unity Engine for Game Dev, so I wouldn't really have any expertise in how to make Java perform in Realtime applications like games (most Business Applications are not really that performance critical)... there are enough people on this forum that are using Java for their Game development, so if you want specific info on how to use Java for game development, best way is to first search for old threads, and then ask the remaining questions in a separate thread.
This is an issue I'm wary of. There will be a form of in-game currency. Could you suggest a way of circumventing this problem, while still handling logic client-side?
AFAIK that is a very difficult question. Kind of the holy grail of Multiplayer Game programming... current trend seems to be to just move everything to the server that needs to be trustworthy. That is also why the current crop of multiplayer games often have simplified and streamlined game logic compared to some singleplayer games.
To be honest, I don't think you should worry to much about server performance... a simple game concept like yours should be easy to calculate on the server. You might be able to lessen the load on the server a little bit by making some things purely cosmetic (example that might not apply to your game concept: Make debris created during an explosion not affect gameplay in any way (no collision model, no influence on line of sight and so on)... that way you can happily calculate debris physics client side, because it doesn't matter if debris falls to different places for different players)...
As said, just beware of the obvious pitfall: just because other players can't see something doesn't make it save to calculate client side. If it has an influence on game logic, even if its just an influence for a single player, it can and will become a target for cheats.
Lets come up with some examples more suited to your concept... be aware that this is all my personal opinion, and I am make a lot of assumption about your game concept:
1) Your player can cut down trees, but only he will see the tree being cut down, and it has no ingame effect other than the tree now lying on the ground, therefore purely cosmetic.
No problem leaving the code in the client. Players might come up with a cheat to cut down ALL trees in the game world with a single click, but that doesn't do much for them. If the effect is persistent, it might even just piss them off because their instance of the game world is deforested now for all eternity.
You could just as easy prevent them from doing that by having a max number trees that can be lying on the ground at the same time and check that at startup (can be cheated again, but allows to reset the cheat), and actually, at some point this update has to reach the server anyway for persistence. If a player cuts down more than a single tree at the same time, something is fishy, and you can reject it, making it non-persistent.
2) You have a puzzle somewhere that needs the player to shove around boxes to reach a new part of a level. IMO can be left client side. Yes, players might cheat the puzzle to get the boxes align correctly without needing to solve the puzzle... but a) people might just read a walktrhough and "cheat" the game in some seconds without hacking your code, and b) the reward for the cheat is just a quicker way to whatever is lying beyond the puzzle obstacle, which has zero influence on your ingame economy, as long as the puuzle wasn't designed to be only solved by a certain % of the playerbase and the reward gained by solving it isn't overly huge.
In the end, the player will just make the entertainment shorter for himself....
3) A player can dig in the ground to find some rewards that might include ingame money, or resources either also sold in a cash store, or linked to the ingame economy. To prevent players doing that 24/7 to get "ingame rich" quickly or not having to live with freeloaders limitations, this action can only be repeated once per minute.
Now, this needs to be on the server. There is no way around it. Just limiting it when persisting the rewards isn't really enough. You might get the guys that try to get rich by spamming the digging 24/7, but the guys that repeat the digging only once a minute, but hack the possibilities to get certain rewards are hard to catch. Your server would need to keep track of what the player dug up in the last few tries anyway to spot a pattern to goes way outside of standart deviations anyway (like getting the super rare sword of IMBAness like 10 times in a row), so you could as well let the server do the RNG diceroll and tell the client what the player dug up.
So, TL;DR: if you don't want move it to the server, it should be purely cosmetic, or only affect a single player without ANY influence on the players resources / economy. Everthing else needs to be calculated server side. If that is too much load, and you cannot improve performance, you need to simplify the logic.
Just as you describe MMO as a taboo word, is GameMaker not another one? I was under the impression it was not well regarded among game developers.
Thanks again to you all. I was a little overwhelmed by the response!
Well, see, different devs have different opinions around here. Some will teach you to avoid existing Engines like the plague and write all your games from scratch (and at least for learning, they have a valid point IMO)... others will tell you to not reinvent the wheel and develop games, not engines.
Same with different Tools and Engines. Personally, I never tried Gamemaker so I cannot really judge... but there are people around here that did use it and are happy with it, and as usual, you will also find the opposite.
Again, best thing is to create a separate thread to ask if your game idea can be realized in GameMaker, or if there are better options around for that. Of course before asking, you should investigate yourself a little bit. Given enough time, maybe check all the popular game engines as most of them offer 2D Workflows nowadays. But a lot of them are 3D Engines in their core and quite overkill for a 2D Game because of their complexity...
Which brings us to why I even mentioned GameMaker: it is a simpler, pure 2D Engine, and as far as I know it is the most used and mentioned 2D engine out there.
First means less complexity and most probably flatter learning curve, second means large community, so lots of tutorials available, and many people you can ask if you get stuck.
In the end, there will always be people that judge a Book by the label (like games that have been built in Unity cannot be as good as the ones built in CryEngine...riiiight), but that is hard to evade as an Indie anyway. Find the tools that let you be as productive as possible, and don't worry about the labels as long as the output is satisfying.