Bringing Java To The World Of Microcontrollers

C is a beautiful language perfectly suited for development on low-power devices such as the 8-bit microcontrollers. With newer, more powerful ARM microcontrollers making their way onto the market and workbenches around the world, it was only fitting that Oracle got in on the action. They released a version of Java targeted at these newer, more powerful microcontrollers called Java ME embedded.

The new embedded version of Java has everything you would expect from a microcontroller development platform – access to GPIO pins, including SD cards and I2C devices. The new Java machine is designed for full headless operation and is capable of running on devices with as little as 130 kB of RAM and 350 kB of ROM.

As for the utility of programming a microcontroller in Java, it’s still the second most popular language, after spending the better part of a decade as the number one language programmers choose to use. The requirements of the new embedded version of Java are far too large to fit onto even the best 8-bit microcontrollers, but with a new crop of more powerful ARM devices, we’ll expect to see more and more ARM/Java projects making their way into the Hackaday tip line in the coming months.

Tip ‘o the hat to [roger] for sending this one in.

104 thoughts on “Bringing Java To The World Of Microcontrollers

    1. I agree, learn how a micro works. But then, seriously, who has the time to write in assembly, or even for that matter if you don’t have a career in it, become completely proficient in c? Personally, I think Java rocks, and I do know assembly and c. It is so much faster and easier to whip something out in, especially for a quick one-off project that you want to dedicate 30 minutes of code to, not 30 hours.

    2. Why not C? Because it is not an object oriented language.
      Why not C++ Because it’s c with objects tacked on.
      Why not C# It is for the most part a Microsoft centric language.
      Everyone that hates on C pretty much are people that have used badly written java programs, never used it, or frankly wrote bad java programs.
      That is the “problem” with Java. You can write a total piece of crap that would have blown chunks in c or c++ but will work in java. Honestly if you want to write a stable program Java is the way to go.
      And Java is what is used to write most Android apps and has been used in feature phones for years. Make perfect sense in this space as well In fact it has been here for a while

      1. Well, there is really a LOT of good C++ (really) big projects out there. This is not about OOP, but about performance. And about IP. Java is not even near as free/open as GNU C/C++ toolchains. And it’s 10 times slower and much more memory consuming.

      2. And what if my app is not being a Phone? You want Java in this if your device or device family is going to have diferent chip familys, so you write an app and it will run on the newer or other version. Its ok for those situations you realy need the option to let old or cross platform apps work on diferent devices of the same type but Hey, if youre gonna think about that then you can put Android on it right? else its to small and I cant think about a reason to do Java then, just do C or something and maybe we need a new version of Cpp, a combination of C# and Cpp. less Microsoft and more opensource. DOnt be a MS hater, Commercial companies use MS daily, only most of the Hax0r ppl bash on ms, for what? COmputer do what ppl aks them to do. So Ask a IC precisely what to do, I dont want a Crashing IC because my Java sucks and now prefenting me to destroy my flash, when you learn C, or Cpp you learn the hardway that you need to be carefull.

        :P So yeah, I write in java sometimes and I like it, but I dont like Android, dont feel free to program everything I want. Import this library, enable this security option… Maybe I just dont like the IDE’s for Java dev. Java is not my lover, Im in love with C (And her children). :P

    3. > as little as 130 kB of RAM and 350 kB of ROM.

      Holy **** crap. I do occasional programing in java for android, used to write a few apps in j2me. Well, the whole java idea sucks when in comes to such resource constrained systems. It just sucks.
      You don’t have enough resources to unleash the full beauty of the language, and for blinking a few leds and sending a few bytes over i2c… It’s an overkill. Even asm is just about the same effort.
      To sum up – C is the only sane choice and will remain it. If you want interactive prototyping in something high-level – eLua is my platform of choice (and don’t mention that ugly pile of crap called arduino)

    4. @Julián
      >good C++ (really) big projects out there.

      And there are lots of good Java projects out there.. not seeing your point here.

      >Java is not even near as free/open as
      >GNU C/C++ toolchains.

      There are a few opensource JVMs like .. The reference implementation of the JVM and class library are opensource as OpenJDK and there are alternatives like Harmony.

      >And it’s 10 times slower and
      >much more memory consuming.

      Got any evidence to actually back that up?

      1. 1. The point there is against the argument that “Java is the only solution for big projects” That’s simply not true. I’m not saying Java is not good to scale, just C++ is also good.

        2. Free/Open. Maybe, but as I said in another comment, since the attempt from Oracle against Google in that horrible patent war, I will not trust them any more.

        3. Aside from using Java apps and waiting for their bad response times, here are some links with statistcal data (I like the first one because it’s from Google, interested part since Android Apps are Java based):

        Perhaps it’s not 10 times, but the difference is key point is that C++ seems to be always faster. And that’s very important in small MCUs.

    5. >Why java? why not C? why not Cpp, Why not C#?

      Funny, me being a naive noob EE I dont see a difference between those :) Sure, some buildin functions will be different and compiler will complain about data types or some minor syntax, but all in all its all the same.

  1. Java executes about an order of magnitude slower than C/C++ or any other compiled solution. I don’t believe in the argument of making things difficult per se. So I don’t support assembly programming as a good practice today, for a lot of reasons. But these days, big (hardware) efforts are made to improve energy efficiency and CPU performance, so why waste precious machine cycles with a Virtual Machine? And don’t say that Java is now running better than before, because although that’s true, the native solutions will always execute faster. Anoter important thing: I don’t like Java’s new owner attitude against open source systems. I think the open source community should really move away from these kind of propietary technologies.

    1. >Java executes about an order of
      >magnitude slower than C/C++ or any
      >other compiled solution.

      – Do you understand what JIT is?
      – Lots of ARM cores have jazelle that executes Java byte code like it would ARM or Thumb.
      – Google and others have tools that take Java and translate it into Javascript, ObjectiveC etc.. there are bytecode level translation tools out there too.

      >So I don’t support assembly programming
      >as a good practice today, for a lot of

      Programming in assembly on machines made for C(tm)
      like ARM isn’t sensible unless you really need to do it. Understanding assembly when you come to stepping instructions in GDB during a frustrating debugging session is definitely a plus.

      >But these days, big (hardware) efforts
      >are made to improve energy efficiency
      >and CPU performance, so why waste
      >precious machine cycles with a Virtual Machine?

      A decent VM will detect hotspots in the code and generate “native code”. Dynamic optimization might actually result in more efficient code than statically optimized code..

      >native solutions will always execute faster.

      Except where dynamic optimization can find hotspots that relate to your particular workload.

      >Java’s new owner attitude against
      >open source systems.

      Oracle are dicks.. but Java is open now whether they like it or not.

      1. 1. Well, I understand perfectly JIT.

        2. I agree with you that knowing how to program in assembly is a plus. Never said another thing. In fact, I was only supporting the usage of high level languages for embedded devices, nothing more. I like assembler and I used it a lot, for a lot of architectures.

        3. I also worked for 2 years desining instruction set for an FPGA based MCU and I strongly disagree with the Jazelle approach. But I’m not the only one, since Hennessy & Patterson said exactly that: don’t design CPUs with big instruction sets to help compilation of spedific languages. And that’s a rule based on the biggest statistical study on CPUs in history. I think you know that book.

        4. JIT and other optimization techniques are not enough to make VM based languages run as faster as native solutions. As far as I know, the biggest claim in getting close is from Google, and I think they still admit to be running about 5 times slower than native code. I don’t like iPhones, but their native code solution Objetive-C (although it’s probably 3 times slower in methods calls than native non-virtual C++ methods) really works better than Java based Android apps (yes, even with Dalvik). If you ever tested it you know that. And I own an Android because I don’t like propietary technologies (probably will migrate to Firefox OS when available) and I don’t also like patent aggressive companies.

        5. Since the attempt from Oracle to fight against Google’s usage of Java, I will not trust them never never never. Some mistakes are one-time mistakes. Open source community should learn from that trial a lot. So yes: Normally I would be happy with a new language coming to the ARM world. But not this time, with these guys.

        6. Good compiler heuristic over RISC machines still works better than those “dynamic optimitzations” you mentinoned. It’s a fact. I like VMs when used properly, here I see they will only make us to waste CPU cycles.

    2. I was recently involved in writing a geometric library for tessellating large point clouds. The host app was written in Java, and they didn’t want to have to build a C++ CGAL library for each platform.

      The result was around 1.5x FASTER than the C++ CGAL library.

      Why? Java with JIT isn’t as slow as you think it is – look at some benchmarks. On top of that it’s got very good profiling tools which allow you to see performance issues and fix them properly.

      1. It’s not what I think, it’s what MOST benchmarks actually shows. Sorry, but I did not see your benchrmark on a published paper about performance. I posted 2 links above, one from Google and one from Stanford. And there are a LOT of benchmarks showing that C++ is faster, plese google them. Just a few give advantage to Java, showing that it’s more a desire than a real thing. Regarding profiling, I think there are good tools for both worlds. Regarding JIT, it’s not enough to make Java faster than C++, because the VM is still there, and just relatively small portions of code are compiled to native. And they compile to native because native is faster than interpreted. But please don’t misunderstand me: I don’t hate Java, and I like its syntax more than C/C++’s syntax. It’s just that, at least for me, the evidence is against the usage Java in microcontrollers. Here are some probably Java advantages that I will agree with:

        1. Reaching the market in less time.
        2. Accessing to a truly standarized (and really bit) API.
        3. Reducing maintenance costs.
        4. Avoiding weird strange syntax that have a large learning curve.
        5. Portability (except if you want to downscale something to 8 bit MCUs).

        But please don’t speak me about performance (nor spatial nor temporal), because saying that C++ is slower than Java is simply not true.

    3. @Julián

      The two links you gave aren’t really that great, one seems to only deal with loops and doesn’t have enough scope or runtime to actually put Java’s JIT into action. The other is from 2003 and from a quick glance of the page the test hardware was a 233MHz pentium 2.. I do like how you pasted two wishy washy links but shot down someone else’s real world example of Java being faster than C++.
      Also note that I never said that “Java is faster than C++”.. I am just calling you out on your claims that Java is slow.

      >If you ever tested it you know that.
      >And I own an Android because I don’t
      >like propietary technologies

      I write Android code on a daily basis and I have written games for Android in Java. If you have ever profiled an Android app you would have noticed how much is actually “native code”. It’s only really less performance critical parts that aren’t calls into native code. i.e. Layout stuff is all “java” but as soon as you start doing blits to a Canvas it starts turning into calls into native code, and if you’re careful you can actually make it so that the data you’re blitting doesn’t enter the VM at all.

      1. What ARM are you using that is faster than a 233 mhz pentium 2? And why is Android calling native? Why didn’t they write the whole OS in Java? Because it’s sloooooow! I’m writing games for a living and for android we’re writing in C++ with a handful of java glue code. Even like this the android port of the game is slower than the iphone port, even if run on a faster device :)

        Sent from my iPhone4s

      2. >What ARM are you using that is faster than a 233 >mhz pentium 2?

        The 700Mhz or whatever ARM on my beaglebone is faster than a P2 .. the 1.2GHz ARM in my phone is faster than a P2. The memory, GPU etc attached to these things is also better than what a P2 machine could have.

        >And why is Android calling native?

        For stuff that isn’t suited to being done inside dalvik..
        A lot of Android is native. Use the profiling tool and look what happens when you draw a Bitmap to a Canvas .. What is actually implemented as native code depends on the version of Android ofcourse. SQLite was native, but they rewrote it in Java for some reason.

        >Why didn’t they write the whole OS in Java?

        No. The kernel is Linux, a lot of the userland is written in C and a lot of the Java (well, really Dalvik but we’ll forget that for now) used for the UI layer of the stack calls into native code where it is needed. Java does of course have JNI.

        >Because it’s sloooooow!

        You’re doing it wrong then. If you’re using OpenGL very little of the real work is done inside the VM.

        >I’m writing games for a living and for
        >android we’re writing in C++ with a handful of >java glue code.

        I have some code that does the same thing probably , native code doing the work and Java via JNI rendering it to the screen. The trick is to use native buffers so that when the Java code calls back into native code to do the blitting the buffer never has to enter the VM.. ofcourse you should know this already. The fact that you seem to think Android is implemented completely in Java makes me suspect you might be telling porky pies though.

      3. @filisoft

        >Why didn’t they write the whole OS in Java?

        I probably misunderstood what you meant here.
        Why wouldn’t you write an OS in Java.. because Java isn’t really a suitable language to do that. You are a fool if you pick one language you like and only ever use that.. pick the best tool for the job. A lot of the core of Android is written in C, and a lot of the higher levels are written in Java. Applications are mostly written in Java and there is a rich standard library that abstracts away the hardware/implementation differences (read: makes writing apps less of a nightmare). Your applications can of course make use of native code where needed via JNI and parts of the upper layers of Android use native code when needed. You have to also take into account that Dalvik is slightly different to HotSpot, in many ways “not as good” and it’s JIT isn’t all that mature and the Java compiler leans on the JIT doing a lot of the optimization work. There are some things you can do that Dalvik will make a total mess of but are just fine in the standard JVM.. there is a page on the Android developer site that details these things btw.

      4. I’m not talking about using Java in a 700 MHz processor with 128 MB DDR. There you might get away with it. I’m talking about a 100 MHz, 512 KB SRAM uC. I don’t see the reason to use Java on that.
        I know Android is not written in Java. I was just asking, if Java is so good for everything, why didn’t they just write everything in Java? Why did they have to optimize stuff by writing native code when they could have used Java + JIT? Because Java is not suited for everything. It’s not the solution to all your problems. If you have memory/cycles to waste and just need something done, go ahead. But if you’re in a constrained environment where you optimize every alloc, Java is not good.
        I’m not against Java. If I need a tool that’s used from time to time and performance is not an issue, I use Java (especially because it’s multiplatform). But if I need something to run fast, I use C++. I did a test recently. I wrote a tool that compiled some models in both Java and C++. I used roughly the same code. Java was about 8-10 times slower than the C++ version. Then I’ve optimized it, unrolled loops, rewrote matrix code and managed to be about 5 times slower… Timings were done on Java 1.7, quad core processor. Oddly, one of the best improvements in the code was replacing

        for (int i=0; i<m; i++)
        for (int j=0; j<n; j++)
        { do stuff }


        for (int j=0; j<n; j++)
        for (int i=0; i<m; i++)
        { do stuff }

        In C++ this made no difference, but in Java it saved a lot. Also moving variable declarations outside of the loops made a difference in Java but not in C++.

      5. @filisoft

        >I’m talking about a 100 MHz, 512 KB SRAM uC.
        >I don’t see the reason to use Java on that.

        Why not? There are JVMs that run in 64KB of RAM.
        I could say the same of C++. Why use C++ when you can use C? Why use big standard libraries when you could write your own from scratch for the target and save 10 bytes of RAM you weren’t going to use anyways.
        You asked where my ARM that is faster than a P2 is.. because it happens to actually be faster than a P2 it isn’t valid by your weird logic? :\ The fact that some ARM microcontrollers could execute Java bytecode invalidates any of your “java isn’t suitable for micro controllers” points.

        >I know Android is not written in Java.
        >I was just asking, if Java is so good for >everything,

        Who said Java is good for everything? I haven’t said Java is good for everything, in fact the only person trying to say that one language is good for everything is you.

        >why didn’t they just write everything in Java?

        Dalvik is not HotSpot by a long way.. if it was Java(TM) Oracle wouldn’t have sued Google.

        >Why did they have to optimize stuff by
        >writing native code when they could have
        >used Java + JIT?

        Again, Android is Dalvik and not Java. Google have optimized stuff that needs to be optimized. As I said earlier SQLite has actually moved from a C/C++ implementation to Java. Older versions of Dalvik didn’t have JIT enabled. Native code is important in some places because you are talking to other bits of native code and JNI isn’t free..

        >Because Java is not suited for everything.

        Who said it was?

        >It’s not the solution to all your problems.

        Again, who said it was? You are the one making out it has no use at all.

        >If you have memory/cycles to waste and just need >something done, go ahead.

        Blah blah blah. Most C/C++ compilers generate awful machine code, do you get all butt hurt about that too?

        >But if you’re in a constrained environment
        >where you optimize every alloc, Java is
        >not good.

        How is that any different than using malloc? You are aware of tools like VisualVM right?

        >I’m not against Java.


        >I use Java (especially because it’s >multiplatform).

        So you’re singing the praises of C++ and saying that people that use Java are sloppy coders and you can’t write portable code?

        >Java was about 8-10 times slower than
        >the C++ version.

        All hot air unless you can actually present your tests etc. What JVM settings did you use etc etc.

        >Then I’ve optimized it,

        Did you actually use the tools available to profile the code and see what the JVM is doing?

        >Timings were done on Java 1.7, quad core

        You might just not be great at writing multi-threaded code.

        >Oddly, one of the best improvements in
        >the code was replacing

        Use the tools available to see what it was doing.

      6. My “weird” logic is this: don’t use Java on a small uC, you will kill it. On larger ones, you could…
        I don’t need multithreading, I just need a fast tool written in 2 hours that can compile some models. So I didn’t profile it with anything more than measuring the run-time of the app. Why should I profile and lose time optimizing something when in C++ it runs 10 times faster? So in the end it was faster to write C++ code, compile it for Win/OSX/Unix and distribute all versions than make a Java version (that still needed batches for the three platforms because graphic artists are completely against command line)

    4. @filisoft

      >don’t use Java on a small uC, you will kill it.

      Except that some small microcontrollers have the ability to execute Java byte code and there is Java in some form running on tiny machines?.. obviously reality is disagreeing with you here. Although it isn’t ideal Java the language can be compiled down to “native code”..

      >On larger ones, you could…

      On larger machines you can run better VMs (with fancy JITs, code insertion etc) and have access to a wider standard library. It’s pretty clear from the features/footprint of the product offered by oracle that isn’t for the super low end . One of the issues Oracle brought up in the case against Google is that Google are running the J2SE standard library on a mobile device,.. obviously you and Oracle haven’t caught on to how much faster tiny systems are now.

      >I don’t need multithreading,

      So why bring up the number of cores in your test machine if it didn’t actually matter? “I ran this test on my super computer and it was really slow, of course I only ran code on the microcontroller on the keyboard”.

      >So I didn’t profile it

      So, your benchmarks mean nothing.

      >I profile and lose time optimizing
      >something when in C++ it runs 10 times faster?

      If you want your benchmarks to be used as proof that Java is slow you have to make sure that it wasn’t an issue with your code.

      >So in the end it was faster to write C++ code, >compile it for Win/OSX/Unix

      So you can write portable code now?

      >that still needed batches

      3 “batch” files + one jar vs 3 executables.. my god, the horror! Look into avian, it is designed to take the java byte code as a payload in the same executable as the VM..

  2. Please, NO! … Dear God in heaven.

    Better have a good bootloader since Java needs updating often…. although not quite as often as that dawg Adobe Flash.

    Just stick with C.

    1. Java platforms on desktops are updated often to provide new features to the plugins and to close security holes which are exploited by malicious applications mostly web based.

      How does this affect an embeded solution?

  3. Maybe it is too long ago for people to remember, but Java was originally designed for embedded controllers, but quickly got picked up by web backend developers looking for something better than C or Perl and CGI-BIN, myself included.

    Java is actually a good language for embedded usage. Anyone remembers the Java Card API? (running Java on a smart card).

    1. I do remember that. But there are good reasons why Java (or any other interpreted/byte code language) is not the best solution for embedded. MCUs really work better with compiled solutions. And C/C++ is not so different from Java. If you have a good HAL / API, you can really port things between even 8 and 32 bits without big efforts.

      1. True, but I don’t believe it is not a clear cut choice. There is a an area in which multi-platform C APIs, DSLs, scripting languages and byte code languages like Java overlap. Like most things in hardware and software, there are rarely simple answers to complex questions. “C is superior language for embedded” is a strong statement. I think it is nice to have multiple tools to chose from, even if I admit I have used “Arduino C” for all my (few) projects so far.

    2. This was my first thought as well. I remember. When Sun was a fountain of innovation.

      Although my second thought was to laugh at this, and the third was to think negative thoughts because its Oracle, in the end I came to saying, “meh, it’s ok. More choice for those who want to code embedded apps in Java”. Won’t be me though.

  4. “130 kB of RAM and 350 kB of ROM.”

    That’s the requirement for a simple led blink? That’s a lot of wasted ressources.
    What’s the point of spending ressource and money on something that will be less powerful?
    I’m not an C/C++ expert (being in Software QA) but i manage to do what i want with my arduino : bluetooth, FFT for spectrum analyzer, driving a 16*32 RGB led matrix with no difficulty and it’s still under 35KB of rom… and it’s runs fucking fast.

    You really think that having to make a full object oriented program to run micro will be a good it… it’ll love to see comparison between arduino sketch and the same thing with that JavaME…
    result should be : 2 times less performance and 2 times the cost for a powerfull enough board (with more space taken and more power hungry… so efficent…)

    1. Well, the problem is not OOP. In fact Arduino’s API uses some OOP (not nicely perhaps, but still there), like the Serial preinstantiated object, among others. The problem with Java is it’s VM and it’s memory and CPY cycle requirements. Byte codes are not opcodes!

  5. “C is a beautiful language perfectly suited for development on low-power devices such as the 8-bit microcontrollers”

    Hardly! The only reason we use C is all the other languages are worse. Please someone smarter than me come up with an easier more readable embedded language that doesn’t take a huge memory footprint and still allows low level / bitwise hardware control (I don’t ask for much, do I :)

  6. @aweijnitz: I agree with the overlap, and I believe that for rapid prototyping / learning some interactive languages make sense. But Java is not an interactive language, nor a compiled one. I’m not also saying that C/C++ is superior. I just say that VM based languages are really worst regarding both temporal and spatial efficiency. And Java is not that much better than C++ when this last one is well used regarding the scaling of the project. Regarding the Arduino API, that’s my point! I don’t like that API a lot, but it’s practical, it has been ported to different 8, 16 (MSP430) and 32 bits MCUs and it just works, without a big overhead. And most programmers don’t need to deal with pointers, etc., although they will be using the GNU GCC when programing with Arduino. So I think that’s a far better solution than any Java or any other VM based lang.

  7. Daaaamn! Those memory requirements make even the .NET Micro Framework look svelte. Not to mention Microsoft beat them to market by a few years, making this one of the rare cases where Microsoft can’t be accused of copying someone else’s product.

    The real questions – how does it compare in terms of execution speed? Class library support? Licensing restrictions?

    1. Eh? MS beat them by a few years? In what aspect? If I remember correctly, I was already programming in Java before .Net was ever heard of. And if you are talking about the embedded space, I’m sure I’ve seen one of those sunspots being demoed by Sun sales people before .Net micro has been conceived.

      1. Yes, it should be obvious we’re talking about the embedded space.

        As for the Sun SPOT, I’d say it doesn’t count in this comparison, because:

        1) It was primarily a specific hardware device, not just a software framework intended to be ported to your own device. While porting the software was possible, I can’t find any reference to anyone actually doing so.

        2) It was an obscure thing no one used. I had to look it up myself to see what you were talking about. Not a single entry on HAD. Many of the websites regarding it are now defunct. If you want to include the obscure, I’m pretty sure DotNetAnywhere had .NET code running on embedded controllers before either Microsoft’s Micro Framework or the Sun SPOT.

  8. Jesus people, real programmers use the best tool that is most appropriate for the job (even if that means “butterflies” to flip the bits).

    I can’t understand the Java hate here. More tools means more options, and that is a good thing. Don’t bash the technology, bash the programmer who used it inappropriately.

    1. I don’t get the Java hate either.

      With lots of these Micros (especially the ones with that much RAM) now having Ethernet, it makes a huge amount of sense (to me).

      Handling the multiple web connections sensibly in C just isn’t going to be very sensible.

  9. Dear lord, why, why. Why make mcu programming accessible to the many millions of people who know Java. Why would we waste all those precious CPU cycles being productive *right now*, when I could instead be spending my time setting up toolchains and learning the finer points of interrupt handling? This will be the death of ARM development, much as Arduino’s were the death of AVR.


    For the love of all that’s holy, people. Give it up. This is an entry point, much as OMFGBBQ those horrible Arduinos are an entry point. It will not be as efficient as C, and the JVM on it will obviously not be powerful enough to run the VM languages of this century, but it DOES NOT MATTER. Go back to your handcrafted 8051 assembly and give it a rest.

  10. Yeah, great! I programmed a lot of time games on mobile phones in Java. I had to deal with performance issues, very little available memory and so on. Do you know what I had to do to make games behave like games and not slideshows? Program in Java like in C. Make one huge class with only static methods, allocate one big chunk of memory and use an in-house memory allocator and get on with it.
    In C you can have something like

    Point points[100];

    in Java you have to do

    Point points[];
    points = new Point[100];
    for (int i=0; i<100; i++)
    points[i] = new Point();

    Each and every one of those 101 allocations eat up precious memory like hell…
    If we say that each Point contains 2 floats (8 bytes), in C you would use 800 bytes. In Java each Point contains 2 floats(8 bytes) and an Object (8 bytes) so 16 bytes in total. This brings us to about 1620 bytes (don’t forget the array object that needs a pointer and a length).
    So the Java code takes more than double memory, lots more cycles and more code to do a very simple task.
    In my opinion this is useful only for lazy/incompetent programmers. Everybody else will still use C/C++/ASM…

    1. >contains 2 floats (8 bytes),

      Use an array of the primitive float type then ..

      float[][] points = new float[100][100];

      and there are unsafe arrays and buffers etc if you *really* want that.

      1. Great, so instead of

        Point points[100];
        points[5].x = 1;

        I have to do

        float points_x[];
        float points_y[];

        points_x = new float[100];
        points_y = new float[100];

        points_x[5] = 1;

        Great! More work for me! Then instead of


        I need

        DrawLines(points_x, points_y);

        Great! More params to be sent in the stack.
        Then the lovely GC checking from time to time if points_x and points_y are still needed or it can delete them.

      2. @filisoft

        You are comparing structs to objects.. they are not the same thing. Yes, C structs are nice but structs are not objects. If you are worried about allocations you shouldn’t go over wrapping primitive types into classes..

        >float points_x[];
        >float points_y[];

        You don’t understand multidimensional arrays? Maybe that’s why you didn’t notice my typo. Either way.. by wrapping two floats in struct or a class you have already written more code than that..

        >Great! More work for me! Then instead of

        You are making work for yourself.. and if you use a modern Java IDE like eclipse you could have that typed in about 10 keystrokes either way.

        >Great! More params to be sent in the stack.

        You’re complaining a little too much now.

        >Then the lovely GC checking from time to time

        Use the tools available to make sure you aren’t forcing GC to happen. The GC is configurable on most implementations btw.

      3. Does Java have structs now? Why haven’t I been noticed?
        Ok, that was a very simple example. Look: I need to keep track of a collection of points that have coords (float), color (integer), flags (integer), etc (???). How am I going to use a float multidimensional array for that? I need a simple way to keep track of all this stuff in a single place so that I can do ProcessPoint(points[10]) instead of ProcessPoint(points_x[10], points_y[10], points_flags[10], points_color[10],…); Even a fan-boy like you that can’t understand a simple example must realize that it’s much more work this way.
        I think that you don’t understand multidimensional arrays, hence your typo. I don’t care about your typo, I’m not your teacher.
        By wrapping two floats in a struct I’m using something free from C that brings clarity and convenience to my code. By wrapping two floats in an object I’m just bloating my memory and exec time. So instead of writing nice & clear code, I have to do sh#t like keeping each variable separated in another array.

      4. @filisoft

        >Does Java have structs now?
        >Why haven’t I been noticed?

        Who said it did? You seem to keep reading hidden meanings that aren’t present.

        >Look: I need to keep track of a collection of >points that have coords (float), color (integer), >flags (integer), etc (???).

        Keep them as primitive types in the fields of your class that implements the methods to work on those fields? Write a class that wraps around a buffer to store the information you want in the least space? There are ways around this issue you seem to be fixated with.. maybe they aren’t as clean as it would be in . There are lots of things that are horrible to implement in C but a breeze to do nicely in Java. Get over it.

        >I can do ProcessPoint(points[10]) instead of
        >ProcessPoint(points_x[10], points_y[10], >points_flags[10], points_color[10],…);

        Why exactly is that an issue?.. say you have points that are all the same colour.. you have just wasted memory by bundling the colour in with the other data of the point. If you want to make all of the points the same colour you have to loop through all of your structs. If you make your methods able to take the primitives as arguments you can reuse that method somewhere else where you just want to pass in the values. If only C had overloading right?

        >it’s much more work this way.

        I type one or two chars of the method name, press ctrl-space to complete the method name, eclipse fills out the method signature, and works out most of what I want for the parameters via code completion.. do you use notepad to write code or do you just have really lazy fingers?

        >I’m not your teacher.

        I’m very glad of that.

        >By wrapping two floats in a struct
        >By wrapping two floats in an object

        Again, structs are not objects, they have some of the properties of structs i.e. they have fields but they are not structs and never will be.
        There are plenty of things that could be implemented “better” in assembly .. that doesn’t make C or any other high level language bad. Horses for courses.

        >So instead of writing nice & clear code

        You are trying to code like you would in C for Java. You are applying the concept of structs (which only exist at compile time) to objects (look at how much you can do with reflection..). All of this is premature optimisation any how.. did you profile the code and see that the excess memory use was actually a problem? Yes if you have millions of points that might be a problem but when you profile your code and it turns out you only ever have 50 or so points who cares? On the other hand if you have 20 million points and it is a big problem you can come up with a solution.. hell you could even write some code in C and use it via JNI.

  11. “As for the utility of programming a microcontroller in Java, it’s still the second most popular language, after spending the better part of a decade as the number one language programmers choose to use”

    I cannot understand why….either point.
    1. How does this statement demonstrate the utility of embedded JAVA?
    It has been my experience that developers FAIL to make java applications TRULY PLATFORM PORTABLE – which was MY understanding for the #1 reason for the EXISTENCE of JAVA.
    2b. It has ALSO been my experience that any application written in JAVA is 2 to 3 times SLOWER than any comparable C/C++/C# application.
    2c. JAVA developers fail to completely closely emulate the *standard* things like folder navigation, menu/toolbar click, mouse selection, drag/drop and on, and on, ad nauseum.

  12. Did I time warp back 5 years ? Java has been available for ARM for years, this isn’t anything new, just a re-write by oracle with some new features. It still will not increase ARM developers because the problem with getting into ARM isn’t the programming language, it is setting up the hardware that baffles most people. Python ? Yep that has been around 5+ years too, and just about every other language in existence.

  13. Well, i follow this now for some hours and I must say. im still not impressed to go out and play with Java on my ARM systems. many people made good points on why not, and the points of why I should mostly getting hit afterwards.

    Do we need another platform for Java or do we need to improve an exsisting one? There is propberbly a thread over at the HaD Forums about this :P

  14. Java is the only option for people who developed Java ME embedded. The question was: Can Java be squeezed into an embedded system or not. Thus, all the discussion about power consumption, system dimensions, performance, etc is pointless.

    aJile’s SOCs is a form of Java I can imagine to be used in an embedded system:

    On the software Java VM front I still wonder why one should use $15 micro to run Java VM to flush a few LEDs while it can be done on $1 micro with free GCC…

  15. ” The question was: Can Java be squeezed into an embedded system or not.”

    Ask yourself: Just because we CAN, does it necessarily mean we SHOULD??
    Gosh, Can we squeeze VisualBasic 6 on a 6800?
    Even if the answer were YES, should we?

  16. Java is an excellent choice for a microcontroller programming language if you have a microcontroller chip that is too fast, has too much memory, draws too little current and is not producing enough heat.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.