Develop Reference

Languages that compile to Java Bytecode and can run on the JVM

I am an embedded programmer and working with an embedded JVM.
This enables running Java files on constrained devices.
These Java files are first compiled to bytecode into .class files which are then further optimized and uploaded to the device which has a micro JVM to run the optimized bytecode.
The micro JVM does not support all features, e.g., no reflection.
The main benefit is obvious: this allows programming in Java for constrained devices.
However, I was thinking that plenty of languages compile to bytecode, some are listed https://en.wikipedia.org/wiki/Java_bytecode.
So in theory these languages could also be used to program.
I'd like to obtain a list of common languages that compile down to bytecode and was wondering if you could help.
For example, Python has special implementations that reduce to Java Bytecode, if I'm not mistaken, and stuff like C to Java virtual machine compilers also exist.
So what languages would you think are logical to try and run on the devices? Any pointers on how to or similar experiences?
Also, I'm not clear what the difference is from reading Wikipedia between (Python) bytecode and Java bytecode, could anybody help explain that?

I'm agree with you about the overall idea and it would be nice to develop an embedded application using any language that can run on a JVM. But there are some practical issues that you should consider and I think that's why none of major vendors or open source initiatives have any active/serious project on this (as far as I know).
As you mentioned, a JVM implementations that can run on embedded devices, each have their own constraints and limitations. The most obvious one is that some packages may not be available at runtime. In order to apply such a constraint, you should either control it in the compile process or have a toolchain (sort of an SDK) which accepts the bytecode and checks such constraints.
This situation would be worth when a developer tries to use a third party library that is available for that specific language. It's not easy to guess if a library is safe for use against such a framework or not.
One great facility for developers would be to have their IDE check such issues on the fly (something like inspection in IntelliJ Idea). This makes it much more smoother to move toward using such a solution. But again the problem is that for each such languages there need to be a specific plugin compatible with their own syntax.
Also some of JVM languages that are actually implementation of an existing language (e.g. Jython or JRuby) are most of the time out of sync with the original language in case of supporting libraries/syntax changes of that language.
Anyway, I think in order to have a list of JVM languages you could easily find them on Wikipedia. Maybe you mean those who may worth considering in this regard by having a large community and tools support. In my opinion, you should focus on the following JVM languages as those who may worth to include in your final list:
Groovy
Kotlin
Scala
These are all pure JVM languages and are only using different syntax than Java.
Regarding the topic in general, I should say that when you search for embedded JVM implementations, you'll notice that it's also a fairly academic concepts and they're so many publications in this topics regarding the overall architecture, threading support, toolchain, error handling, memory management, etc. This means that you should have a very great experiences/background on both embedded systems and programming language concepts and implementation to be able to devise a proper architecture for such a platform.
About your last question regarding the difference between Python bytecode and Java bytecode (if I understand your question correctly), these are both conceptually the same but each has its own syntax and constraints. The bytecode concept refers to the piece of software that is the output of the compiler and is the platform independent representation of the original code and can be run/interpreted at runtime by another software component which is the virtual machine. In Java world, this software is called the Java Virtual Machine (JVM). I'm from the Java world so I don't know what it's called in Python vocabulary but it should be something similar (e.g. Python virtual machine).
I think due to the complexity of developing such a toolchain and also considering the unprecedented development of new IoT and SoC devices, many of them capable of running a more higher level operating systems, maybe in a long run most developers prefer to develop for a more high end devices using more high level APIs and SDKs. Who knows! In that case, we would have a same situation that we're in today for PCs. Languages like C and Assembly are still in use, but they have their own domain of applications. I mean throughout the time, layers of abstraction are being added on top of the previous one. The same thing can happen for embedded devices.

Threading in application programming

Why is it that the C threading library (pthreads) not as popular as the java one when it comes to application development?
Is it just the memory management issue or are there other major advantages involved?

pthreads are not implemented natively on all OSes, such as Windows (there is a Win32 API for that). In fact, C as a language has no concept of threads.
Java was built with threads integrated into the language. C was not.

It's not entirely portable -- pthreads is parts of POSIX, and not normally provided under (for one obvious example) Windows.
C++ 0x adds threading primitives to the standard library (and they're mostly quite similar to pthreads) which is what most new code is likely to start using fairly soon (and some already does).
pthreads are also fairly low-level and kind of a pain to use well; many application programs will probably be better off using futures (roughly similar to the Java objects of the same name) for many of the relatively simple threading situations.

It depends completely on which type of application you have in mind writing. Perhaps the applications you're referring to are more convenient to write in a high level language such as Java.

In addition to the matter of (non-)portability mentioned by others, systems that implement pthreads often also implement cheap and easy multi-process programming, and that was how parallel unix programs were written for a very long time.

I'd say threading is too popular in Java, for example because it is hard to do asynchronous I/O. It looks to me like libraries in Java are designed with the attitude that threads are good. Library designers using C simply have the opposite attitude :)

The Qt framework offers a platform independent implementation for threads in C++.
It has borrowed extensively from java and is a lot newer than some the libraries mentioned earlier so its still gaining in popularity.

Surely this is a question about the popularity of Java vs C rather than one library over the other. I imagine most developers select the development language not the threading library. Once the language is selected this constrains the library choice; after all you cannot use pthreads in Java.
Another point is that in C there is no standard threading library, although pthreads is commonly available on many platforms.
I also doubt the premise; if we assume that you really mean that Java is more popular than C (since that is perhaps the implication), then I doubt it is true generally. In certain application domains maybe, but it is not an easy thing to measure. Depending on how you measure it, you can make Java, C, C++, PHP, JavaScript, Python, and even D look like the world's most popular programming language.
It is possible I suppose that if you choose to use multi-threading, this may lead to a decision to prefer Java (though I doubt that too), but that is a different decision process than choosing pthreads over Java threads.

Java is mainly application programming language so more people and companies are on to it, whereas c is more of a system level programming and core programming which is less popular compared to application programming.

Status of VB6/ Best Desktop Application Language with Native Compilation

I was looking for a Desktop Application Programming Language with one of the biggest constraint: - “I need to output as native executable”.
I explored multiple options:
Java is not a very good option for desktop programming, but still you can use it. But Java to Exe is a problem. Only GCJ and Excelsior-Jet provides this.
.Net platform does not support native compilation. Only very few expensive tools are available which can do the job.
Python is not an option for native compilation. Right?
VB6 is the option I am left with.
From the above list, if I am correct, VB6 is the only and probably the best option I have.
But VB6 itself has issues like:
It is no more under development since
There are questions on support of VB6 IDE with Vista
Thus my questions are:
From the list of programming language options, do you want to add any more?
If VB6 is good/best option, looking at its development status, would you suggest using VB6 in this era?

Delphi (and its underlying Pascal language) is still alive and well, with the 2010 edition recently released; if you have funding (a minimum of $899 for the cheapest edition, I believe). it may be worth your time to download a try a free-for-30-days (or something like that) version.

Out of curiosity, what are the driving factors behind the "native-binary-only" constraint?
As others have said, it's essentially impossible to prevent reverse engineering. (I realize the answer I linked to is in the context of .Net, but it applies to all programs.)

You added a comment saying it is because .NET and java can be decompiled that you don't want to use them. You could use an obfuscator which makes the output code harder to read.

Visual C++ is an option, though unfortunately the free version is a bit crippled from the point of view of building MFC-based applications.
You can also choose to use a different GUI framework than MFC, such as wxWidgets or Qt. With these frameworks a GCC compiler (such as MinGW) can be used. There are several free IDEs that are supposed to work with one or both of those frames works including Qt Creator or Code::Blocks.
I've heard good things about Delphi, but don't know anything else about it.

I was involved in a hunt for a similar language/platform for a client to replace their VB6 application. Although they eventually decided to webify everything and rewrite it all in Flex, they were briefly looking at RealBasic. VB6-esque syntax and it compiles to native binaries.
I can't speak for what it's like for day to day use; the trial looked ok. A bit of the RAD oh-that-didn't-take-long workflow that VB6 had and very little else has got anywhere near. Not unreasonably expensive for the Personal Edition.

Check out 'Power Basic' - It compiles 'true' small native EXEs and provides a fast VB like basic environment, and doesn't require a run-time environment. This makes it much harder to disassemble. It isn't VB, but its affordable and powerful.

VB is an interpreted language not native although I guess there are native compilers. Also it's runtime support is not guaranteed past windows 7. The IDE and runtime have a few issues in windows vista and 7 mainly related to UAC and network drives.
I would suggest delphi or some c variant if it must be native.

Cross-Platform Programming Language with a decent gui toolkit?

For the program idea I have, it requires that the software be written in one binary that is executeable by all major desktop platforms, meaning it needs an interpreted language or a language within a JVM. Either is fine with me, but the programming language has to balance power & simplicity (e.g. Python)
I know of wxPython but I have read that it's support on Mac OS X is fairly limited
Java sounds good & it looks good but it seems almost too difficult to program in
Any help?

I used Python with wxPython for quite a while and found it very easy to use. I now use Java with both Swing and SWT.
I prefer Java but that's just a personal preference so you shouldn't let that sway you.
I didn't find the transition from Python to Java that difficult. In terms of GUI, they both have the layout manager paradigm - the managers are different but not so different you'll have trouble switching.
Java has an absolute huge class library to the point where you probably don't need to write your own version of anything, just string together the components. I never really got that deep into Python but it may well be similar. One thing I did notice is that all the really good stuff I used in Python (e.g., s[-4:-1]) could still be done quite easily in Java. Both languages were a step up from C where I had to manage strings with my own libraries.
If you think wxPython is limited on MacOS, you should try Java. I run my Java code on Windows, Linux and other UNIXes without compatibility problems. Sadly, not Mac, so I can't really advise you there.
My advice, pick a smallish project - do it in both Python and Java - see how it runs on all the platforms you're interested in.

Python with PyQt or the eventually-to-be-equivalent-but-gratis PySide seems the way to go -- after all, few languages are easier to program in than Java (which you consider "almost too difficult to program in"), Python is one of those few, Qt arguably the best cross-platform GUI toolkit in any language, and PyQt (now, but GPL or for-$$$) or PySide (eventually, gratis even if you want to close-source your own code) are powerful interfaces between Python and Qt.

You can use any of languages targeting JVM, e.g. Jython (Python impl) and JRuby (Ruby impl).
You can try using Qt bindings for Python, Qt seems to support many of Mac OSX specifics.

Consider Tcl/Tk. I'm not sure how you define "one binary that is executeable [sic] by all major desktop platforms" but Tcl probably meets this as well as java, and likely better than any other scripting language.
Using the tcl packaging technology of starkits you can either a) create a single file that can be run on any platform that has an appropriate runtime engine (and they are available for all major and many minor platforms), or you can package that platform-specific runtime engine and and cross-platform starkit into a single file executable for each platform.
The starkit technology is something other languages should aspire to. What you get is a complete, fully functional virtual file system within a single file. This lets you easily package up sound files, dll/.so files (which must be copied to disk for obvious (?) reasons), images, data, etc along with your executable code.
Tk, the graphical library, is very mature and has really good support on all platforms. Some people think it looks dated but those impressions are usually based on information that is at least 5 years old. Modern Tk looks quite good. For some examples see the tkdocs website. I's not clear whether you're more concerned with eye candy or functionality, but if it's functionality you're interested in then Tk is something to seriously consider.
Most agree that Tcl is an aquired taste but those that use it professionally usually swear by it. I've been doing wxPython programming the last several months and would switch back to tcl/tk in a heartbeat if given the opportunity.

You could use Groovy to work around the Java complexities.
Still you'll need good foundations of Swing.
While the learning curve may be steep, the trade of of not having to completely re-write the whole application again for the next platform will be a good reward.
Bear in mind, that even though it is cross platform, you should consider different platforms still have different idioms ( e.g. Copy/Past in Windows is ctrl+v, ctrl+v while in Mac it is cmd+c, cmd+v )

I work on a program that has to run on Windows, Linux and OS X (and OS X is my development platform), and wxPython is what we use.
If I had a chance to start again, I'd probably go with PyQT (based on advice from friends), but wxPython will get the job done.

I think wxPython is pretty good, though I am not sure what you mean by "support on Mac OS X is fairly limited" but I have been porting a wxPython app (www.mockupscreens.com) to Mac and it wasn't that difficult with few tweaks e.g. some UI elements may not come up as you expected, as wxPython uses native UI elements, which can be an advanatage or disadvantage based on your requirements.
Other good option is PyQT which will give you consistent look on all platforms.

Java seems better for what you want.
Well what about the web application in Javascript?

How about SWT
Cross Platform
Native Look and feel
Huge community
Constantly maintained/upgraded ( IBM backed )
Atleast one mega successful cross platform project

I would suggest going the wxPython route, I know that wxWidgets (which is what wxPython is using) can be made to have great looking Mac apps (look at PgAdmin3 from postgresql). While PgAdmin3 is not done in python, it was done with wxWidgets and looks fine on a mac.

I use three cross-platform tools regularly: Realbasic from Realsoftware which is what Visual Basic v6 would have been if allowed to grow; Revolution from Runrev which is what Hypercard would have been if allowed to survive (and its neat using a scripting language whose syntax is basically English); and finally, Delphi Prism with Mono.
All are quite mature and yet expanding at a great rate. For instance, Revolution is just introducing a web-application feature to its language that is really easy to use.

Delphi versus C++ Builder - Which is Better Choice for a Java Programmer Doing Win32

I'm a pretty experienced Java programmer that's been doing quite a bit of Win32 stuff in the last couple of years. Mainly I've been using VB6, but I really need to move to something better.
I've spent a month or so playing with Delphi 2009. I like the VCL GUI stuff, Delphi seems more suited to Windows API calls than VB6, I really like the fact that it's much better at OO than VB6, and I like the unit-testing framework that comes with the IDE.
But I really struggle with the fact that there's no widely-used garbage collector for Delphi - having to free every object manually or use interfaces for everything seems to have a pretty big impact on the way that you can do things effectively in an object oriented way. Also I'm not particularly keen on the syntax, or the fact that you have to declare variables all at the top of a method.
I can handle Delphi, but I'm wondering if C++ Builder 2009 might be a better choice for me. I know very little about C++ Builder and C++, but then I know very little about Delphi either. I know there's a lot to the C++ language, but I suspect it's only necessary to know a subset of it to get things done productively... I have heard that the C++ of today is a lot more productive to program in than the C++ of 10 years ago.
I'll be doing new development only so I wouldn't need to master every aspect of the C++ language - if I can find an equivalent for each of Java's language features I'll be happy enough, and as I progress I could start looking at the more advanced stuff a bit more. (Sorry if that sounds painfully naive - if so please set me straight!)
So, for a Java programmer that's new to both Delphi and C++ Builder, which would you consider to be a better choice for productive development of Win32 exes and dlls, and why? What do you see to be the pros and cons of each?

Delphi or C++ Builder - it's a difficult choice!
As you're aware, they're basically very similar, from the IDE and RAD point of view.
The pros and cons of each - irrespective of background - are a bit like this. Both share a great 2-way RAD form designer and framework (VCL) that are ideal for native Windows development.
Delphi:
FOR: Large, active, enthusiastic community
FOR: Delphi 2009 is the best version for many years
FOR: Delphi "units" make C source/header file pairs seem archaic
AGAINST: No automatic destruction as objects leave scope, hence lots of 'finally's in your code
AGAINST: Language can be 'wordy', which is a matter of taste
AGAINST: Using third-party DLL's or libraries in other languages (esp. C) requires Delphi header files to be written
C++Builder
FOR: C++Builder 2009 is probably the best version ever
FOR: RAII idiom simplifies memory management hugely
FOR: Templates are incredibly useful and powerful, even if the C++Builder implementation has some bugs with them.
FOR: Support for BOOST and other modern template-based libraries (even though the Boost support is not 100%)
FOR: Great interop with Delphi means most Delphi components can easily be used.
FOR: Easy to use with third-part DLLs/libraries with C/C++ headers.
FOR: C++ may look better on a CV than Delphi.
AGAINST: CB2009 is "unicode only" - the implications of this for code portability are different and less well thought-out than for Delphi
AGAINST: C++Builder user-base is much smaller than Delphi. Maybe 20% or less.
AGAINST: Borland/Inprise nearly killed BCB a few years ago, and it was only resurrected after major efforts from the community. (However, Codegear/Embarcadero commitment does seem impressive)
AGAINST: C++Builder is not top of the pile within Codegear.
AGAINST: Third-party component vendors don't always understand/support C++Builder
That's about it. Just to state my position, I'm a happy BCB2007/2009 user (since BCB5), and I also infrequently use Delphi. A few years back, I considered a switch from C++ to Delphi, but the lack of RAII idiom was the one thing that I found difficult to come to terms with.

Go with Delphi and you can use the Boehm Garbage Collector API written by Barry Kelly so you can have garbage collection in Delphi. Barry wrote this before he went to work for CodeGear as a compiler architect. It does have issues with really large applications, and most likely won't work with 64-Bit Delphi. He talks about it quite a bit in this podcast interview.
Even if you don't use that garbage collecting memory manager, I would still recommend Delphi over C++. The only advantage C++ gives you for general development is the curly brace syntax. If you don't mind the Delphi syntax, then for most things you will find it better. Granted C++ Builder has the whole Delphi VCL and RTL, so it isn't as bad as Visual C++, but I still think Delphi would be a better choice.
For Excel add-ins (as you mentioned in your comment) I would recommend Delphi over C++ builder because it has better COM support (which I believe you need for Excel add-ins).

Delphi will be a lot easier for you to come to terms with, sure you have to manage your memory, but its very simple
MyObj = TMyObj.Create;
try
MyObj.DoSomething;
finally
MyObj.Free;
end
In Delphi all your objects are allocated on the heap, so the rule is very simple if you create it you free it.
C++ with its stack and heap based objs means you have a little more to learn and more scope for getting into trouble.

After working with Borland C and C++ compliers since BCC 4.1/DOS and Delphi from 3.0 thru 2007 I can tell you honestly that you're in for a great adventure either way. Moving from C/C++ on Borland's Builder and RAD IDE's is a substantial paradigm shift (and learning curve) from Microsoft's VC++, C++ and .NET (have used VC from the first MS-DOS release -- the beige three ring mini binders).
The choice between C++ and Delphi is one I suggest you make after getting your feet wet on a few small to mid sized projects in both languages. I started out a C programmer and after about five years switched to Delphi (V3.0) when the VCL just made Windows programming a lot easier and more productive.
Be warned, Delphi is a seductive language for programmers coming from other languages like COBOL, FORTRAN, VisualBasic because its syntax and code rules enforce a kind of discipline that keeps one out of trouble. The terseness and raw metal power of C makes it a great systems programming language (device drivers, O/S code, real-time embedded programming), but in inexperienced hands it can bite you.
Borland's C++ Builder (Delphi's VCL added to C++ compiler) takes many of C++ sharp edges off and is my second favorite language. Since Borland added .NET support to both languages
there's a strong argument to use Builder instead of VC++ for MS framework programming. Although C# has a good amount of 'friendliness' built in compared to C++, if pushed I'd still stick to Delphi or Builder if I was just starting out.
For learning the ropes, for prototyping and quick concept programs there is simply not a language out there that can beat Delphi especially with the VCL and the third party components. No hype, just facts.

Personally, I think there are other important considerations apart from the differences between the languages. For example, the Delphi IDE is totally freakin' awesome for building GUIs in a WYSIWYG fashion. I haven't used the C++ builder IDE, but I'd be really surprised if it has a GUI builder that's as nice as Delphi.
Although superficially the syntax of C++ looks more like that of Java, Delphi's object model is actually closer to that of Java. Although pointers exist in Delphi, in practice object references (like those in Java) are used 99% of the time. Even in modern C++, I don't think it's possible to avoid pointers. Not that there's anything wrong with pointers per se, but in practice....
On a personal note, I'm mostly a Java guy these days, but I spent 2 years working with Delphi and would go back to it in a heartbeat. In contrast, I have only very limited experience with C++ and would prefer to clean toilets than return to that language :)

I think if you go with Delphi you will find it more easier after few times of using, also it has more third party support and some of the features introduced in Delphi before C++ Builder
also read this blog from ex-Java and now the guy behind most of database and datasnap work in Delphi Steve Shaughnessy, about his experience about programming Delphi after 10 years of Java :-)
http://blogs.codegear.com/steveshaughnessy/2006/12/03/30193

Of course java sintax is more like c++ than like delphi, but I think that the object model is more similar to delphi:
single inheritance. Interfaces exist but are more like COM than like java interfaces.
objects are allocated on the heap and accessed by reference
you can find a paper comparing the three languages here

There is nothing I haven't been able to do in C++ VCL that I couldn't do with Delphi VCL and almost all Delphi components work fine in C++ Builder. Since I program for both Windows and UNIX, C++ is more portable.
If you use C++ STL or an other well designed library for your containers, garbage collection sort of becomes a moot point, and otherwise manual GC is not difficult (one quickly learns good habits - which you should be practicing anyways irrespective of a GC). As long as you use RAII where possible, keep your memory management encapsulated in containers, be clear on object ownership and only use pointers as nilable references (all of which you should also be doing irrespective on the language), GC really should not be an issue.

"For example, the Delphi IDE is totally freakin' awesome for building GUIs in a WYSIWYG fashion. I haven't used the C++ builder IDE, but I'd be really surprised if it has a GUI builder that's as nice as Delphi."
Actually the C++Builder GUI editor is exactly the same editor, and works in the same way. It is fantastic.
.Net has a huge number of classes, much like Java. C# has similar syntax to Java and because of the huge class library works fairly similarly. And it's a perfectly adequate environment to program in. But frankly Delphi is a much more pleasant language, IDE and general environment to work with. C# was designed by the same person who designed Delphi and "feels" very similar in many ways, so don't assume that because Delphi compiles to native code (though you can use Delphi .Net as well) it's fundamentally harder to use. It's not, at all.
My personal recommendation would be for Delphi, because it's a cool language. However if you're interested in learning C++, C++ Builder is probably the nicest way you could do it.

I program professionaly in Delphi for the last 10 years and have a good knowledge of C++.
I'd go to the Delphi way. Syntax is much simpler and memory management also. That GC for native Delphi I don't have heard yet... Although I didn't like much the traps on Delphi.Net code introduced because of the .NET gc, I'm not much fond of gcs ;-)

One thing I forgot to mention before:
From a cost perspective, you don't really need to choose. Buy the RAD Studio package, and for a modest extra cost over one individual language, you get both Delphi and C++Builder personalities in the same IDE.
And, it's worth mentioning that the C++Builder package includes the Delphi compiler, and you can write/add Delphi .pas files and include them as part of your C++ projects.

If you're going to do a lot of Windows programming, learn C++. Would you learn German in preparation for a trip to France? C/C++ is the native language of the Windows API. Dealing with WinAPI data structures and calls is so much simpler in C/C++. As to RAD, I've used MSVC for about 13 years and I can whip together a GUI app as quickly as anybody using Visual Studio's GUI editor.