We Keep Coding

are there java method naming conventions are in use for mutable `with`?

IMPORTANT: I am NOT asking for an opinion on what naming convention I should use. I want to know what naming conventions others have seen for the case below, in projects large and public enough to be noteworthy. Unfortunately, my Google searches have turned up nothing, probably because I don't already know any of the prefixes and therefore can't search for it by name.
I know that the with method prefix should be used to return a new instance of an immutable object, with its contents modified according to the specified object. However, I’m not aware of any naming convention for simply mutating a mutable object. Is anyone aware of any naming conventions for this and where they’re used?
If it matters, the problem I want to solve is I want to add a method that initializes the contents of an existing DTO, using a corresponding entity.

I don't think there is a standard convention for the scenario you're describing. Take a look at a GsonBuilder (documentation here). There are many prefixes used, including "set", "add", "register", "enable", etc. They all just describe the method's behavior.
I would recommend using initializeFromEntity(entity) or something similar, since this describes what the method does -- you're initializing the DTO contents using an entity.
Searching Google for "Java initializeFrom" results in several usages (example, example).

Is it bad design to use Java enums to call other methods?

I have got a problem where I calculate a number and according to this number I have to call a specific method. I ended up with the idea of creating an enum in which each element calls another method. Just as described in this post https://stackoverflow.com/a/4280838/2426316
However, the poster of that answer also mentioned that it would not be considered a very good design, so that I am wondering what I should do. Is it safe to implement an algorithm that uses this design? If not, what else can I do?

The Java Enum type is a language level support (syntactic sugar) for the type-safe enum pattern.
One of the advantages of the type-safe enum pattern and the Java Enum type (compared to other solutions such as C# enums) is that it's designed to support methods, even abstract ones.
Possible usage:
places where you would use the Strategy pattern, but have a fixed set of strategies
replace switch statements with polymorphism (prefered)
...
For more information:
Effective Java, by Joshua Bloch.
First edition includes the type-safe enum pattern
Second edition includes the Java Enum type
Refactoring, by Martin Fowler (e.g. Replace conditional with polymorphism)

Well, safety probably isn't the issue here. It is uncommon an can be difficult to follow though.
My recommendation would be to build around this in one of two ways:
Use ENUMS but don't include the function calls in the ENUM code itself. Rather have a function explore(Level1 level){...} that has a switch statement which differentiates by the level passed.
Use Lambda expressions. This is the cleaner solution as it allows you to pass functions as arguments; sadly Java won't support this method natively until Java 8 is released. There are however implementations to simulate Lambda expressions, the best known probably being lambdaj.

Is it good practice for Java class names to be plural?

Is it good to have java class name like ExtractionUtils.In naming conventions I no where found anything about plural name of the java class.
I have seen classes like this in one of the project.

Arrays, Collections, Executors, Files, Objects, Utilities [!] - examples from JDK. It kind of violates OO design since all these classes are just namespaces holding utility or factory methods of objects in question while the name suggest they actually contain or maintain a collection of such objects. But being reasonable - I find these names readable and completely fine.
BTW looks like such a naming convention was very popular among Java 7 API designers.

Yes perfectly acceptable to have plurals, look at Collections for example, it is a class which has many static methods which help when dealing with different flavours of collection.

Only issue I see is that a "utils" is pretty ill-defined. You want the class to refer to the object, not the collection of methods in the object. Basically, it's just not a very object oriented name, and it's not even about OOP - a "utils" file is pretty poor structured programming often.

Have a look at jls7 http://docs.oracle.com/javase/specs/jls/se7/jls7.pdf . I found anything wrong about naming classes in plural.

When is a Java subroutine not a method?

I came across this during learning Java in the beginning, but I am learning top down, so I would like some direction:
This was on a Java tutorial relatively early on:
As one final general note, you should be aware that subroutines in Java are often referred to as methods. Generally, the term "method" means a subroutine that is contained in a class or in an object. Since this is true of every subroutine in Java, every subroutine in Java is a method (with one very technical exception). The same is not true for other programming languages. Nevertheless, the term "method" is mostly used in the context of object-oriented programming, and until we start doing real object-oriented programming in Chapter 5, I will prefer to use the more general term, "subroutine." However, I should note that some people prefer to use the term "method" from the beginning.
My question is what is that "one very technical exception." Since I am learning multiple stack technologies, I would like to know this specific exception he is referring to. It comes from this tutorial :
http://math.hws.edu/javanotes/c2/

Quoting from chapter 5 of the tutorial you linked to:
Constructors are subroutines, but they are subroutines of a special
type. They are certainly not instance methods, since they don't belong
to objects. Since they are responsible for creating objects, they
exist before any objects have been created. They are more like static
member subroutines, but they are not and cannot be declared to be
static. In fact, according to the Java language specification, they
are technically not members of the class at all! In particular,
constructors are not referred to as "methods."

Class constructors are not methods.

Would it be possible to have "method/field" literals comparable to the class literals in Java/Scala?

Java's Foo.class as well Scala's classOf[Foo] literal class syntax return a reflective view about the class in question.
Is it possible and would it make sense to provide something like .method/.field or methodOf[]/fieldOf[] for getting comparable reflective access to methods and fields?
How would something like this be implemented in Java/Scala?
In the case of Java, I would assume that this would either require a language change (very unlikely) or some wizardry with bytecode tools/AspectJ, whereas in Scala it is probably possible to implement it with an implicit conversion.

Yes and no. Paul Phillips has certainly expressed an interest in such a thing, and there's a lot of work currently happening in trunk around the forthcoming scala reflections.
It's doubtful that we'll see anything like your proposed syntax though. Methods are not a first-class construct and, as such, and only be referenced via their containing class. But we will be getting a nice scala-friendly way to access members via reflection, including default params, parameter names, etc.

I don't recall where, but I stumbled across a Java library recently that would take Java classes as input and generate a metaclass, so to speak, that had static fields (I think) that were references to all of the fields and methods on the target class. It's certainly not as elegant as what you're looking for, but it struck me as a potentially useful bit of wizardry.