Level Designers/Editors are one tool/group of tools that programmers make.
Is the editor suppose to do this:
1) First make the map in the editor
2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.
3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map
into their program.
Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.
can the editor generate a file that contains a set of integers that represent game object data. Each integer corresponds with a different game objects like: stone, grass, trees, flowers, wood. Is that the prefer way for what the editor should perform?
In the end, your tool will be tailored to your engine and to the purpose you are trying to accomplish. If your game engine has a mechanism to differentiate game objects by some sort of ids, then yes, perhaps storing objects as ids in your input file would be the way to go. Honestly it all depends on the situation, what you are trying to do, and how your game does so.
In my experience, a tool such as a scene or level editor would probably use the same "engine" as the game. Its job is to make the creation of entities more convenient than hard coding everything. By having the tool use the actual engine, you get to see how things will pan out in the actual game as you are creating your level. The only difference with the actual game is that the tool spits out a file and your game reads that file as its input. Hence, the editor would need a way to save things out in a convenient format, and your game would need to parse that file to reproduce the entities. The tool exports, and the game imports.
Another example.... Artists usually create content in commercial applications such as Photoshop (for textures) and 3ds max (for modeling). The problem is that rendering your asset in 3ds max will not look the same as in your game. An artist has no idea what his/her creation will look like until the work that was created can be rendered by the game's rendering pipeline. A tool, using the game rendering pipeline, can be created for artists to check and tweak their creation. Within the tool, lighting settings can be modified. The textures and materials could be tweaked. Things will be modified until the artist is content with the results, at which point things can be exported into a format that the actual game will know about and can import in.
Similar tools can be created to facilitate content creations related to other fields... say sound for example. A sound engineer will work on creating sound in a software he/she is familiar with. But in the end, the results must be checked with the actual game's sound engine. A tool could be created for that as well within which sound settings could be modified until the sound engineer is satisfied and the results match what he invisioned in the first place.
What I'm trying to get at is that there is no real general ideal when it comes to tool creation. You must first analyze workflow problems within your project, see how you can facilitate it, and create a tool tailored for it.