Tag Archives: coding

Why does Java not support unsigned int? – Part 1

An interesting thing for me, is that if I am active on twitter during daytime in India (now that I’m here on vacation), I get to have some interesting conversations about design and development. Today, I chanced to talk about the lack of unsigned values support in Java.


  1. Veerabahu
    veechand is there unsigned int in #java support your answers
  2. Shivanand Velmurugan
    shiva @veechand nope. but use char instead. If you really want a type, you can define your own class backed by char
  3. Veerabahu
    veechand @shiva @surendrakumar defining a own class for unsigned..let me think over it.. but my main question is y #java didn’t support unsigned ?
  4. Shivanand Velmurugan
    shiva @veechand @surendrakumar the question actually is, why do you need unsigned?
  5. Veerabahu
    veechand @shiva @surendrakumar my answer so that in given 32 bit I could store wide range of numbers (given my application wont go negative)
  6. Surendra Kumar
    surendrakumar @shiva a lot of real life applications uses unsigned int. Example sales, money, hours, are all unsigned.

this quote was brought to you by quoteurl

Java is, by no means, a “new” language for anyone I know. However, we still try to write C/C++ like code using it. We approach it with all of the training of C/C++, and start micro-optimisation much before it is needed, and end up with hard to comprehend complex code.

I thought I will write a long-winded post about why unsigned int is not available in Java, and how to emulate it if you really need to, but I will leave that to more able hands.

The reason for lack of unsigned types in Java are:
1. The core of the Java language was designed to be simple. This meant leaving out anything that adds complexity that can be done without. unsigned types didn’t make the cut
2. Someone got lazy and didn’t bother to implement them, when the time came to make Oak into Java. (I wish leaving things out like this happen more in the industry).

Now, let’s examine why one requires unsigned types:
1. Represent business case values like salary or percentile etc
2. Store bitsets — each bit representing some state or option
3. provide the ability to store more value that one can in an signed, thereby requiring lesser in-memory size

Case 1 is a no brainer: As long as the value fits within the bounds of a 32-bit integer, you shouldn’t care. Unless you need to store a value greater than 2,147,483,647, you shouldn’t care if it is signed or unsigned.

Case 2 is a hack: This is a typical carry-over from the C world, where there are no true enum or bitset types. If you need this, consider using an Enum or BitSet (as the case be for the problem you are trying to address)

Case 3 is a delusion, and a sin: To a certain extent this is also something that was necessary and a good thing in C, and almost useless, and sometimes wrong to do in Java. The cost and the risk of implementing a type, particularly one that will require, new arithmetic semantics to be written, is never justified. The less new language syntax one invents, the simpler the code is. My rule of thumb is — if I’m extending the language, I delete that class, and re-write it to use only existing semantics. If that means re-writing 5 other classes, so be it. In the long run, that yields a better, compact, and clean system.

Now contrast that, with using a signed int, where you expect the value to be unsigned. Unless you need to store a value greater than 2,147,483,647 there is no reason or benefit for implementing an unsigned int. Even in that case, unless you expect that to be marshalled to a system implemented in another language (like C/C++) via rpc, you should be using a long.

The next time you get the urge to extend the Java language, by defining a class that the language left out — think twice if you really need it. If, after deliberation, you still think you need it, implement it, use it in your code, delete the implementation and re-write your code. Trust me, it won’t have affected the application much, but your code will be cleaner and simpler to understand.

That is worth every extra-line of non-resuable code that you write.

Peace.
-Shiva

The devil is in the why?

Recently I got asked, what the best way to do a join between two large lists,  into another list was? I always tend to answer that question with: it depends. 

Just like any other algorithm, there is no silver bullet. It is a trade off  between CPU and memory utilisation. Sometimes, we do have to think about these  things (this is code in c++ on a device with scarce resources, to say the  least).

Of course, the simplest solution for this would be to use multiple for loops:

// merge - version 1
function List<C> merge(List<A> l1, List<B> l2) {

  // oh god! I shouldn't be doing this
  for(A a: l1) {
    C c = new C(a);
    for(B b: l2) {
      if (c.foo == b.foo) {
        c.add(b);
      }
    }
  }
}

As is obvious any half-decent programmer would shudder at the thought of writing something like this, particularly let it run on a device with limited resources. A simple way to refactor this would be to create an index for one of the lists and iterate through other. 

// merge - version 2
function List<C> merge(List<A> l1, List<B> l2) {

  // create the index
  HashMap<Foo, Bar> map = new HashMap();  

  for (B b: l2) {
    map.put (b.foo, b);
  }

  for(A a: l1) {
    C c = new C(a);
    c.add(map.get(a.foo));
  }
}

Conventional wisdom says, that version 2 is much better than version 1. Right? Well, what if you have 128 MB of shared memory across your system, but a dedicated processor for your subsystem?! Won’t you want to pick version 1 in that case? What if both the lists can have millions of entries? That would render both these cases useless.

Sometimes, before trying to find a technical solution to the problem at hand, it might help to ask why? What is the need for this requirement? The key is to ask why until you reach a specific use-case. I tend to ask this all the way until I reach either a SOAP request, or a specific component in the GUI that requires this piece of data. Most of the time, we can get by without writing a potentially inefficient solution. 

Lord of his city

In this case, after several “why”s, I discovered that this requirement came about, since one of the products in our suite (yeah we have a bunch of products that build on each other), need to display a list of names of object C, as the user searches for a specific one to add items to. If we had decided to write either v1 or v2, every time the user opened that GUI component, we would transport, a possible 10000 records from the device all the way to the GUI (which in our case is several layers above), when we only need a list of names based on a specific criteria.

 

The “how” of your design depends the “why”. The only limiting factor is the willingness to ask why, until you can find an alternate solution, or, are absolutely convinced that there is no other way to acheive a specific requirement without writing some inefficient code — then defend rigorously against doing it. well, atleast you have to get a some kind of limits in place. 

Sometimes you have to stand up to your product manager, and sometimes you have to take a sip of warm wine, and go write that “piece of crap” code. 

Happy coding!

Proposed GUI for C++ based twitter client

I got really sick of using Adobe AIR apps that take up more and more of system memory for an app that does twitter.

I’ve decided to put my “coding for myself” hat on and write a QT based C++ application (that should be cross-platform). No name as yet, but I will find something soon. QtTwitter is taken. Mebbe, once I have a working version, I can get ownership of the project on google code.

Share photos on twitter with Twitpic

That’s the proposed GUI. Sorry for the bad light. The iphone cam’s not too good with tungsten light.

Any suggestions?! I will try and post some mock up as I create em. I don’t want to be writing my own twitter REST c++ library. Any suggestion are welcome.