We Keep Coding

Java: but you need to make each JVM, don't you?

I'm just starting to learn Java (as the second language from Python), but I can't understand the very first point of it. From my understanding, it says:
"Making each kind of compiler (e.g. of C/C++) to each kind of CPU is too much of a hassle. Java, on the other hand, works universally once JVM is installed, because its intermediate code is interpreted by JVM, rather than making a specific native code."
...but don't you need to implement each kind of JVM to each kind of CPU? Is this really an advantage of Java over C/C++?
I think there's a duplicate about this in SO or elsewhere on the internet, but sorry, I couldn't think up any good search word.

each kind of JVM to each kind of CPU is implemented by folks from oracle and other JVM vendors: in case of C/C++ you have to compile YOUR application code for each CPU/OS

Yes, someone has to make a JVM to be able to run on different platforms, but that someone isn't you.
If you go to the download link for Java https://java.com/en/download/manual.jsp you can see there are various JVM builds for Windows, Mac, Linux and Solaris etc
As a programmer, you just have to write your own code and compile it into .class files. Then it's someone else's problem to provide a JVM to run those class files on a specific machine.

Yes someone need to implement each kind of JVM to each kind of CPU? And if this JVM is going to be used, it will also contain a jit compiler, so not much benefit compared to just writing a compiler.
But it might be talking about using the jvm as a target for your own compiled language.
Imagine this: You want to make your own language. Lets call it MyLanguage. Normally you would have to write a compiler, for each cpu, and lots of support code for each operation system you want to support.
But if you just write one compiler which compiles MyLanguage to java bytecode, then the user can run the java byte code on a JVM.
Your language can then be used on any processor/operation system currently supported by a JVM. And you only had to write one compiler.
This is for example what the developers of Scala did.

What should a Scala developer know about Java and/or the JVM?

So up until about 6 months ago, most of my work (big graph processing) consisted of Python and C++. Up to that point, and even now, I had not written any Java whatsoever.. I had seen the language and was familiar with the syntax (having come from a C/C++ background), and liked the idea of the JVM, but never actually written any substantial amount of Java.
When I picked up Scala, I loved it, OOP and functional programming features all in one, and it being on the JVM was great. I've been constantly striving to improve my Scala and have been playing with Akka, and still loving it. However, at times, perhaps it is just me overthinkng it, but I feel I should learn some more about Java and/or the JVM.
I've heard from many that Scala should be considered a separate language from Java, much like C++ to C. Perhaps you may feel the same way, and perhaps learning Java is more or less disjoint from learning Scala, but I'm feeling learning more about the JVM (e.g. JIT compilation, type erasure) would be helpful?
Thoughts?

The JVM executes Bytecode and it is definately helpful to know how this works, just as it is sometimes helpful to know how C/C++ method invocations work or how classes are initialized; because sometimes it matters and cannot be abstracted away.
Java is the prime language for the JVM, and it is helpful to be able to read Java to some extent if you need to use Java classes directly. And this may happen quite often; only a few examples:
you need to use some third party Java library (and there are tons)
working with Properties
you need to do something special in Swing which is not supported by the Scala-Swing wrapper
also sources explaining stuff for 1) will most probably use Java examples
But my advice is not to study it in advance - you'll pick it up when you need it.

Buy this book now: Java Performance. It was only released last October and is a treasure trove of information for anyone who wants to understand the JVM. If you're going to be a Scala developer, you must understand garbage collection and JVM runtime parameters at the very least.

Off top of my head
primitives, autoboxing, and how java arrays are special;
erasure and manifests
how logically tail recursive calls in scala source are compiled
installing -client, -server on your platform and when you want to try 32 bit: e.g. JAVA_HOME and "Java preferences" in OS X. I think openJDK should work anywhere you use same version of Oracle JDK, but IntelliJ warns you to use only official Oracle JDK. I've seen very isolated reports that 3d graphics libs have had problems with openJDK, and also parts of openJDK like the fonts have licensing issues.
setting classpaths in REPL, as compiler option, and in SBT
Hotspot switches, XMX, XMS (heap settings), most common garbage collectors, inlining method calls
java.util.concurrent
possible binary compatibility issues with java and scala code compiled in JDK 6 and 7.

I don't know exactly what you need, but there are several similar questions on SO, look it.
Understanding JVM Better
Understanding the Sun JVM
Also, here good articles for Java Memory Model
Java theory and practice: Fixing the Java Memory Model, Part 1
Java theory and practice: Fixing the Java Memory Model, Part 2
My thought it's better to dig in Java language, write some code, read Java-specific books for better understanding how all things works.

There are a lot of tools surrounding the JVM. If you want to understand how your programs are running (for performance or other reasons) then it's worth being au fait with these. Two useful tools are:
jstack
visualvm
Both are particularly useful for monitoring and interrogating long-running processes.

I think you will know more about JVM when you program Scala. I mean you will have more questions like 'Why this solution is slow and that is fast?' - one way to answer this question is to check the bytecode

Which parts or packages can be removed from JDK?

There are a lot of packages built in the jdk, and the size of jdk is biger and biger. But I found there are a lot of packages I never used, or they have a better 3rd party replacement.
So, which packages do you think can be removed from JDK, or we don't need to use them?

So, which packages do you think can be removed from JDK, or we don't need to use them?
Unless you mean this as an subjective question of what "we think is superfluous" (in which case the question should and will get closed quite quickly), you are the only one able to tell which packages you don't need.
I'm not sure though, why you would want to strip down the JDK. The JRE would perhaps make more sense to strip down on a system with really limited resources. If you wish to do this, Google provides many good urls.

So, which packages do you think can be removed from JDK, or we don't need to use them?
I don't think a cut down JRE is a good idea.
Lets think about the reasons why you might want a cut down JRE:
"The size of a JRE is getting bigger". But the size of hard disks is getting bigger more quickly.
"The size of JRE installers is getting bigger". But the speed of networks is getting faster more quickly.
"The JRE is using more and more memory". Most likely it isn't. A running Java application only loads the JRE classes that it actually uses. A command line "hello world" program does not pull in Swing, CORBA support, the XML parsers, or anything else that it doesn't use.
"But it is using too much memory". Really? If you think so, consider using Java ME .... and learn to live with the downside of a cut-down class library.
And to answer your question. I don't think any of them should be removed. They are all useful to a lot of people some of the time. And if any of these packages were removed, from the standard JRE it would break compatibility for many, many existing applications.
And the packages cost very little in the case where they are not actually needed. At least, not in most use-cases.
In reality, Sun/Oracle have done a lot of work to reduce footprints and improve JVM startup times. And last time I looked, more work on this was on the agenda for Java 8.
If you are considering doing this for yourself, here is some free advice:
DON'T DO IT.
IANAL, but I understand that creating and shipping a cut-down binary version of the JRE is a violation of the Java software license, and of the conditions under which you are permitted to use trademarked terms like Java, JRE and so on.

The first thing that comes to my mind is the project Jigsaw I'm not sure whether it is still active, but should still be a good starting point.

Learning about Java bytecode and the JVM

In a recent question asked recently my simple minded answer highlighted many of my misconceptions about Java, the JVM, and how the code gets compiled and run. This has created a desire in me to take my understanding to a lower level. I have no problems with the low level understanding like assembly how ever bytecode and the JVM confound me. How object oriented code gets broken down on a low level is lost to me. I was wondering if anyone had any suggestion on how to learn about the JVM, bytecode and the lower level functioning of Java. Are there any utilities out there that allow you to write and run bytecode directly as I believe hands on experience with something is the best way to grow in understanding of it? Additionally and reading suggestions on this topic would be appreciated.
Edit: Secondary question. So I have a kinda sub question, the answers gave me an interesting idea to learn about the jvm, what would the plausibility of writing a really simple language like brainf**k or Ook only in a readable syntax (maybe I could even develop it to support oo eventually) that compiles into bytecode be? Would that be a good learning experience?

Suggested reading: the JVM spec.
You might also want to play with BCEL - there are other libraries around for manipulating bytecode, but that's probably the best known one.

The Apache BCEL will allow you to analyse and hand craft .class files from bytecode.
javap will allow you to disassemble existing .class files. It's particularly useful for knocking up quick test classes to understand what is really going on underneath the covers.

I learned by reading the ASM tutorial and mucking about with the library itself.
IMHO, ASM is better than BECL.
BCEL is already being used
successfully in several projects such
as compilers, optimizers,
obsfuscators, code generators and
analysis tools. Unfortunately there
hasn't been much development going on
over the past few years. Feel free to
help out or you might want to have a
look into the ASM project at
objectweb.
- http://jakarta.apache.org/bcel/

There is only one reliable source for JVM understanding
The Java® Virtual Machine Specification Java SE 7 Edition
http://docs.oracle.com/javase/specs/jvms/se7/html/index.html

Programming for the Java Virtual Machine is a good book for this topic. (Disclosure: I work with the author.)

For understanding Java/the JVM's architecture: read Wikipedia, the specs and the source code.
For understanding how object-orientated code is done on a low level: try and emulate features like inheritance/polymorphism/encapsulation in a lower-level language like C.
In C you can achieve the above through, for example, a combination of function pointers and nested structures.

java in-memory compilation

How can i generate bytecode (Byte[]) from a String at runtime, without using a "javac" process or something of this sort? is there a simple way of calling the compiler like that?
later addition:
I chose to accept the solution that actually best fits my situation. my application is a hobby-project still in design sketch phase, and it is the right time to consider inserting new technology. also, since the guy that's supposed to help me with BL is a JavaScript developer, the idea of using a JavaScript interpreter instead of a stub compiler+classLoader seems more appealing to me in this situation. other (unaccepted) answers of this question are informative and, as far as i can tell, answer my question very well, so thanks, but I'm going to try Rhino :)

JDK6 has a Java compiler API. However, it's not necessarily very easy to use.
A quick google pulled up this example usage.

I think your best shot is going to be Janino. That will let you compile code at runtime and call it from the rest of your program. We use it in some of our systems to let us dynamically update some classes.
It's not free. It works well, but it uses permgen space every time you load a new class (or version of a class) so you will run out of memory eventually if you have a (really) long running process (or something that loads lots of new classes) but you can change the amount of permgen space in the JVM to move that barrier out quite a way if that's a problem.
Janino is actually a compiler, but you could see how it injects the bytecode if you need to operate at that level. You may need to end up making a classloader or use the Java compiler API as Tom Hawtin suggested.

You might find something like rhino or groovy more useful in practice.

You can access the compiler as long as the tools.jar file from your JDK is on the classpath. The documentation for it is here. The API isn't as simple as eval() in some interpreted languages but it is there.
You might also have to get into some weird ClassLoader code to actually run that code, I'm not totally sure about that.