Develop Reference

Suitable replacement for java to develop a cross-platform application

I've always used java for developing cross platform applications, however, this time java can not solve my problem. The problem is, I have to develop an application which is computationally expensive. More precisely, in my application there is a simulation which is a little too heavy. I made a java prototype app but it's not fast enough and I have some lag in my simulation so I started to think to switch to c++.
My application has a GUI and I was wondering if I want to switch to c++ for a cross platform application, what should I do with GUI?
My questions are:
If I use Qt framework, is my application going to be significantly faster?
If I deploy my jar file to native os executable (.exe, .app, etc) is my application going to be significantly faster?
p.s. Mac OSx, Windows and Ubuntu are target platforms for my software.

This Article may Help You, I Face the same questions a couple of years ago. I decided to stick with Java for my own programming experience, since I'm not that good in C++ and my project was to be honest, very simple. As you know, Java is a very spread / wide around the world, tons of docs and libraries ready for you to use, Qt is faster, but you will need to get your hands dirty to do the job. If performance is your goal, Go Qt. Or redesign your application to hava Java/Swing GUI and C++ programs server side. Anyways here's the link.
http://turing.iimas.unam.mx/~elena/PDI-Lic/qt-vs-java-whitepaper.pdf
Java/Swing may be appropriate for certain projects, especially those without GUIs
or with limited GUI functionality. C++/Qt is an overall superior solution, particularly for GUI applications.

Using C++ instead of Java improves CPU performance, sometimes as much as 10-30%. However using multiple threads also increases the amount of CPU you have available. Given using multiple threads didn't help, I suspect your bottleneck is not in CPU and switching language is unlikely to help.
Where C can help is in programming graphics cards, e.g. CUDA. You can get dramatically faster results for certain types of problems using a high performance processing card. http://www.nvidia.co.uk/object/cuda_home_new_uk.html There are JOCL libraries to use CUDA from Java, but the code which does the real work is in a C-like language.
I suggest you determine where your bottle neck really is as switching to C++ will not increase the size of your cache, your memory bandwidth, IO bandwidth or the size of your main memory.

How to approach Java 2D performance variations between different computers?

I've been designing a card game in Java on Windows. It runs really well on my laptop and a few others, but on a lot of other systems (even a few newer ones both Mac and Windows) the animation is incredibly slow.
I've found User Interface Toolkits for Java to be the best resource so far, but haven't been able to make a significant improvement. I'm using the AWT/Swing libraries.
Question:
Looking at my game, (<1.5Mb), how could it be that on some computers (of similar spec) the performance seems to be significantly less that what it is on my laptop? The entire app is event-driven and I've done most of the optimization that I reckon could be done given the implementation.
I have a feeling it is memory-related. I create (compatible) and then store all my images into an array at the start, and then reference them there.
Note: I decided to make this game so that I can learn and practice some new ideas, so I'm not just trying to share it - I'm really interested to find out what's going on here.

On not all operating systems, the Java 2D rendering pipeline supports hardware acceleration by the GPU. It depends on the Java implementation that you're using.
One of the new features for Oracle's Java SE 7 implementation (which is coming out at the end of the month) is this: XRender pipeline for Java 2D which means that it will have much better performing 2D graphics on Linux.
For Windows, in Java SE 6 update 10 there were some improvements to make Java 2D perform better by using Direct3D hardware acceleration (source).

For the Mac, you should try the system propeties and rendering hints described in this document, particularly the one that tells Java to use the native Quartz renderer rather than the Sun renderer.

..why could it be that on some computers the performance seems to be at least half of what it is on my laptop?
Video drivers. I was involved in a thread on usenet a long while ago, where there was a phenomenal difference in rendering speed on machines with similar spec. Ultimately it was concluded that some machines were using outdated video drivers, and that was the root cause of the difference.
If that turns out to be the case here, your best bet is probably to do a rendering test. Check the FPS, and if it is too low, advise the user to update the drivers.

Try popping it in a profiler and see what comes up. I'd do it on both windows and mac and compare where exactly you're getting the problem. JProfiler is my favorite, but YourKit is good as well. You can get a trial version for 30 days which should be plenty of time to figure this out.
It's probably graphics hardware related, hardware acceleration vs software, since there is such a difference between Mac and Windows noted on this thread.

MonoTouch performance vs. Objective-C/Java

I'm in the process of developing a multiplatform game engine and am using MonoTouch to cover Android and iPhone. I'm really interested in the performance aspect of using MonoTouch for iOS and Android development, does anyone know what, if any, performance impact MonoTouch will have over developing using Java or Objective-C for their relevant platforms? I ask this specificlaly from a game developers perspective, so things like drawing code and such really worry me. From what I've seen mono apps run fine, but say you made a game in the level of Angry Birds (art work, sound, physics processing), would that run well enough through mono that you wouldn't be put at a significant disadvantage over using the native language of the platform?

First, a clarification: on Android, the code is not executed by Java runtime, but by Dalvik (written from scratch by Google). Thus, the Java VM performance is of no relevance to this question.
With this in mind: most programs on Android don't execute native code, but run on Dalvik VM (which runs the translated Java bytecode). The Mono JIT has been benchmarked against it before and was consistently been found faster (check for example http://www.koushikdutta.com/2009/01/dalvik-vs-mono.html ).
On iOS, MonoTouch has to pre-compile the code into a native application before it can be installed on an Apple device (because of license restrictions, which are enforced by the Operating System). That said, both Objective C compiler and Mono's Ahead Of Time Compilation use the same LLVM backend for generating and optimizing the binary code, so the results you will get should be almost identical (with some memory overhead for Mono).
Please remember one important quote from Donald Knuth: "Premature optimization is the root of all evil." Write your code with performance in mind, but remember that maintainability is more important. Optimization should be done only when it's necessary (because usually the compiler will do a much better job than you can).

Is there an advantage to running JRuby if you don't know any Java?

I've heard great things about JRuby and I know you can run it without knowing any Java. My development skills are strong, Java is just not one of the tools I know. It's a massive tool with a myriad of accompanying tools such as Maven/Ant/JUnit etc.
Is it worth moving my current Rails applications to JRuby for performance reasons alone? Perhaps if I pick up some basic Java along side, there can be so added benefits that aren't obvious such as better debugging/performance optimization tools?
Would love some advice on this one.

I think you pretty much nailed it.
JRuby is just yet another Ruby execution engine, just like MRI, YARV, IronRuby, Rubinius, MacRuby, MagLev, SmallRuby, Ruby.NET, XRuby, RubyGoLightly, tinyrb, HotRuby, BlueRuby, Red Sun and all the others.
The main differences are:
portability: for example, YARV is only officially supported on x86 32 Bit Linux. It is not supported on OSX or Windows or 64 Bit Linux. Rubinius only works on Unix, not on Windows. JRuby OTOH runs everywhere: desktops, servers, phones, App Engine, you name it. It runs on the Oracle JDK, OpenJDK, IBM J9, Apple SoyLatte, RedHat IcedTea and Oracle JRockit JVMs (and probably a couple of others I forgot about) and also on the Dalvik VM. It runs on Windows, Linux, OSX, Solaris, several BSDs, other proprietary and open Unices, OpenVMS and several mainframe OSs, Android and Google App Engine. In fact, on Windows, JRuby passes more RubySpec tests than "Ruby" (meaning MRI or YARV) itself!
extensibility: Ruby programs running on JRuby can use any arbitrary Java library. Through JRuby-FFI, they can also use any arbitrary C library. And with the new C extension support in JRuby 1.6, they can even use a large subset of MRI and YARV C extensions, like Mongrel for example. (And note that "Java" or "C" library does not actually mean written in those languages, it only means with a Java or C API. They could be written in Scala or Clojure or C++ or Haskell.)
tooling: whenever someone writes a new tool for YARV or MRI (like e.g. memprof), it turns out that JRuby already had a tool 5 years ago which does the same thing, only better. The Java ecosystem has some of the best tools for "runtime behavior comprehension" (which is a term I just made up, by which I mean much more than just simple profiling, I mean tools for deeply understanding what exactly your program does at runtime, what its performance characteristics are, where the bottlenecks are, where the memory is going, and most importantly why all of that is happening) and visualization available on the market, and pretty much all of those work with JRuby, at least to some extent.
deployment: assuming that your target system already has a JVM installed, deploying a JRuby app (and I'm not just talking about Rails, I also mean desktop, mobile, other kinds of servers) is literally just copying one JAR (or WAR) and a double-click.
performance: JRuby has much higher startup overhead. In return you get much higher throughput. In practice, this means that deploying a Rails app to JRuby is a good idea, as is running your integration tests, but for developer unit tests and scripts, MRI, YARV or Rubinius are better choices. Note that many Rails developers simply develop and unit test on MRI and integration test and deploy on JRuby. There's no need to choose a single execution engine for everything.
concurrency: JRuby runs Ruby threads concurrently. This means two things: if your locking is correct, your program will run faster, and if your locking is incorrect, your program will break. (Unfortunately, neither MRI nor YARV nor Rubinius run threads concurrently, so there's still some broken multithreaded Ruby code out there that doesn't know it's broken, because obviously concurrency bugs can only show up if there's actual concurrency.)
platforms (this is somewhat related to portability): there are some amazing Java platforms out there, e.g. the Azul JCA with 768 GiBytes of RAM and 864 CPU cores specifically designed for memory-safe, pointer-safe, garbage-collected, object-oriented languages. Android. Google App Engine. All of those run JRuby.

I would modify what Peter said slightly. JRuby may use more memory compared to standard Ruby, but that's usually because you're doing the work in a single process what would take several processes with Ruby.
You should try the Rails.threadsafe! option with a single JRuby runtime (for example, the Trinidad gem with the --threadsafe option). We've heard several stories where it gives you great performance and low memory usage, while leveraging multiple CPU cores with a single process.

JRuby is one of the few implementations that uses native threads. So if you care to do some multithreading, go for it.
As far as hosting is concerned, you have to put your app in some sort of java container, which I personally find to be far less straightforward than using something like passenger (for Rack apps)
I use JRuby for an app as we communicate over JMS and it works fine, but if I wasn't using any Java I would certainly stick to CRuby. My biggest beef is that in testing, running tests takes forever with JRuby as you have to spin up a VM each time you run them. This makes it a lot harder to TDD as it's a significant hit on your testing time.

Jruby has advantages if you're on Windows. It supports 64 bits and you can use a lot of proprietary databases with standard JDBC drivers.

The latest releases are significantly faster than Ruby but also use significantly more memory. If that is your only reason for using JRuby, I wouldn't bother unless you have a specific performance need that it solves, simply because, while it is pretty popular, it is less standard for hosting and less people use it as compared to standard Ruby. That being said, there are many other reasons to use JRuby such as a need for interoperability with existing Java code and the need to deploy in environments where Java has been "blessed" by the operations department and Ruby has not.

Is it possible to code a device driver in Java?

Introduction
I heard something about writing device drivers in Java (heard as in "with my ears", not from the internet) and was wondering... I always thought device drivers operated on an operating system level and thus must be written in the same language as the OS (thus mostly C I suppose)
Questions
Am I generally wrong with this
assumption? (it seems so)
How can a driver in an "alien"
language be used in the OS?
What are the requirements (from a
programming language point of view)
for a device driver anyway?
Thanks for reading

There are a couple of ways this can be done.
First, code running at "OS level" does not need to be written in the same language as the OS. It merely has to be able to be linked together with OS code. Virtually all languages can interoperate with C, which is really all that's needed.
So language-wise, there is technically no problem. Java functions can call C functions, and C functions can call Java functions. And if the OS isn't written in C (let's say, for the sake of argument that it's written in C++), then the OS C++ code can call into some intermediate C code, which forwards to your Java, and vice versa. C is pretty much a lingua franca of programming.
Once a program has been compiled (to native code), its source language is no longer relevant. Assembler looks much the same regardless of which language the source code was written in before compilation. As long as you use the same calling convention as the OS, it's no problem.
A bigger problem is runtime support. Not a lot of software services are available in the OS. There usually is no Java virtual machine, for example. (There is no reason why there technically couldn't be, but usually, but usually, it's safe to assume that it's not present).
Unfortunately, in its "default" representation, as Java bytecode, a Java program requires a lot of infrastructure. It needs the Java VM to interpret and JIT the bytecode, and it needs the class library and so on.
But there are two ways around this:
Support Java in the kernel. This would be an unusual step, but it could be done.
Or compile your Java source code to a native format. A Java program doesn't have to be compiled to Java bytecode. You could compile it to x86 assembler. The same goes for whatever class libraries you use. Those too could be compiled all the way to assembler. Of course, parts of the Java class library requires certain OS features that won't be available, but then use of those classes could be avoided.
So yes, it can be done. But it's not straightforward, and it's unclear what you'd gain.
Of course another problem may be that Java won't let you access arbitrary memory locations, which would make a lot of hardware communication pretty tricky. But that could be worked around too, perhaps by calling into very simple C functions which simply return the relevant memory areas as arrays for Java to work on.

Writing Solaris Device Drivers in Java covers a A RAM disk device written in Java.
Another one for Linux. Goes more in depth on why you might want a DD in Java as well (since some people were wondering by the looks of the other posts and comments)

A device driver could be a lot of things
I actually write device drivers in java for a living: drivers for industrial devices, such as scales or weighing devices, packaging machines, barcode scanners, weighing bridges, bag and box printers, ... Java is a really good choice here.
Industrial devices are very different from your home/office devices (e.g. scanners, printers). Especially in manufacturing (e.g. food), companies opt more and more for a centralized server which runs an MES application (e.g. developed in Java) The MES server needs to interface with the devices of the production line, but also contains business logic. Java is a language that can do both.
Where your home/office devices are often built-in to your computer or connected with an USB cable, these industrial devices usually use Ethernet or RS232 connectors. So, in essence, pretty much every language could do the job.
There is not much standardisation in this area yet. Most vendors prefer to create their own protocol for their devices. After all they are hardware builders, not software geniuses. The result is that there is a high diversity of protocols. Some vendors prefer simple plain-text protocols, but others prefer complex binary protocols with CRC codes, framing, ... Sometimes they like to stack multiple protocols (e.g. a vendor specific handshaking algorithm on top of an OPC layer). A strong OOP language has a lot of advantages here.
E.g. I've seen java print at a continuous speed of 100ms/cycle. This includes generating a unique label, sending it to the printer, receiving a confirmation, printing it on paper and applying it to the product using air pressure.
In summary, the power of java:
It is useful for both business logic as complex interfacing.
It is just as reliable in communication with sockets as C.
Some drivers can benifit from Java's OOP power.
Java is fast enough.

It's not impossible, but possibly hard and possibly makes not much sense.
Possible is it, because Java is a normal programming language, as long as you have some way to access the data, it's no problem. Normally in a modern OS the kernel has a layer to allow raw access to hardware in some way. Also already exist drivers in userspace, at least the userspace-part should be no problem to implement in Java.
It makes possibly not too much sense, because the kernel has to start a JVM to execute the driver. Also JVM-implementations normally eat up much memory.
You could also use Java-code compiled to be executed natively on the platform (not with the help of a JVM). This is usually not that efficient, but it could be suitable for a device-driver.
The question is, does it make sense to implement the driver in Java? Or stated in another way: What is the benefit you hope for, if you use Java for implementing the driver instead of another alternative? If you can answer this question, you should find a way to make it possible.
At the end the hint to JNode, a project that tries to implement a complete OS purely based on Java.

You have a too narrow view of device drivers.
I have written such device drivers on top of MOST in an automotive application. A more widespread use might be drivers for USB devices if Java ever gets a decent USB library.
In these cases there is a generic low-level protocol which is handled in native code, and the Java driver handles the device specifics (data formats, state machines, ...).

For the motivation, please remember that there is plenty of fast languages which are better than C for programming; they might not be as fast as C, but they are safe languages: if you make a mistake you don't get undefined behavior. And "undefined behavior" includes executing arbitrary code supplied by some attacker which formats your HD.
Many functional languages are usually compiled to native code.
Device drivers contain the most bugs in an OS kernel - I know that for Linux (Linus Torvalds and others keep saying so) and I heard that for Windows. While for a disk or Ethernet driver you need top-notch performance, and while in Linux drivers today are the bottleneck for 10G Ethernet or SSD disks, most drivers don't need that much speed - all computers wait at the same speed.
That's why there are various projects to allow writing drivers which run outside of the kernel, even if that causes a slowdown; when you can do that, you can use whatever language you want; you will just then need Java bindings for the hardware control library you use - if you were writing the driver in C, you would still have a library with C bindings.
For drivers in kernel mode proper, there are two problems that I've not yet seen mentioned:
Garbage Collection, and that's a tough requirement. You need to write an in-kernel Garbage Collector; some GC algorithms rely on Virtual Memory, and you cannot use them. Moreover, you probably need to scan the whole OS memory to find roots for the GC. Finally, I would only trust an algorithm guaranteeing (soft) real-time GC, which would make the overhead even bigger.
Reading the paper which was mentioned about Java Device Drivers on top of Linux, they just give up, and require programmers to manually free memory. They try to argue that this will not compromise safety, but I don't think their argument is convincing - it's not even clear whether they understand that Garbage Collection is needed for a safe language.
Reflection and class loading. A full Java implementation, even when running native code, needs to be able to load new code. This is a library you can avoid, but if you have an interpreter or JIT compiler in kernel (and there's no real reason that makes it technically impossible).
Performance. The paper about a JVM on Linux is very bad, and their performance numbers are not convincing - indeed, they test a USB 1.1 network driver, and then show that performance is not so bad! However, given enough effort something better can surely be done.
Two last things:
I'd like to mention Singularity, which is a complete OS written in a C# variant, with just a Hardware Abstraction Layer in a native language.
About picoJava, it's a bad idea to use it unless your system is a really memory constrained one, like a smart card. Cliff Click already explained why: it gives better performance to write a good JIT, and nowadays even smartphones can support that.

Have you perhaps heard a reference to the JDDK?
Writing a device driver 100% in Java is not possible without native code to provide the interaction between (1) the OS-specific driver entry points and conventions, and (2) the JVM instance. The JVM instance could be started "in-process" (and "in-process" may have different meanings depending on the OS and on whether the driver is a kernel-mode or user-mode driver), or as a separate user-land process with which a thin, native driver adaptation layer can communicate and onto which the said driver adaptation layer can offload actual user-land work.

It is possible to compile java code to hardware native (i.e. not JVM bytecode) instructions. See for instance GCJ. With this in hand, you're a lot closer to being able to compile device drivers than you were before.
I don't know how practical it is, though.

Possible?
Yes but only in special circumstances. Because you can write an operating system in Java and C#, and then, should be able to write device drivers for it. The memory hit to these drivers and operating systems would be substantial.
Probable?
Not likely. Atleast not in the world of Windows or MacOS or even Linux... At least not anytime soon. Because languages like C# and Java depend on the CLR and JVM. The way these languages work means that they cannot effectively be loaded into ring0.
Also, the performance hit would be rather large if managed languages were employed in device drivers.

Device drivers have to be written in a language which can execute in the kernel, either compiled into it, or loaded as a module at runtime. This usually precludes writing device drivers in Java, but I suppose you theoretically could implement a JVM inside a device driver and let it execute Java code. Not that any sane person would want to do that.
On Linux there are several user-land (i.e. non-kernel) implementations of filesystems which uses a common abstraction layer called (fuse) which allows user-land programs to implement things which are typically done in the kernel.

The Windows Driver Foundation (WDF) is a Microsoft API that does allow both User and Kernel mode device drivers to be written. This is being done today, and it is now compatible with w2k and later (used to not have w2k as a supported target). There is no reason that JNI calls can't be made to do some work in the JRE . . . ( assuming that JNI is still the way to call Java from C/C++ . . . my knowledge is dated in that arena). This could be an interesting way to have high level algorithms directly munch on data from a USB pipe for something to that effect . . . cool stuff!

PCIe user space device drivers can be written in Pure Java. See JVerbs for details about memory-based direct hardware access, in the context of OFED. This is a technique that can be used to create very high performance systems.
You can examine the PCI bus to determine the memory regions for a given device, what ports it has, etc. The memory regions can be mapped into the JVM's process.
Of course, you're responsible for implementing everything yourself.
I didn't say easy. I said possible. ;)
See also Device Drivers in User Space, which discusses using the UIO framework to build a user space driver.

First of all, note that I'm not an expert on device drivers (though I wrote a few myself back in the day), much less an expert on Java.
Let's leave the fact that writing device drivers in a high-level language is not a good idea (for performance and possibly many other reasons) aside for a moment, and answer your question.
You can write device drivers in almost any language, at least in theory.
However, most device drivers need to do plenty of low-level stuff like handling interrupts and communicating with the OS using the OS APIs and system calls, which I believe you can't do in Java.
But, if your device communicates using, say, a serial port or USB, and if the OS doesn't necessarily need to be aware of the device (only your application will access the device*), then you can write the driver in any language that provides the necessary means to access the device.
So for example you probably can't write a SCSI card driver in Java, but you can write a driver for a proprietary control device, USB lava lamp, license dongle, etc.
* The obvious question here is, of course, does that count as a driver?