ciplogic.com
Live with grace. Write superb software.

java

  • Good Code Exists

    A PHP programmer was begging on a street corner. With dirty clothing, extremely sad and distracted, was watching the ground. On the cardboard in front of him was written: "Help a poor PHP programmer".

    From time to time, a Java or C# developer would give him something.

    A Python programmer that happened to pass by, stopped, took the cardboard, wrote a few words, then left.

    Something amazing happened. Ruby, Groovy, C# and Java programmers were stopping, reading what was written and giving plenty of money, some of them with tears in their eyes, crying with deep sorrow. A pretty large crowd gathered around him, so the PHP programmer raised his eyes. He read the cardboard, and cried with a shriek from the bottom of his lungs, lungs of a despaired man, from his truly unfortunate state. Tears started flowing over his cheeks, faced now with the truth revealed to his soul, when he read the words:

    "Help a poor PHP programmer. I know good code exists, I just have never seen it."

    A Perl programmer, extremely dirty, with his ripped clothing, and disheveled hair also passed trough the crowd, bumping into people. Unfortunately no one discovered the meaning of the senseless words he was muttering, so they let him be, to continue his painful existence.

  • How Programming Languages Relate to Girlfriends

    C

    The simple girlfriend that doesn't really get you. Whenever you go to a new place, she doesn't want to go. Goes if you really insist, but causes a scene there.

    C++

    The borderline insane girlfriend. One mistake, and she goes bonkers. Tries to be friends with all of your friends, even if no one likes her.

    Python

    Your true love, but you know deep inside you two won't last. She's nice, but whenever you want something from her she's nowhere to be found.

    Java

    Boring as hell. You pity her and you think you should like her more. You just can't get yourself to do it. She keeps trying to make it work.

    C#

    The slightly prettier sister of Java, with all the mental issues of C++.

    PHP

    The beast from Beauty and the Beast. Reasoning with her is like talking with a grizzly bear.

    Perl

    She always hungers for human flesh. Congratulations, you're dating a zombie.

     

  • Maven for Noobs (Beginners)

    I'm going in the next article (or two, if I feel I go way overboard in length) to explain you Maven as a build tool. At the end you won't be an expert, but you'll have a solid grasp on what it does to build projects, how to investigate what it does, and why it is so popular. So grab you favorite beverage (better be coffee), we're jumping straight in:

    Introduction

    Maven does three things, really well, which are sort of inter connected:

    1. Project Management

    The name of the project, who works on it, what SCM are configured for it, licenses, etc.

    2. Artifact Repository (Artifact = fancy name for binaries)

    Downloading of the various dependencies. Even Maven itself has a lot of its functionality as plugins that will be downloaded.

    3. Build System

    A bunch of steps to execute to get from a bunch of sources a binary output.

    Maven has for a single project only one configuration file, and it must be called pom.xml. POM itself stands for Project Object Model. This is an unfortunate name, it literally just means that all the data for a project is there, touching all the 3 points mentioned (project management, artifact repository dependencies, and the build system).

    In this article we will focus only on the 3rd point of the article, namely the build system.

  • Programming Vocabulary

    Whenever talking to each other, whenever that happens, developers tend to formalize specific concepts and map them to specific words.

    For example you all know what a singleton is. We don't need to disambiguate in regards to it. Nor do we need to disambiguate in regards to what an object, function, or method are.

    And this is why the following article A Factory Should Create, Not Retain, in which Paul M. Jones claims that a factory that retains references to its created instances it's not truly a factory, came as a surprise for me.

    The article TL;DR: A factory just creates objects, a registry just references objects, a container does both.

    Fine.

    But while this might be technically correct, it's not actually meaningful in any way to make this distinction, except tedious mental exercise. Don't worry, here come examples (Java, but, you get the picture).

     

    1. Caching factories are containers

    In java numbers can be represented as either primitives, either immutable objects. To convert from one another, e.g. from `int` to `Integer`, the Integer class has a factory function named: `valueOf(int) : Integer`. This makes the Integer class a factory for Integer objects.

    Except that I lied a bit.

    Creating objects for every number it's expensive, and since the low indexes are heavily used, they are pre-cached (at least in the Oracle's Java version they are). This is not part of the functional specification, it's just an implementation detail, on how the objects are going to be fetched. Note that objects outside that range are always created.

    http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Integer.java#Integer.valueOf%28int%29

    1
    2
    3
    4
    5
    6
    7
        public static Integer valueOf(int i) {
            final int offset = 128;
            if (i >= -128 && i <= 127) { // must cache
                return IntegerCache.cache[i + offset];
            }
            return new Integer(i);
        }

    Can you be pedantic and say, that this is a container, and not actually a factory? Yes. Does it add value to the conversation? No. I'm going later to explain why this is an issue.

    Note that if I just comment those caching lines, my container magically transforms to a factory, and if I uncomment it, it's back a container, even if functionally its behaviour is the same. But whatever.

    By the same definition...

     

    2. Registries that create objects are containers as well

    Again in java there is an amazing class, named TreeMap. TreeMap holds instances to these objects into a tree structure, thus its full of imagination name of TreeMap. Tree... Map. TreeMap.

    Someone could argue that this is a registry, but again, if we want to be pedantic about it, this is no ordinary registry. Because it creates its keys, so it's also a factory.

    http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/TreeMap.java#TreeMap.put%28java.lang.Object%2Cjava.lang.Object%29

    Among the many separation of concerns that this class blatantly violates, are also creating and reordering objects, but for the sake of our discution, we can safely say that the TreeMap is technically also a factory, since it creates its keys:

    1
    2
    3
    4
    5
          Entry<K,V> e = new Entry<K,V>(key, value, parent);
          if (cmp < 0)
              parent.left = e;
          else
              parent.right = e;

     

    3. Singleton

    Finally, I said that I will explain why I find it as an issue, with being pedantic about separation of concerns. Because it stiffles communication. We actually lose more time trying to disambiguate things that our so specific vocabulary would allegedly try to disambiguate.

    The best example is Singleton.

    Singleton it's a pattern that describes how single instances can be created for an application. This is made by having a single static instance on the class, and using it across the application.

    Except that this is not true if you use Dependency Injection. The singleton class will not have the single instance bound to the class. It will not implement the actual pattern. Actually might not even be a singleton in certain cases, since now this might be a configuration issue. So I should not use the "singleton" word to describe it at all, since it's not implementing the pattern, nor can I guarantee that it will always be a singleton.

    Conclusion

    But that's why this whole thing makes no sense. If I know that in my application an object has a single instance (provided by the DI, or its own static reference, or the JVM that creates it via some callback method, etc), then I can say it is a singleton. Its meaning is derived from its behavior, not the actual implementation on how the singleton behavior will be provided. That is an implementation detail.

    Similarily, if I have an object that creates other objects as one of its main purposes in life, it is a factory, irrespective on what kind of caching (if any it uses). It's meaningless to say that valueOf from Integer is actually a container method. There is no gained value out of it.

    If an object is used to mainly store references to other objects, then yes, it's a registry. The same goes on key creation. This doesn't changes the purpose of the class.

    It makes no sense looking at every tidbit of implementation details, with super categorization. There is no benefit out of it. No cleaner code, no better communication. Nothing.

    We can't see the forest anymore, since so many trees are blocking our view.

  • Smile at the World, and the World Will Smile Back

    I have this idea, where we should by convention name all the iterables P or D.

    So iterating over a list would become:

    1
    2
    3
    4
    5
    int haha, sum;
     
    for (haha :D) {
      sum += haha;
    }

    Obviously cryptic as hell, but the code will smile back at you.

  • sun.misc.Unsafe It's Being Removed. And That's a Good Thing.

    An interesting article is making waves on dzone and twitter:

    http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/

    TL;DR: the sun.misc.* package it's going to be removed, a bunch of libraries are using it, apocalypse will ensue, just because Oracle removes packages for "no reason".(I kid you not, the dripstat author actually states that).

    No it's not a new thing. No it's not the apocalypse now either. Let's break it down on why:

    1. It's not at all a "no reason" change

    It's because Java has become so full of security exploits, it's not even funny at this moment. It's scary to see how in January a patch fixed 19 security holes, with 13 of them being show stoppers. Oracle themselves explains it at length even.

    It's not because:

    "This engineer hates the Unsafe class for no real reason at all.."

    That's a silly statement, to say the least. (To be honest, I get my blood boiling a bit just reading that sentence, because it's insulting to the engineer)

    It is because people are loosing trust in the platform. Why would you go with a platform ridden with bugs like that? What's the point in using whatever framework that is allegedly super secure, if the JVM itself it's the weakest link. That is what makes Java now loose billions.

    That's the reason why Apple dropped Java altogether, because its security was in the gutter.

    2. It's a private package of the JVM

    If you're bold enough to use it, you should be bold enough to write your own thing. Why should Oracle be bound by some form of moral requirement to document some whatever cryptic legacy code, that people reverse engineered in the first place? What. The. Hell.

    Probably this tweet captures the essence of the whole thing: 

    It's not even such a big deal. I swear!

    Do you know what else introduced breaking API changes for public APIs? The endorsed folder. It's what stuff like WebLogic uses to overwrite already published public APIs. I'm going to reiterate this: There is already the endorsed folder, that allows overwriting public APIs from the JVM, and people are using it. This is a great thing actually, especially if the API was not finalized. Why getting stuck with an API for the next two years?

    Public APIs! And you see that the universe imploded? Billions of dollars were lost? Calm down people, jeeeez.

    3. There will still be YEARS of Java 8 support

    Oracle doesn't just throw away JVMs, and then just plugs support out. If the program you're using, and its creepy library that needs the sun.misc.Unsafe are that important, go buy support. I mean, for crying out loud, you can still get Java 6 support that people were using to connect to dinosaurs. And the Java life cycle support it's for 11 (eleven!!) years.

    So finally, please all, can you just chill out?

    It's all for the better I promise.

    PS: I am not affiliated with Oracle in any shape or form, beside I'm developing and using Java, and I'm a certified JEE5 Enterprise Architect.

  • The Eclipse Experience

Germanium

The one to rule them all. The browsers that is.

SharpKnight

SharpKnight is an Android chess game.

MagicGroup

MagicGroup is an eclipse plugin.