Related
I'm trying to understand whether and under what circs one should use Python classes and/or Java ones.
If making a specialist dictionary/Map kind of class, should one subclass from Python's dict, or from Java's HashMap or TreeMap, etc.?
It is tempting to use the Python ones just because they are simpler and sexier. But one reason that Jython runs relatively slowly (so it appears to me to do) seems to have something to do with the dynamic typing. I'd better say I'm not that clear about all this, and haven't spent nocturnal hours poring over the Python/Jython interpreter code, to my shame.
Anyway it just occurs to me that the Java classes might possibly run faster because the code might have to do less work. OTOH maybe it has to do more. Or maybe there's nothing in it. Anyone know?
The point of using Jython is that you can write Python code and have it run on the JVM. Don't ruin that by making your Python into Java.
If -- if -- it turns out that your data structure is too slow, you can drop-in replace it with a Java version. But that's for the optimisation stage of programming, which comes later.
I guess I should try to answer your question. I would guess that using native Java structures will be faster (because the JVM can infer more about them than the Python interpreter can), but that might be counterbalanced by the extra processing needed to interface with Jython. Only tests will tell!
Generally, the decision shouldn't be one of speed - the Python classes will be implemented in terms of Java classes anyway, even if they don't inherit from them. So, the speed should be roughly comparable, and at most you would save a couple of method calls per operation.
The bigger question is what you plan on doing with your class. If you're using it with Python APIs, you'll want to use the Python types, or something that behaves like them so that you don't have to do the work of implementing the entire Mapping protocol (only the bits your class changes). If you're using Java APIs, you will certainly need to meet the static type checks - which means you'll need to inherit from Java's classes.
If this isn't easy to answer in your situation, start with the Python ones, since you (correctly ;-) find them "simpler and sexier". If your class doesn't pass outside the boundaries of your project, then this should be trivial to change later if the speed really becomes an issue - and at that point, you might also be thinking about questions like "could it help to implement it entirely at the Java level?" which you've hopefully recognised would be premature optimisation to think about now.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been a C++ developer for about 10 years. I need to pick up Java just for Hadoop. I doubt I will be doing any thing else in Java. So, I would like a list of things I would need to pick up. Of course, I would need to learn the core language, but what else?
I did Google around for this and this could be seen as a possible duplicate of "I want to learn Java. Show me how?" but it's not. Java is a huge programming language with lots, of libraries and what I need to learn will depend largely on what I am using Hadoop for. But I suppose it is possible to say something like don't bother learning this. This will be quite useful too.
In my day job, I've just spent some time helping a C++ person to pick up enough Java to use some Java libraries via JNI (Java Native Interface) and then shared memory into their primarily C++ application. Here are some of the key things I noticed:
You cannot manage for anything beyond a toy project without an IDE. The very first thing you should do is download a popular Java IDE (Eclipse is a fine choice, but there are also alternatives including Netbeans and IntelliJ). Do not be tempted to try and manage with vi / emacs and javac / make. You will be living in a cave and not realising it. Once you're up to speed with even basic IDE functions you will be literally dozens of times more poductive than without an IDE.
Learn how to layout a simple project structure and packages. There will be simple walkthroughs of how to do this on the Eclipse site or elsewhere. Never put anything into the default package.
Java has a type system whereby the reference and primitive types are relatively separate for historic / performance reasons.
Java's generics are not the same as C++ templates. Read up on "type erasure".
You may wish to understand how Java's GC works. Just google "mark and sweep" - at first, you can just settle for the naivest mental model and then learn the details of how a modern production GC would do it later.
The core of the Collections API should be learned without delay. Map / HashMap, List / ArrayList & LinkedList and Set should be enough to get going.
Learn modern Java concurrency. Thread is an assembly-language level primitive compared to some of the cool stuff in java.util.concurrent. Learn ConcurrentHashMap, Atomic*, Lock, Condition, CountDownLatch, BlockingQueue and the threadpools from Executors. Good books here are those by Brian Goetz and Doug Lea.
As soon as you want to use 3rd party libraries, you'll need to learn how the classpath works. It's not rocket science, but it is a bit verbose.
If you're a low-level C++ guy, then you may find some of this interesting also:
Java has virtual dispatch by default. The keyword static on a Java method is used to indicate a class method. private Java methods use invokespecial dispatch, which is a dispatch onto the exact type in use.
On an Oracle VM at least, objects comprise two machine words of header (the mark word and the class word). The mark word is a bunch of flags the VM uses - notably for thread synchronization. The class word you can think of as a pointer to the VM's representation of the Class object (which is where the vtables for methods live). Following the class word are the member fields of the instance of the object.
Java .class files are an intermediate language, and not really that similar to x86 object code. In particular there are lots more useful tools for .class files (including the javap disassembler which ships with the JVM)
The Java equivalent of the symbol table is called the Constant Pool. It's typed and it has a lot of information in it - arguably more than the x86 object code equivalent.
Java virtual method dispatch consists of looking up the correct method to be called in the Constant Pool and then converting that to an offset into a vtable. Then walking up the class hierarchy until a not-null value is found at that vtable offset.
Java starts off interpreted and then goes compiled (for Oracle and some other VMs anyway). The switch to compiled mode is done method-by-method on a as-need basis. When benchmarking and perf tuning you need to make sure that you've warmed the system up before you start, and that you should typically profile at the method level to start with. The optimizations that are made can be quite aggressive / optimistic (with a check and a fallback if the assumptions are violated) - so perf tuning is a bit of an art.
Hopefully there's some useful stuff in there to be going on with - please comment / ask followup questions.
Learning "just enough" Java is learning Java. Either you learn all the core principles and language design decisions, or you suffer along making easily avoidable mistakes. Considering that you already know how to program, a lot of the information can be skimmed (with an eye for where it differs from other languages you are intimately familiar).
so you need to learn:
How to get started
The language itself
The core, essential classes
The major Collections
And if you don't have a build framework in place, how to package your compiled code.
Beyond that, nearly every other item you might need to learn depends heavily on what you intend to do. Don't discount the on-line tutorials from Oracle/Sun, they are quite good (compared to other online tutorials).
Hadoop can use C++ : WordCount example in C++
You can't really use Java without knowing these packages in the standard API:
java.lang
java.util
java.io
And, to a lesser degree:
java.text
java.math
java.net
java.lang.reflect
java.util.concurrent
They contain a lot of classes you'll need to use constantly for pretty much any application, and it's a good idea to look through them until you know which classes they contain and what those are good for, lest you end up reinventing wheels.
Take it easy, learning Java could be
pleasant and fast if you already know
C++
Buy these two books:
The JavaTM Programming Language, (4th Edition) Ken Arnold, James
Gosling, Davis Holmes
Effective Java (2nd Edition), Joshua Bosh
You will soon be mastering Java, You will not regret. Good Luck.
Since C++ and Java share common roots, the core language shouldn't give you too much trouble. You will need to become familar with the java SDK, particularly java.lang and the Collections framework (java.util.)
But perhaps learning java is overkill if you don't see yourself using it elsewhere. Hadoop also has bindings to Python - perhaps learning python would be a better alternative? See Java vs Python on Hadoop.
Here is the quickstart for all you will need
I suggest Eclipse (java) to start working, see this for that
Maybe you don't even need to know Java to use Hadoop.
Pig is far enough from simple to advanced usage of Hadoop.
I don't know how familiar are you with other higher level programming languages. Garbage collection is an important function in Java. It would be important to read a bit about the GC in your VM of choice.
Besides the obvious packages, check out the java.util packages for the collection framework. You might want to check out the source of some classes. I suggest HashMap to get the idea of the computing/memory cost of these operations.
Java likes to use streams instead of buffers when processing large amounts of data. That may take some time getting used to.
Java has no unsigned types. Depending on the packets of data you need to process at once you can either use larger variables and streight arythetics (if we're talking about relatively small packets), or you have to (b[i] & 0xff) every time you read for example unsigned bytes. Also note that Java uses network byte order (msbf) when serializing multibyte numbers.
The most beloved design patterns by the API are Singleton, Decorator and Factory. Check the source of JFC itself for best practices, how these patterns are achieved in the language.
... and you can still post more concrete questions on SO :)
Answer 1 :
It is very desirable to know Java. Hadoop is written in Java. Its popular Sequence File format is dependent on Java.
Even if you use Hive or Pig, you'll probably need to write your own UDF someday. Some people still try to write them in other languages, but I guess that Java has more robust and primary support for them.
Most Hadoop tools are not mature enough (like Sqoop, HCatalog and so on), so you'll see many Java error stack traces and probably you'll want to hack the source code someday
Answer 2
It is not required for you to know Java.
As the others said, it would be very helpful depending on how complex your processing may be. However, there is an incredible amount you can do with just Pig and say Hive.
I would agree that it is fairly likely you will eventually need to write a user defined function (UDF), however, I've written those in Python, and it is very easy to write UDFs in Python.
Granted, if you have very stringent performance requirements, then a Java based MapReduce program would be the way to go. However, great advancements in performance are being made all of the time in both Pig and Hive.
So, the short answer to your question is, "No", it is not required for you to know Java in order to perform Hadoop development.
Source :
http://www.linkedin.com/groups/Is-it-must-Hadoop-Developer-988957.S.141072851
Most of the stuff should be pretty familiar to you. I'd just download eclipse and google a tutorial site. Familiarize yourself with classloading, keywords. One tricky thing a lot of C++ guys run into is how to run a java app so that it finds its library classes(sort of analogous to dynamic linking). Learn the difference between the JRE and JDK. If you can get a few hello world type apps working you ought to be able to get a start on hadoop if you follow the tutorials.
You dont need to learn java to use hadoop.
You need to know linux to installand configure hadoop
then you can write your map reduce jobs using the stream line api on any language which understand standard input/output
further you can do more complex map reduce using other libraries like hive etc
even other components of hadoop like hbase/ cassandra also has clients on most of the languages
I'm interested in programming languages well suited for embedded programming.
In particular:
Is it possible to program embedded systems in C++?
Or is it better to use pure C?
Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded?
What about Java in this domain?
Thanks.
Is it possible to program embedded
systems in C++?
Yes, of course, even on 8bit systems. C++ only has a slightly different run-time initialisation requirements than C, that being that before main() is invoked constructors for any static objects must be called. The overhead (not including the constructors themselves which is within your control) for that is tiny, though you do have to be careful since the order of construction is not defined.
With C++ you only pay for what you use (and much that is useful may be free). That is to say for example, a piece of C code that is also C++ compilable will generally require no more memory and execute no slower when compiled as C++ than when compiled as C. There are some elements of C++ that you may need to be careful with, but much of the most useful features come at little or no cost, and great benefit.
Or is it better to use
pure C?
Possibly, in some cases. Some smaller 8 and even 16 bit targets have no C++ compiler (or at least not one of any repute), using C code will give greater portability should that be an issue. Moreover on severely resource constrained targets with small applications, the benefits that C++ can bring over C are minimal. The extra features in C++ (primarily those that enable OOP) make it suited to relatively large and complex software construction.
Or is C++ OK only if some
features of the language (e.g. RTTI,
exceptions and templates) are
excluded?
The language features that may be acceptable depend entirely on the target and the application. If you are memory constrained, you might avoid expensive features or libraries, and even then it may depend on whether it is code or data space you are short of (on targets where these are separate). If the application is hard real-time, you would avoid those features and library classes that are non-deterministic.
In general, I suggest that if your target will be 32bit, always use C++ in preference to C, then cut your C++ to suit the memory and performance constraints. For smaller parts be a little more circumspect when choosing C++, though do not discount it altogether; it can make life easier.
If you do choose to use C++, make sure you have decent debugger hardware/software that is C++ aware. The relative ease with which complex software can be constructed in C++, make a decent debugger even more valuable. Not all tools in the embedded arena are C++ aware or capable.
I always recommend digging in the archives at Embedded.com on any embedded subject, it has a wealth of articles, including a number of just this question, including:
Poor reasons for rejecting C++
Real men program in C
Dive in to C++ and survive
Guidelines for using C++ as an alternative to C in embedded designs
Why C++ is a viable alternative to C in embedded systems design
Better even at the lowest levels
Regarding Java, I am no expert, but it has significant run-time requirements that make it unsuited to resource constrained systems. You will probably constrain yourself to relatively expensive hardware using Java. Its primary benefit is platform independence, but that portability does not extend to platforms that cannot support Java (of which there are many), so it is arguably less portable than a well designed C or C++ implementation with an abstracted hardware interface.
[edit] Concidentally I just received this in the TechOnline newsletter: Using C++ Efficiently in Embedded Applications
More often than not in embedded systems, the language you're programming in is determined by which compiler is actually available.
If you're hardware only has a C compiler, that's what you're going to use. IF it has a decent C++ compiler than there is really no reason to prefer C over C++.
I would dare say that Java isn't a very popular choice in embedded systems.
Embedded programming these days spans a large range of applications.
Roughly, it goes from sensors/switches up to complete security systems.
You should base your language on the complexity and the hardware resources.
It is 1 of the choices next to HW (CPU,...), OS, protocols,...
possible choices:
switches: assembler
router-like devices: C and/or C++
handhelds: Java or QT/C++
complete systems: combinations C and/or C++ with python
Or is C++ OK only if some features of the language (e.g. RTTI, exceptions and templates) are excluded?
It's good to be thinking along these lines. Compile-time complexity is not a big deal, but runtime complexity has a resource cost.
C++ facilitates class/namespace modularity (e.g. method foo() in more than one context) and instance modularity (member field bar belonging to more than one object), both of which are a big advantage in software design. There are also features like const, references, static casts, and templates, which can help enforce constraints and have little or no runtime cost.
I would not exclude templates. They're complex to think about and you need a compiler that handles them well, but the resource cost is almost all compile time -- what's going to "cost" you is the fact that each time you use a template with different class parameters, you produce a new set of code to instantiate member functions. But you would almost certainly have to do the same thing without templates. Furthermore, templates allow you to design and test libraries for general circumstances, in separate files that are instantiated at compile time rather than link time. Just to clarify that: templates allow you to have a file A.h that you test. Then you use it with file B.h or B.c to instantiate it at compile time. (A library would be linked in rather than compiled, and this makes it less flexible -- template methods can be optimized out so they do not incur a function call.) I've used templates in embedded systems to implement CRC code and fixed-point math: I can test the general code, put it in version control, and then reuse it multiple times by writing a simple class that derives from a template or has a template member field. The classic example of course is STL.
RTTI and exceptions: these add run-time complexity. I don't have a good idea of the resource cost but I expect RTTI would be fairly simple (just adds a type tag, costing extra space) whereas exceptions are probably beastly, involving stack unwinding.
virtual functions: I used to rule these out because of the memory + executiontime costs (minimal but still there), as well as the complexity of debugging, but they allow you to decouple objects from each other. If you don't use virtual functions, when an instance of one class (e.g. Foo) needs to execute code associated with an instance of another class (e.g. Bar), then the first class needs to know everything about the second (to compile Foo you need to have static linkage to all the methods in Bar) -- this adds a lot of tight coupling.
dynamic memory allocation: this is another big thing (that is in C as well), which we avoid like the plague at my company -- not only are there all sorts of errors that can arise, but the big runtime cost is the allocator/deallocator, and you've got to be willing and able to know what that cost is and accept it.
edit: I would love to use Java instead of C++ in the embedded world. Unfortunately my choices are limited and the runtime resource costs (code size, memory size, garbage-collecting time constraints) are too high in the space that I work in. My reason for using Java is less because of its runtime goodies and more for the fact that its software design is much cleaner, and the tools are much better (OMG! refactoring! woohoo!)... the key to me seems to lie with two things, which make C/C++ feel very clunky in comparison:
that everything is an object and all the methods are virtual, so you can lean heavily on the abstractions of interfaces.
the interface/implementation separation in Java is not this clunky ugly .c/.h file splitting thing that makes compilers so slow. In constrast, I use Java in Eclipse and it automatically compiles the code right as I edit it. This is huge! I find most of my errors right away. In C/C++ I have to wait for a whole compile cycle.
Someday I hope there will be a language between C/C++ and Java that provides the advantages of Java for software development, without requiring the bells and whistles that make Java so attractive for desktop/server applications but unattractive in most of the embedded world.
Both C and C++ can be used on embedded systems. If you do limit the features of C++ that you use, then it is going to use roughly the same speed and space as C. As for using these additional features, it really depends on your constraints. For example, if you are making a real-time system, then exceptions might not be a good idea, simply because considering the propagation time for exceptions and all the paths through which exceptions can possibly propagate can make hard real-time guarantees quite tough (although, then again, the ACE / Tao real-time CORBA implementation uses exceptions). While templates and RTTI can lead to larger programs, there is a lot of variability in embedded systems, and so depending on your resource constraints, this could be perfectly fine or unacceptable. The same goes for Java. Java (well, technically, the Java programming language with a subset of the Java API) is running on Android, for example, using the Dalvik VM. J2ME runs on a variety of embedded devices. Whether it will or will not work for your application, depends on your particular constraints.
c is the most common language used in embedded systems.
However, I think C++'s future lies in the embedded system domain. I think the C++0x standards will help in that resepect. So I wouldn't be surprised to see C++ used a lot more in this field.
I think you already have a great answer by Clifford, but I'll add my experience to it. As was pointed out, the type of embedded system is the main driver. In Defense/Aerospace, C and Ada are the most popular embedded languages I encounter. Although as time goes on, I am seeing more C++ as the model based development becomes popular with the tools such as Rhapsody. In the jobs listing, seeing requirements for Object Oriented Design experience also leads me to believe that the market is slowly shifting to follow the trends of mainstream development.
If you're really interested in embedded development, I would start with C. It is pretty universal. Almost every OS, including real time OS's like Integrity, Nucleus, VxWorks, and embedded Linux, has a compiler and tools for it. The things you'll learn about pointers, memory management, etc... will translate into C++ development well in the embedded world at least.
As for Java, if you're interested in development for mobile platforms like smart phones, this is a solid choice (Android comes to mind). But in the world of Real Time Operating Systems, I haven't seen it.
On that note, that brings me to my last point and advice. If I wanted to jump into embedded programming (which I did just 4 years ago), I would focus on learning C from a low level point of view as mentioned above. Then, I would also learn what makes real time programming so difficult/different. I found the book below quite good at teaching you to think like an embedded programmer vs. an application developer. Good luck!
An Embedded Software Primer
It really boils down to what hardware platform you're operating on and hence what software platforms are open to you. For a lot of recent embedded kit - designed around a system-on-chip, a megabyte or two of RAM, a few devices - you really want a small operating system to manage the low level hardware while you concentrate on your application. Your choice of OS then constrains your available language set.
It's certainly possible to use C++ in the embedded space, but the full feature set of the language takes a lot of work to port correctly. For example, eCos is implemented in a mixture of C and what you might call the structural aspects of C++; support for RTTI, exceptions and the STL are lacking in the free version, though there are people working on this (and a commercial port available).
Similarly, it's possible to use Java - I know, I've ported a JVM to an embedded environment; it wasn't fun - though you usually get a cut-down Java language configuration, often something based on J2ME.
I have been developing applications based on C# (.net) and Java (J2EE) for the last 3 years.
But now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
So, I am trying to learn C++, but I find it a little "confusing" due to pointer, multiple inheritance, some conventions and other concepts of C++ which don't exist in Java. So, what do you guys suggest? How should I feel about it?
Thanks
PS: I am a student, so have all the time in the world and actually shift.
In my opinion, you should learn C first in order to properly understand the base upon which C++ is built. Pick up a copy of "The C Programming Language" by Kernighan and Ritchie, widely considered the best reference on the language, and start reading through it. Once you fully understand C, you'll have the low-level base you need.
C++ is no more "basic and underlying" than any other modern programming language. It has a model of a computer (a flat memory address space), but the OS and CPU merely simulates that model using many layers of caching and paging, so it's not "real". The result is that the same operation may sometimes take 1000s of times longer to complete than at other times.
Also modern C++ has lots of powerful abstractions that have no more direct relationship with how a computer works than do the abstractions provided in Java and C#. The OP mentions multiple inheritance - clearly no more elemental than inheritance in other OO languages. Many other features of C++ omitted from Java are high-level abstractions (or allow you to build them) and so in some ways Java is the more low-level language. In Java the meaning of operator symbols is always the same, whereas in C++ a simple == might build an object that will later be used to generate a SQL expression instead of being executed in-process.
The JVM and CLR runtimes are (almost certainly) written in C and/or C++, so in that sense obviously they happen to form layers today. But at the C/C++ layer you will still be working in an abstraction that is not "how the machine really works", so you'll really just be learning a different set of abstractions, rather than "reality". And an OS (or indeed a hardware chip) can be designed specifically so that JVM or CLR like runtimes are the native low-level layer of the system; on such a system it would be the C/C++ runtime that would require a "high-level" (expensive) emulation layer in order to work.
So it is probably not worth trying to learn how to program in "reality". No one really does that these days; it's a waste of time. You're better off learning about how programming abstractions help you to write correct programs. If a language makes life difficult for you, that doesn't prove you're doing the "real thing". It just means you picked the wrong language for what you're trying to do.
I disagree with the sentiment that you need to learn C or assembly language first. C++ and C may be similar in theory but are very different in terms of practical use. One gains little to nothing in the way of C++ idioms by using only C, and while it is good to have practical experience in multiple languages, it's an exercise in futility to specify prerequisites in language learning. I think the best way to learn the concepts of programming is to sit down with someone who understands them well and just talk about it, be that on StackOverflow, in forums, or, if you're lucky, in person.
At the end of the day, I think programming really isn't all that hard, and you may need someone to explain it right just one time to have everything click. It's all about rehashing the same simple concepts over and over to build complex and beautiful machines.
For learning c++ I reccommend reading C++ for Java Programmers by Mark Allen Weiss. It helped me alot when moving from Java to C++ as it is very good at highlighting the differences between the languages.
But, now I feel, Java, C# makes you lame (from learning point of view) and you can develop your apps quickly but you fail to understand the basic underlying concepts of programming.
If you're trying to learn the concepts of programming, rather than machine architecture, there's not much benefit to learning C++. I would suggest going with something different from Java all together. A Lisp variant, perhaps.
How To Design Programs is a pretty good book.
If you want to understand the underlying concepts of programming languages, I would suggest a book such as John Mitchell's Concepts in Programming Languages. Follow this up by writing a few parsers/interpreters for simple languages. Another good resources is SICP, which is specific to Scheme (a LISP dialect), and available in full here. Once you've learned a few languages, it doesn't take too long to pick up the syntax and semantics of a new one (the core libraries on the other hand, can take quite a while to be familiarized with).
If you want to learn about how today's computers work, I'd recommend learning C and reading books such as Tanenbaum's Modern Operating Systems. C is useful in this context mostly for reading systems level code. Implementing a (very) simple operating system can be incredibly educational. However, something as simple as implementing a basic shell (like bourne shell, except simpler) is probably a better place to start. I'd also recommend learning about how networking works specifically, since it's such an integral part of modern computer systems.
C and C++ make some basic underlying programming concepts more evident, but they weren't designed by God. I'd second the suggestion to study the actual low-level systems behind your low-level code: operating systems, compilers/runtimes (try "Essentials of Programming Languages"), and machine architecture.
P.S. In general it may be better to study C++ on its own, rather than starting with C, but for your particular purpose -- getting more intimate with low-level, unsafe constructs such as pointers, after already learning Java -- I think it's better to start with C (and K&R) where these are front and center.
I would suggest learning assembly language first. This will give you a very solid foundation in what is happening at a low level. This will also help to reinforce the idea that "everything is really just an address".
Taking a class which focuses on assembly language is advisable since it will "force" you to learn it (personally, I don't think ASM is /that/ fun, but it was worthwhile [and a requirement for graduation] for me to take the class).
After you know assembly, go on to C and C++.
Have a lot of fun!
It sounds like you're avoiding the first mistake most people make, which is assuming the new language is the same as the old one. C++ is different and should be learned as a neww(-ish) language.
A reference I would suggest would be C++ How to Program which is used at my University for the introductory C++ classes.
After that, then look at previous Java software that you have written and seeing how you would translate them to C++. The syntax can easily be referenced from CPlusPlus.com. While doing this, it is important to keep in mind what all the different syntax represents, and how it changes what is going on in the software (i.e. The differences between the two languages). This has the added benefit of allowing you to see how the underlying architecture is represented for both languages (and for programming languages in general). I don't know of a good book that explains how programming languages work under the covers, or I'd recommend that.
If you are, however, interested in learning how programming works, then Assembly language would be a good place to start. Assembly language for Intel-Based Computers is what I used to learn assembly language and it was very useful.
Assembly Language.
Start with the Z-80. Then add 'x86. Then try 68000. Then the TI 320 series of DSP. You might also wish to add the Z-8. Just to see how different machines do it.
If you really want to know more about low level programming I would recommend learning C and Assembly. C++ is much more complex than C but really doesn't give you much more insight into low level concerns. It might be interesting if you want to learn about what type of concepts and constructs a programming language can be made up of though, since C++ has a lot of them.
There is also a lower level of your VM you don't seem to know yet and which you might want to explore. To learn about the internals of Java I would recommend learning how to program the JVM in (Java) Assembly language. Jasmin (http://jasmin.sourceforge.net/) is the reference assembler/syntax for this kind of programming. Another great resource is the Java Language specification (http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html) which contains a lot of Java internals. When you have learned C you can also use some lower level APIs the JVM provides (http://java.sun.com/javase/6/docs/technotes/guides/jvmti/) that allow you to retrieve low level information about a running JVM and write interesting things like debuggers.
If you learn this stuff and do some hacking on your own you will learn how the JVM works and what the compiler actually puts into your class files. It's also very likely that you discover some new things about the Java programming language itself you didn't know before even if you think you know everything about it.
You can also program the .Net VM in assembly by the way.
I think you should start with C, but not as a necessary preamble for learning C++. Rather, for learning C. In other words, while you learn C put your efforts into learning the language, feeling the philosophy of the language and focusing on letting it sip into your skin. Be a good C programmer and you will be a good programmer, period. Not just a good C++ programmer -- this has nothing to do with learning C -- but a good programmer.
There's another reason for learning C first. It's easier than C++, much easier than C++, and it bridges well to C++ (in contrast to Java, which doesn't in all aspects but the most superficial object-oriented ones). I'm not talking about the syntax similarities: I'm talking about low-level programming. I'm talking about the concepts of pointers, which exist as themselves and in the form of iterators in C++. You can pass around functions in C, and you can pass around function objects in C++. C is fast to learn, and it will warm you up very effectively.
Learning C will also eliminate the fear of free functions some pure OO programmers tend to have. C++ is a hybrid language, and C truly is a subset of C++, not just by syntax but by philosophy as well.
Start by getting yourself the K&R book and drinking it through. You won't regret this.
Whatever you start off with, my suggestion would be dump the full fledged IDE's. Use good text editors (vim/emacs)
The learning curve is better when using text editors since everything needs to be written on your own. No prompts and no pre-written code.
You have all the best answers above, in anycase. :)
Ivar
Set up a performant C++ compiling environment such as Microsoft Visual C++ 2008 Express and go through all links in Bjarne Strousrup's The C++ Programming Language site, beginning with C++ Style and Technique FAQ.
If you are experimented in any other language you don't need more :-)
Learn C and C++ at the same time, I'm talking from experience here. Very often I come across code that mixes C and C++, so it's better to know both and their differences. Pick up K&R for C (understand pointers, header files and manual memory allocation and cleaning...which are not used by Java!) and any decent C++ beginner book (I picked Prata, but whatever you are more comfortable with). Practice the same examples doing versions of C, C++ in a sequential fashion, object-oriented (OO) fashion, generic/template fashion etc. C++ has a larger standard library than C: templates, STL containers (no need for pointers, but you can do pointer fine tuning writing your own container), threads (since C++11). You can always use C if you have no choice (or Boost libraries), any C++ compiler will allow it.
If you come from Java you should already know OO concepts for C++, and, perhaps, some generic programming as in C++ templates. C++ is mistakenly regarded as an OO language, but it's more than that. BTW, objects are a dynamic concept (runtime), whereas templates are static (compilation time), so learn the language CONCEPTS, not just the syntax! Once you learn the concepts read Stroustrup's book (he created C++) to learn his philosophy for the best design rules for C++ code.
Learn the latest C++ standard (C++11) as it adds many new things to the language (auto, nullptr, threads, lambda functions, new containers, etc.). Last but not least, please use Doxygen in C/C++ the same way you used Javadoc....there is nothing worse than undocumented, unreadable code no matter what language you're using.
Learn Forth. It has better Objects. And it is a virtual machine. Unless you want a real machine see Green Arrays or Sandpiper/John Rible for that.
Free threaded interpreted versions are all over the 'net. For practice. When you understand it write your own Direct Threaded version. Or see Forth Inc and buy one for your machine or use their free windows version.
Java is a Forth/C hybrid so if you want to go Java you will have some of the stuff under your belt.
Education:
Starting Forth - Brodie
Thinking Forth - Brodie
The second is excellent for any language because it is the best book on factoring I know. Free Versions of both on the net.
If you want to do a hardware/FPGA Forth Stack Machines: The New Wave by Koopman
All the above books are free on the 'net.
Is there any rational reason, why native properties will not be part of Java 7?
There are some high-level reasons related to schedule and resources of course. Implementation of properties and understanding all of the ramifications and intersections with other language features is a large task similar to the size of various Java 5 language changes.
But I think the real reason Sun is not pushing properties is the same as closures:
1) There is no consensus on what the implementation should look like. Or rather, there are many competing alternatives and people who are passionate about properties disagree about crucial parts of the implementation.
2) Perhaps more importantly, there is a significant lack of consensus about whether the feature is wanted at all. While many people want properties, there are also many people that don't think it's necessary or useful (in particular, I think server-side people see properties as far less crucial to their daily life than swing programmers).
Properties history here:
http://tech.puredanger.com/java7#property
Doing properties "right" in Java will not be easy. Rémi Forax's work especially has been valuable in figuring out what this might look like, and uncovering a lot of the "gotchas" that will have to be dealt with.
Meanwhile, Java 7 has already taken too long. The closures debate was a huge, controversial distraction that wasted a lot of mind-power that could have been used to develop features (like properties) that have broad consensus of support. Eventually, the decision was made to limit major changes to modularization (Project Jigsaw). Only "small change" is being considered for the language (under Project Coin).
JavaFX has beautiful property support, so Sun clearly understands the value of properties and knows how to implement them. But having been spoiled by JavaFX properties, developers are less likely to settle for a half-baked implementation in Java. If they are worth doing, they are worth doing right.
Any given thing is "not done" by default, so no particular reason is needed for something to remain not done. Rather some compelling reason is needed to move something from "not done" to "planned" or "done". No sufficiently compelling reason has yet arisen for this language feature.
There are two more reasons to avoid properties in any language:
Properties are not very object-oriented. Making them easy to write encourages the pattern where the object just serves up its internal state and the caller manipulates it. The object should provide higher-level methods and keep its internals private. Next time you're tediously implementing a getter, consider what the caller will do with the data and whether you can just provide that functionality directly.
Properties encourage mutable state (through setters), which makes a program less parallelizable. As the number of cores goes up, we should all be trying to make our objects immutable to make concurrent reasoning easier. Next time you're tediously implementing a setter, consider removing it and making the object immutable.
Not enough time?
Not yet specced properly?
Difficult to add to java due to java's implementation?
Deemed not important enough, ie other things were prioritiesed?