Sunday, December 08, 2013

The case for copyrighted APIs

So Oracle is trying to sue Google over the idea that application program interfaces (known as APIs) are protected by copyright.  Now I won't go into a ton of detail but APIs expose to a programmer the pieces of software that can and cannot be used.  So if I needed to round a number, I might call a piece of code called, Math.round(56.73)

Now how exactly that piece of code actually rounds up, there is no doubt, the implementation is copyrighted.  But Oracle's argument is that the whole term, Math.round() is copyrighted, no matter how one implements it.

This would be akin to someone copyrighting the steering wheel.  Now a particular design of steering wheel understood, but the whole notion of a wheel that is used to control a car is just crazy.  The wheel is the expression (the API) of how the driver (programmer) interacts with whatever the steering mechanism is (the implementation).

I'm of the opinion that APIs fall outside copyright.  The reason being I cite Lotus Dev. Corp. v. Borland Int'l, Inc. 516 U.S. 233 (1996).  Here the Supreme Court ruled in favor of Borland that, "the set of available operations and the mechanics of how they are activated are not copyrightable."  This allowed Borland to use menus in their product called Quattro Pro that looked exactly like the menus in Lotus 1-2-3.  Just because the menus looked the same (there was a file, new worksheet, new formula, etc... menu) the underlying code behind those menu items were different enough to not constitute infringement of copyright.  How one goes about activating an operation is not the same as how that operation actually works.

Thus, the way I activate rounding, via the Math.round() is not the same as how that rounding occurs.  Thus, since Math.round() is the manner in which I actually activate that rounding, it should logically fall outside of copyright.

In an appeal to the DC circuit court Oracle is set to have a retrial on this very notion, is an API copyrightable?  "It seems to me that almost all computer code has to have a functional purpose, otherwise what's the purpose," --Judge Plager

While what Judge Plager says is true, all code at some point has a function, if the function is to express an underlying intent or implementation.  I believe that 17 USC 102(b) implies that if the function is simply expression of an idea, which an API would most certainly be that, it falls outside of the protection offered in 102(a).  Even if § 101 states clearly that API's fall into the definition of "computer program", 102(b) clarifies that definition to restrain application of copyright to broad ideas like, how do I call a number rounding piece of code?  If copyright existed on the notion of round(), then how would other's code their own implementation without eventually stepping on such broad claims?

There is no doubt, this case is bound for the Supreme Court, and the ramifications of copyrighted APIs would have broad implications on developers.  It would bring about a downward trend in interoperability.  Network protocols, web services, and more which rely on open APIs would suddenly become licensable technology.  Even worst, this could spill over into widely used standards for communication, imagine if the ability for one hospital to talk to another hospital was a commercial protocol via a copyrighted API.  Only if every hospital choose a single vendor would there be the ability to for hospitals to talk to each other.  Those who choose a different product would be in a different closed box from the others.  And trying to have proxy services that translate between the two of them would require a vendor to license from both vendors in question to make such a proxy, that would make such proxies insanely costly.

Open APIs are incredibly vital to developers, already developers face too many difficulties with "patented" software processes.  If APIs are ruled into the domain of copyright, developers will have increased pressure on design and ultimately will mean that some developers may never get out the door with the years it may take to do due-diligence to ensure copyright and patents aren't being broken.  API libraries may cease being freely usable, useful API libraries, it could take years before open APIs are completely untangled and ensured are infringement free, meaning that small software shops will suddenly have to invest thousands of dollars in commercial libraries or wait until whatever they were using gets untangled.  Either option could cost them more in the long run than they originally had to begin with.

It is clear that Oracle is doing this to take what they deem their piece of a multi-billion dollar industry within Android.  I can get they feel a bit jaded about the whole thing.  However, their argument would have much wider repercussions than on Android.  This would bring to an end anybody who mimics Amazon Web Services APIs for interoperability.  There is a lot of vendors that stand to lose out big time on this.  Additionally, current cloud services, like Azure, Amazon, Oracle, and yes even Google's could copyright their APIs and lock their customers programs forever, or until overturned, onto their platform.  Either a customer rewrites their entire application or pays out the ying-yang to build a proxy while they move from one to another platform.  Writing a program that can translate one API to another would be copyright infringement.

What can be done about it?  Not much at the current point in time, but it does highlight a warning sign that commercial vendors of software are ever looking for new ways to take traditional developer values and twist them into meanings that make them top dollar.  It is becoming clearing with each passing year that truly from the start open APIs will be the only sure fire way of avoiding having the rug pulled out from underneath you.

Ultimately HTML5 and the open web/format will be the only "safe" bet in town.  That is why organizations like Mozilla, Apache, The Document Foundation, the Qt Project, the Fedora Project and others are so vital to developers.  They stand for platforms, libraries, protocols, and formats that are free from surprises, free for implementation from the start, free to be used for the masses to communicate freely with the world.  Because they believe that developers and users have a right to exchange ideas with one another without fear that one day, they might get a knock at the door asking for money.

Copyrighted APIs will have yet another chilling effect, but only because we have thus far had good faith in those who created these APIs, that they wouldn't do something as stupid as Oracle has suddenly decided to do.  Maybe developers were naive, but it takes someone with a really cold heart to actually act on that.   I do hope that Oracle finds whatever their reward to be, should this all end in their favor, worth the irreparable damage that this has on the faith of developers.  As future developers will be extra cautious to not fall into some inescapable pit and freely distributed SDKs will be met with ever increased skepticism of how "free" that platform truly is.

Monday, November 18, 2013

Inform 7 First going.

So I've started using Inform 7 for writing IF (interactive fiction). I've used Inform 6 before and TADS, which I'm pretty partial towards TADS.

However, I've decided to give Inform 7 a go.  It's programming syntax is described as natural language.  Here is an example of me creating a room object, creating an enumerated property, creating a generic object, giving the generic object the enumerated property, and creating a few instances of the new object type.

Your Apartment is a room. 

Color is a kind of value. The colors are red, blue, and green.
A car is a kind of thing. A car has a color. The color of the car is blue.
Before printing the name of a car: say "[color] ".

The North Car is a car.
The South Car is a car.
The color of the North car is red.
The North Car is in your apartment.
The South Car is in your apartment.

Now obviously, I hope you don't really find cars in your apartment.  However this illustrates pretty well the construct of Inform 7's language.  I've created a room call "your apartment"  Created the enum color and given it {red, blue, green}.  Created a car type which has a enum value and set a default value of blue.  I've overridden the print name method of a car type to print the color, and I created two cars [North Car, South Car] and given North Car the color red.
So it's a little weird to work with at first and I'm still struggling a bit with the syntax but hopefully, I'll be able to do my first five room adventure with Inform soon enough.

Wish me luck!

Monday, July 15, 2013

The Qt dictate

So it is pretty apparent that I haven't been updating this blog in a while.  The reason for this is that we are going through a period where we are converting MS Access files into full fledged applications.

Now MS Access is fine and what not, but after a certain point, it can get a bit abused.  That point was crossed some time ago in my company that I work for.  So what are we switching to?  Not Java, no that would have been too awesome.  However, I can't say that I am really down about what platform we are going with.  We are going to be using Qt!  Qt 5 to be exact.

I'm a bit thrilled to be tasked to start working back in my favorite language, C++.  Not only that, Qt 5 supports many of the most recent additions to the C++ language.  I can hardly wait to start digging in.

I'm going to pick back up on the JSF tutorial here in a bit.  The next step it looks like was a read/write JSF managed bean.  So I'll do a quick run through of that, but I doubt that I'll have the namesapces match up with what they were in the previous post.

I don't fully remember where I was going with all of the JSF stuff, but I guess after the Read/Write thing, moving into AJAX in JSF.


Friday, April 19, 2013

Moving on, using a managed bean

So let's try using what is known as JSF managed beans.  Managed beans are plain old Java objects (POJO) that get managed by the JSF controller.

How it technically works is that the JSF library will scan the classes in your project for the @ManagedBean annotation.  When it finds a class, it registers it as a managed type.

Once registered, you can create beans all over the place in your JSF pages.  Beans can have one of six scopes:

  • @RequestScope - This means the bean is created for the life of the HTTP request.  Once the HTTP request has been fully processed the bean is destroyed.  Basically, these beans exist so long as the request for a web page lasts.  Once the page has been serviced, the bean is no longer available.  This also applies to AJAX requests.
  • @SessionScope - This bean is created for the life of the HTTP session.  Once a HTTP session is started, the JSF library will create this bean and allow it to last so long as the HTTP session is still open.  Once the HTTP session ends, due to inactivity or closing the web page, the bean is destroyed.
  • @ViewScope - This is an interesting bean that will last through requests, so long as the current view has not changed.  This is useful is you present a single view to the user and then do a lot of AJAX in the background to modify that view.
  • @ApplicationScope - This is a bean that is created as soon as the application is started.  That means as soon as you publish it to the server or upon the first HTTP packet to the application (this is dictated by the eager=true flag, setting to true is as soon as you publish it.)  Only use this kind of bean for things that can safely be shared between instances of sessions.  Just FYI, don't assume that this automatically means thread safety.
  • @NoneScope - This is a bean that is created as soon as it is requested in a JSF page and destroyed as soon as it was created.  If you use the bean three times in your JSF page, then the bean is created and destroyed three times.  In my example to follow, the none scope would have sufficed.  Use this kind of bean for one shot stuff that doesn't need to be remembered, or if you intend on using this bean within another bean.
  • @CustomScope - This is exactly what it says.  You define when and where the bean exists and get destroyed by modifying a Map that is created for managing this bean.  When you add an entry to the Map, the bean is created, when you remove the entry the bean is destroyed.  Use this when nothing above seems to fit your use-case.
So let's create a bean!

Right mouse click on your project and select New » Other…

This screen appears
 Choose the JSF Managed Bean and click Next >

We're just going to go with the defaults here with a little bit of extra like package name, generally you are going to name this something actually useful.
Fill in the information about your bean and I'm going to set it to request scope.  The package will be lan.testing.  You can also add a little description to the bean.  No idea where this description gets saved at the moment.  Go ahead and click finish.

Now you will have a newly minted request bean.

New JSF Managed Bean
Now at the moment this bean does absolutely nothing other than suck memory.  So let's make it do something more interesting.  Let's add a field in the Java class called message.  We will make this field private.  So let's add that now.  While we are at it, let's set the fields default value by placing that in the constructor.

Adding a field to the bean

Now let's expose that bean so that it can be used on our pages.  We do that by creating standard getters and setters.  Just press Alt+Insert in the IDE to get a popup.

Select the Getter and Setter… option
Check the boxes of the fields you want to expose, since we have one, we are exposing them all.
Your Java class should look like the following:

Your field is now exposed by the bean.
Now that we have exposed the field, let's go ahead and add that to our JSF page.  To access JSF managed beans we need to replace the static text in our tag with #{}.  The pound sign and curly brackets indicate to the JSF libraries that it needs to look at all of the registered classes.

Once we type that into the value you'll notice a code completion pop-up appear.

Code completions is happening.
In the completion box you should see the name of your managed bean.  Go ahead and select it.  It will now appear as #{whateverYouNamedYourBean}.

Go ahead and type period to get the next bit, this will show you what has been exposed by this bean.

Our field exposed by the bean
Go ahead and select the exposed message field.

Our completed code
Once you have done that, go ahead and press the giant play button to see the results.

Ta-da!  Your field in the Java class is now exposed and being used by the JSF libraries.  Right now, not very useful, but good to know that it is working.  All of this on Tomcat!

Quick point:
Beans are meant to allow you to create useful components to be used in your JSF application.  Right now it might be a bit hard to see that, but eventually you'll start building beans that are for all kinds of purposes, with all kinds of different scopes.

The thing to remember about beans is that you should take the million little cogs approach with them.  As opposed to building one giant bean or one huge session bean and one huge request bean, beans should be for a specific purpose in your web application.  You may have one that hold the current user's profile information, another to hold the current conversation that they are in, and so on.

Right now we are only using the read function (get) of the bean.  I'll show you next how to write (set) to the bean and explain a bit about why it works.

First JSF web application on Tomcat 7

Okay as promised, here is the first Netbeans 7.3 + JSF 2.1 + Tomcat 7 web application.

First download Netbeans, if you haven't already.  Go ahead and select the full all out, no hold bars download.  Next install the software and make sure you install the Tomcat that is included with Netbeans installer.

Okay now that you have all of that out of the way, go ahead and start up Netbeans and head over to the services tab and start up the Tomcat Server installed on your system.

Starting up the Tomcat server.  Netbeans 7.3 automatically detects this installed if you did it with the installer from the web.

Now go ahead and start a new project.  Choose Java Web | Web Application.  See the following images for the wizard screenshots.

Step 1 - Title your new web application.

Step 2 - Choose the server to deploy to and the context to use.  MAKE SURE YOU SELECT THE TOMCAT INSTALL!

Step 3 - Include what libraries you might need.  Make sure you click the JavaServer Faces library.  Tomcat doesn't come with JSF built in, you must manually add it!

Okay you should now have a shell project with the default index file.

Behold!  The default index file!

So to ensure that we are running JSF and not that the server is doing some sort of pseudo translation here, let's use an actual JSF tag.

I'll use the tag which does exactly what it says, it outputs text.  Here I'll just use some static value for the value attribute.

Adding in a JSF tag, don't forget the

Now go ahead and click on the run project icon, it's that giant play button up there.  If your Tomcat server is running (you better go catch it, ha ha) then it will deploy the project to the server and open up your browser to the context that you provided.

Pushing the Play button.

Ta-da!  Our project runs!
 So there you go, your very first JSF 2.1 application on a Tomcat server.

Here's some highlights.  Tomcat 7 does not come with JSF baked in.  It is a simple servlet server.  Ergo, you must include the JSF library with your project.  The nice thing is that Netbeans will go ahead and do that for you, because it knows that Tomcat doesn't have these libraries by default.

Draw your attention to the highlighted area.
Now here's the deal.  If at some point down the road, you add these libraries to the Tomcat server itself, then you need to make sure that Netbeans doesn't try to "help" you out here.  To do that, you need to indicate that the libraries do not need to be pushed to the server with the application.  Right mouse click on the libraries icon and choose properties.

If you do not see Properties, then it's because you aren't right clicking in the correct 16x16 space.
Once you do that this window appears:

Notice the check boxes highlighted.  When they are checked, that means the library will be "packaged" with the application.  If the libraries are already on the server, you don't need to package them.

Don't include the JSF libraries inside your server, just package them with the application.  Once you toss the libraries into the server, that pretty much makes that server a JSF Tomcat server.

The downside of this is, this could potentially ruin any old JSP applications that you have on the server.  Now it shouldn't but I would count on something jacked up happening the second you toss JSF libraries on a Tomcat running JSP applications.

I'll start covering some more fun stuff with JSF next post!  Have fun!

Loss of data and moving on.

Of course,

I've lost the whole project that I was doing in JSP and Tomcat.  I really don't feel like going back and going over the whole things…again.

So I'm going to need a new project now.  Hmmm…

Okay, let's do the good old fashion Tomcat 7 + JSF 2.0 + NetBeans IDE.

Not to say that I don't like Eclipse, but I'm a bigger fan of NetBeans.  Sorry for all of the Eclipse fan boys out there.  If it helps, I use Eclipse everyday with Android stuff.

In fact!  How about something Android?  That sounds like fun too!  So here's what I'm going to do going forward.

Monday and Friday I'll do a post about JSF and pretty much J2EE stuff.

Wednesday I'll do something about Android.  Why the hate for Android?  Because I spend so much time developing Android stuff for work, I get tired of even looking at the IDE.  I guess that's why my interest in the JSP thing waned so much.

I'm so capricious it's not even funny.  I'll setup some labels.  We will name the J2EE stuff with the J2EE label and when it includes TomCat, I'll add in TomCat.  When it deals with Glassfish I'll add Glassfish.  For the Android stuff, I'll just add the label Android.

Okay, so there we go.  Something to do.  Oh look it's Friday!  Better start working on my first J2EE post.


Wednesday, February 27, 2013

Where have I been?

You'll have to excuse me, I haven't updated the blog in some time.  I've been doing the road warrior thing for a couple of weeks now, which keeps me from my standard machine that I use and have all my code on at home.

I'll jump back to the JSP demonstration here in a bit.  I know you've all heard that before.

Thursday, January 03, 2013

Doing this MVC thing! Part 1

Let's get back to our web application shall we?

First let's remove everything in our project and start fresh. Here is what I have for the Contact Keeper project.

My current layout for the project.

So basically all that we are keeping is the "com.blogger.contacts.beans" package and the JSTL libraries.  Now let's begin where any sensible project would begin.  On the information that we are trying to store.  In other words, I like to look at the problem as "what to store, before presentation."  Some developers like to work on presentation first and then data.  I always get confused when I work this way, hence the reason I like to focus on data first.  However, to each their own.

Now our "database" isn't going to be a real database, we are just going to use a memory structure to store the information.  If our server gets turned off, then we loose all of our information.  That's okay, because we are going to make the interface to our database generic so that if we decide to ditch the memory storage and replace it with a real DB like PostgreSQL later on, then it will require very little code change.

So the first thing we need to do is create the actual object that we plan to store.  That means we need to model our contact in Java code.  If we were using a real database then we'd add another layer on top of our contact model to implement JPA.  JPA is just a fancy system that you use to translate Java objects into SQL code automatically (I am really simplifying the heck out of JPA here, but the premise holds.)

So we are just going to have a basic naked model here.  Our contacts should have the following:
  • First name - string
  • Last name - string
  • Phone number - string (we are not going to deal with validation here, at least not now)
  • Age - integer (real contact keepers would ask for Birthdate and calculate age from that, be we aren't doing that here, at least not now)
That's it.  Pretty simple.  I want to keep it pretty simple for the time being.

So let's create your Java code for this model.  We are going to store this Java class in a new package called, "com.blogger.contacts.entity"  Entity is the technical term for an object that models to something one would store in a database (or relates to something in the real world if you want a much fuller idea of the term), honestly if you really want a better technical definition, feel free to hit up Wikipedia.  At any rate, we are going to create anything that maps to the real problem in the entity package.

So here is the code:

package com.blogger.contacts.entity;


public class Contact implements Serializable {

  * Serial version of our contact class, so that version stay compatible. 
 private static final long serialVersionUID = 1L;
 private String firstName;
 private String lastName;
 private String phoneNumber;
 private Integer age;
 public Contact() {
  this.firstName = null;
  this.lastName = null;
  this.phoneNumber = null;
  this.age = null;
 public Contact(String firstName, String lastName, String phoneNumber,
   Integer age) {
  this.firstName = firstName;
  this.lastName = lastName;
  this.phoneNumber = phoneNumber;
  this.age = age;

 public String getFirstName() {
  return firstName;

 public void setFirstName(String firstName) {
  this.firstName = firstName;

 public String getLastName() {
  return lastName;

 public void setLastName(String lastName) {
  this.lastName = lastName;

 public String getPhoneNumber() {
  return phoneNumber;

 public void setPhoneNumber(String phoneNumber) {
  this.phoneNumber = phoneNumber;

 public Integer getAge() {
  return age;

 public void setAge(Integer age) {
  this.age = age;

 public int hashCode() {
  final int prime = 31;
  int result = 1;
  result = prime * result + ((age == null) ? 0 : age.hashCode());
  result = prime * result
    + ((firstName == null) ? 0 : firstName.hashCode());
  result = prime * result
    + ((lastName == null) ? 0 : lastName.hashCode());
  result = prime * result
    + ((phoneNumber == null) ? 0 : phoneNumber.hashCode());
  return result;

 public boolean equals(Object obj) {
  if (this == obj)
   return true;
  if (obj == null)
   return false;
  if (getClass() != obj.getClass())
   return false;
  Contact other = (Contact) obj;
  if (age == null) {
   if (other.age != null)
    return false;
  } else if (!age.equals(other.age))
   return false;
  if (firstName == null) {
   if (other.firstName != null)
    return false;
  } else if (!firstName.equals(other.firstName))
   return false;
  if (lastName == null) {
   if (other.lastName != null)
    return false;
  } else if (!lastName.equals(other.lastName))
   return false;
  if (phoneNumber == null) {
   if (other.phoneNumber != null)
    return false;
  } else if (!phoneNumber.equals(other.phoneNumber))
   return false;
  return true;

 public String toString() {
  return "Contact [firstName=" + firstName + ", lastName=" + lastName
    + ", phoneNumber=" + phoneNumber + ", age=" + age + "]";


So you may be asking yourself, why isn't this a bean?  Well it is, to an extent, back in the day you'd be absolutely correct about this being a bean, as this used to be called an Entity Bean.  However, as Java EE matured it became clear that Entities were stuff that mapped to real world things, and Beans were used to access stuff.  So in a basic case like ours here, our Entity could very well function as the bean as well, since the logic needed to access our entity is pretty simple stuff.  However, in more complex cases we might want Access beans that handle the needed logic to access our entities.

For now what we are going to do is let our entity stand by itself and we will create a DAO (Data Access Object) bean that will provide the basic CRUD (Create, Read, Update, and Delete) that we need to have a functioning application.

So there is our entity.  I've provided a hash code function, an equals function, and a to string function.  I usually do this for my benefit rather than any application need.  Your taste to do so may vary.

There you go, we've created the entity.  Now we need to create somewhere to actually store these things!  This needs to be a memory based storage, remember what I said earlier, and it needs to be simple and not overly complex.  What I am going to do, and this isn't something you'd normally do on production code, is just create a regular old collection and set it to the application scope, so that any sessions can access it.  Now you don't do this in normal production code because it is not thread safe at all.  People could come in and create the same contact at the same time and there would be nothing to stop them, or they could delete a contact that was deleted by someone else while the first person was deleting it.  In other words, it could lead to all kinds of badness.

We are going to use a basic Array List collection because it is fast on insert (adding contacts), fast on update (changing information or updating a contact), normal speed on listing (viewing all contacts), and slow on delete and random access (getting rid of contacts and finding a contact).  The only down side is the last part, random access, a contact list's number one feature is "finding" contacts.  We could use a hash map, but then our program would a bit more memory hungry but finding contacts would be very fast, and since we are not actually going to be using this code in any production system, I doubt that our contact list will ever grow to the size where a hash map makes more sense than an array list.  (I would need at least the assumption that the contact list would be at least 100 contacts or more before I would consider the hash map a good fit.)

break time...

Just noticed it is getting late, better call it a night for the time being.  We will implement our Array List next and we are going to create an interface DAO and DAO for that implementation that implements our interface.  So in case you missed that, part two will do the following.

  • Implement our Array List to store our Contact entities.
  • Create an interface for our DAO so that we keep a standard interface regardless of if we are using memory or actually DB back ends.
  • Create a concrete object for our DAO interface that has all the logic to connect our interface and Array List implementation.