Open terminal and do the following:

[korey@localhost ~]$ cd /Library/Java/JavaVirtualMachines
[korey@localhost /Library/Java/JavaVirtualMachines]$ ls -al

This will give you a list of JDKs that you have installed. To set the default java version to 1.8.0_131 for example, use the following command:

[korey@localhost ~]$ /usr/libexec/java_home -v 1.8.0_131 --exec javac -version

Related link read more

In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.

• If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
• If you want to sign your application with a key, the default build keeps prompting you for the keystore password

Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.

Environment Setup

The first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:

#!/bin/sh

export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\
$HOME/Documents/Development/android-sdk-macosx/platform-tools

export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx

Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).

At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:

$ android list targets

Build files

In order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.

Creating a new project

In order to create a new project from the command line, run the following command:

$ android create project --target  --name MyFirstApp \
--path /MyApp --activity MainActivity \
--package com.acme.myapp

The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.

Once the project is created, copy over the following files to the root of your own project and then delete this app folder.

• ant.properties – This is where you store your project specific properties for Ant
• build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
• local.properties – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
• progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
• project.properties – This file contains the target for your project and is most likely already part of your project.

Updating your existing project

This is probably your best bet since it is less of a hack and should add the same set of files to your project.

$ android update project --name  --target  \
--path 

Once again, make sure to use the same <target-id>

Customizing the build

Now that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy. Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:

What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.

Signing the app

One of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the ant.properties file which includes your project specific properties. Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good. So, to get back to the issue at hand, include the following four lines in your ant.properties file and you are good to go:

 key.store=
 key.store.password=
 key.alias=
 key.alias.password=

If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.

The build command

OK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.

$ ant debug
or
$ ant release

Good luck. read more

I recently came across the Play framework (not to be confused with the new name for the Android Market Place). Think of it as the Java version of Ruby on Rails, or one of a dozen other frameworks that leverage convention over configuration. The real beauty here is that you get all the benefits of compiled code with the ease of use of scripted languages. With all of these light, easily scalable frameworks, why would you need a full J2EE stack? In my opinion, the latter is only necessary in very rare situations, where as the former will do the job most of the time with more ease and less cost. Its the old 80-20 rule. read more

This post is about the Google App Engine and its limitations. I googled for a while to try and find an article on how to do better queries using the datastore, but I did not find what I needed. I hope this helps some of you out there. I have a a bunch of child entities, but I only want a select few of them, so I need to query like good old SQL. here is the scenario:

@Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE)
public abstract class A {
}

public class B  extends A {
    List<D>members;
}

@Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE)
public abstract class C extends A {
    B owner;
}

public class D extends C {
    boolean active;
}

public class E extends C {
    String otherProp;
}

As you can see A is my base object with some properties that I want all my objects to have. Now i want to get all Cs that are active and belong to a particular B. Well, the short answer is you cannot and that is because the relationship is not directly on the child class but is on its super class. This must be a bug!!! Solution is to move the property down to both D and E, then I can do the query I want and get on with the rest of my life. JDO:

Key ownerKey = KeyFactory.stringToKey(ownerKeyString); 
String queryStr = "select from " + C.class.getName() + 
                        " where owner == ownerParam && active == true"; 
Query q = pm.newQuery(queryStr); 
q.declareVariables(B.class.getName() + " ownerParam"); 
myCs = (List<C>)q.execute(ownerKey); 

Here is a thread where I was discovering this. read more

I recently had to move a project off of Google App Engine. To my surprise, Google App Engines performance was just not fast enough for this project. In any case, this lead to my installation of Tomcat on OSX and integrating into Eclipse so here is how to do it:

1. Get the latest tomcat: http://tomcat.apache.org/index.html. You need to make sure you get the tar or zip file.
2. Move the download to /usr/local/.
3. Start a super shell:

$ sudo sh

4. If you downloaded the tar, you may have noticed the warning that it will not work with OSX tar command, so make sure to use gnutar which comes with OSX.

$ gnutar xzvf apache-tomcat-6.0.26.tar.gz

5. Now you can change owner ship on this new folder so you can start and stop tomcat without having to sudo, but I left it as is.
6. Create a link to the folder so that you make your life eaiser in the long term when you install newer versions:

$ ln -s apache-tomcat-6.0.26 tomcat

7. Go back to your home folder and create a new script :

#!/bin/sh
export CATALINA_HOME=/usr/local/tomcat
export JAVA_HOM=/usr
if [ "$1" == "start" ] ; then
    $CATALINA_HOME/bin/startup.sh
else
    $CATALINA_HOME/bin/shutdown.sh
fi

8. Now you can start and stop tomcat from your home folder

$ sudo ./tomcat.sh start  <== To start
$ sudo ./tomcat.sh        <== To stop

Now that Tomcat is setup, you need to configure it in Eclipse:

1. Go to Eclipse Preferences ->Server -> Runtime Environments
2. Click Add and select the right Tomcat Version
3. Put in /usr/local/tomcat for the Tomcat Installation directory (the link we created above)
4. Click Finish and you should be setup
Good Luck! read more