Sunday, April 23, 2017

Setting multiple Java JRE/ JDK on MacOSX using brew, cask and jenv

Yesterday at the Java9, Jigsaw HackTheTower event, I realized that I need to step up my game and improve my existing mechanism on maintaining several different JDK's on my machines.

I used to manually download the jdk's, or install them using brew cask, and I would set 'bash alias' on my `~/bash_profile` to switch between different 'JAVA_HOME' etc etc.

I am already using brew & brew cask (official site here) & i recently started using 'CakeBrew'. So in order to install 3 different versions of java all you need to do is :

Step 1: Install JDK's using brew and  brew cask

brew cask install caskroom/versions/java6
brew cask install caskroom/versions/java7  
brew install java

After the installation check the following folder, you are expected to see the 3 different JDK folders.

cd /Library/Java/JavaVirtualMachines

Step 2: Install jenv

brew install jenv 

Step 3: Add the 3 available JDK's to jenv

jenv add /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home
jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home

Step 4: Check if jenv has registered the different jdk's

jenv versions

Step 5: Use jenv to set up the JDK env either globally or the current shell

--Setting java 1.8 for the shell
jenv shell 1.8
java -version 
jenv shell 1.7
java -version 
-- this sets it globally
jenv global 1.8
java -version 

Step 6: Add jenv to .bash_profile

eval "$(jenv init -)"

All done! You can switch different versions easily!

Watch out for now

  • You can install a pre-release of java9 using ' brew cask install caskroom/versions/java9-beta' but it seems that the way it is installed and the paths are not compatible with what jenv expects so you can not jenv add 1.9 (for the time being) 

Saturday, April 22, 2017

Java 9 Module System (Jigsaw) @ LJC's HackTheTower

Today we spent half a day, on our first HackTheTower event. Members of London's Java User Group (aka LJC),  gathered on the 26th floor of  'SalesForceTower'  (aka Heron Tower) at the City of London, invited by
to talk and learn about one Project Jigsaw, Java 9's modular-isation system. The event was well organized, and coding from above, viewing London's town center and the rest of the skyscrapers is really a thing!

The event was splint into 3 sections, where we were given exercises and material to cover around Jigsaw (small examples, similar to the one you will find on OpenJDK's pages) and then we could talk about or raise any concerns or missing things that we felt the should be fed back to the OpenJDK / Oracle devs, evolving Jigsaw.

You can find all the material / slides & our feedback on the following links:

 How do I feel about Jigsaw

I have to be honest, it seems that Jigsaw is my least favorite feature of Java 9. It was one of the reasons I joined the event. Not because it is a bad feature as such or the actual needs behind it, especially the one to make the core of the JDK/JRE modular or more IoT friendly. But because of the potential side effects on the existing Java ecosystem and applications. It is really the first time that I eventually I did not trial personal or work related projects with pre-releases, to see if they work with the new version of Java, because of the various problems (and I still have).

Were we missing Jigsaw like functionality? Yes. Did we have similar attempts? Yes we had, OSGi (was covering many parts), then years after JBoss Modules. I always found OSGi a nice idea, but too complicated . I had the chance to work with JBoss Modules, I liked it but this was only on a product that was built on top of it, the Wildfly Application server, so it was like a full-filled prophecy, so I never tried to applied on my project or any of the projects I worked for.

Today I was kind of frustrated seeing examples of Java code, accompanied with  bash scripts calling jdk specific command like tools. Javac with flags, jlink or jmod, Jars that are not jars, but they behave like jars. I felt like my first Java day's at the uni, where eventually Ant was still NOT a thing, and java was compiled with bespoke make file mechanisms etc. Do I like all this new tooling? No. Why? Because as an application/ business developer I rely on abstracted build tools and I expect they do the heavy lifting for me, i dont want to go back editing module- descriptors or fighting existing build tools where the Plain Old Jar is the king, with the new king the Module and vice versa.

So, currently I don't see a clear path for existing, mainstream Java Built tools. Yes work is underway, for example the Maven Compiler Plugin version 3.6.1 is Jigsaw compatible. By the way it seems that currently you need to map and package your JigSaw modules as Maven Modules, so that you can have the best of 2 world. I don't know this whole thing confuses me a bit, unless I miss something.

It seems that we are heading towards a Java ecosystem, at least for Java 9, where either you play with Jigsaw's rules and you start building something new from scratch, introducing modules & project structure compatible with Jigsaw semantics or you kind of close your eyes,  add the 'kill switch' or your java executions  and continue your quest towards the new and the old world.

Last but not least, I can not ignore, the increasing number of worries and posts from application server, library developers on the potential problems Java9 might introduce to their libraries. I guess all java application developers would like to use Java 9, but if it is like going to introduce 1000 new issues because Spring Class-loading is not working any more, or CDI or any sub-module of their application server is going to break this is kind of unnecessary noise. 

So for the time being I am skeptic about it, but I will continue to invest time and learn more or experiment with it, most probably not using my SpringBoot or WildflySwarm projects but rather simple. 

I really liked the following articles

Thursday, April 20, 2017

A small docker image with kubectl,helm, envsubst based on Alpine

I guess lots of people will have something similar, I thought to share my small customized container.

So here, you can find a small Alpine Based container, stuffed with
  1. bash
  2. curl
  3. envsubst
  4. kubectl
  5. helm (client)
It is mostly used as a `gitlab` runner, in order to `talk` to kubernetes clusters (injected with the appropriate kube-configs).

You can just run /pull it  like

docker pull javapapo/kube-runner:2
docker run -it javapapo/kube-runner:2

 Using different tags e.g 1, 2 etc, I just upgrade some of the versions of the above utils.

Currently I feature tag `1` and `2`.

No rocket science, maybe some people will find it usefull on their GitLab/Circle/BitBucket runner use cases.

ps) github repo is here

Monday, April 10, 2017

Awesome list of MacOSX utils

At some point, I used to have a similar list. For a couple of years, I used to come back to that post and update it. I think this one, is far better and much more flexible! In my spare time today, I started going through the sections and trying out stuff! It is kind of relaxing lol!

Already installed CakeBrew (i love brew/cask), trying out 'Tower' I think I am going to buy it, or giving 'Black Screen' a chance.

Give this guy a 'Github' star!

ps) I need to do a come back on my beloved blog - as a friend suggested yesterday.