Author Archives: Jeanne Boyarsky

gradle in eclipse – egradle vs buildship

Posted on by
2

TLDR: use BuildShip rather than EGradle.

While everyone on our team uses command line git (rather than egit), most actual coding in Java happens within Eclipse. We ran Ant in Eclipse for deploying robot code and Ant at the command line for other things. I’m not sure if we will use Eclipse to run Gradle, but writing up for the team just in case!

For more on what the Gradle files mean see the main Gradle SmartDashboard post

EGradle

The first thing I did was try out the EGradle plugin. It worked, but wasn’t as smooth as BuildShip. (See below for using BuildShip).

Install EGradle

  1. Help
  2. Eclipse Marketplace
  3. EGradle
  4. Accept license and install
  5. Restart Eclipse

Modify the project you cloned from github

  1. Clone SmartDashboard if you haven’t already
  2. Edit the build.gradle file to add the eclipse profile.  You just have to add the one line and save the file: 
    project(':fakeRobot') {
  apply plugin: 'java'
  apply plugin: 'application'
  apply plugin: 'eclipse'

Import the project you cloned from github

  1. File
  2. Import
  3. EGradle > Import gradle root project with all subprojects
  4. Set Gradle root project to the repository you cloned from github

Build

  1. Right click the build.gradle file
  2. Run as > EGradle

EGradle limitations

  1. You had to edit the build.gradle for Eclipse to recognize it.
  2. EGradle doesn’t provide a way to see the build directory so you have to go to the file system. (and yes I tried changing the filters; it just didn’t work)

Trying that again with BuildShip

BuildShip is the official Eclipse.org plugin for Gradle. Wish I knew that before I started!

Install BuildShip

  1. Help
  2. Eclipse Marketplace
  3. BuildShip Gradle Integration
  4. Accept license and install
  5. Restart Eclipse

Import the project you cloned from github

  1. File
  2. Import
  3. Gradle >Existing Gradle project
  4. Set project root directory to the repository you cloned from github (Note that you don’t need to edit the build.gradle file like you had to with EGradle). It also uses the proper project name.

Build

There are multiple ways to do this. I’m showing just one way that maximizes understanding of what is going on.

  1. The Gradle Tasks view is open automatically for this project. (If not, click the project)
  2. Click SmartDashboard to expand
  3. Click build to expand
  4. Right click build (with a green icon to the left) and choose “Run Gradle Tasks”
  5. This automatically opens the Gradle Executions view which shows you what Gradle did in a nice tree. You can click on the Console view to see the actual command line output.
  6. Configure the filters so you can see the Gradle build folder
  7.  F5 to refresh – now you see the build folder.

 

The 8 Nights of Java – Night 8

Posted on by
Reply

It’s been a fun 8 Nights of Java, but alas, tonight is the final post. Java 8 added one of the most radical, most drastic changes to date, even bigger than Java 5 or Java 7: lambdas and streams! The writers of Java updated nearly every Java API to include lambda expression and stream-based methods. More than the API changes, though, they present a new paradigm for thinking about programming. The closest thing to a lambda expression prior to Java 8 was an anonymous inner class, and it a lot of ways they are similar, but the syntax and usability of lambda expressions is unmatched.

We hope everyone had a wonderful holiday season and we hope that you have a Happy New Year! Don’t forget, we have a brand new OCA/OCP 8 book coming out in March 2017. Order yours now on Amazon.com!

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 8 Notable Features

Oracle released Java 8 on March 18, 2014. If you’ve read the previous nights in this series, you might be wondering what the codename of Java 8 was. Oracle decided not to use one. Luckily, our friends at the Javaranch had some ideas. We like “Cuddles” ourselves.

Key new functionality included:

  • Functional interfaces
  • Lambda expressions
  • Streams
  • New date/time library
  • Project Nashorn

From Jeanne:

Streams and lambdas are one of my favorite additions to the language of all time. They make it easy to write expressive code. I haven’t needed the benefits of multi-core parallelization much yet, but it is nice to know it is there. Even without that, I find my stream based code to be shorter and easy to write/read. It took me a little while to get fluent but I went through that with Groovy before Java so I was ready when it came to Java. I was the first person on my team to write a Java 8 program for work. I commented almost every line so it could be used as a teaching example. That was fun!

The date/time library is also cool. I like that it is expressive and has so much more functionality than the Calendar API. Third time for a date API really was the charm. I just wish they retrofitted it to work directly with more libraries like JDBC. Then there’s Nashorn. A JavaScript console was a good idea, but I don’t think this one is it.

From Scott:

Two things I love about lambda expressions and streams in Java 8. First, they found a way to build functional programming into Java, by using functional interfaces. While the signature for some of the built-in functional interfaces can be… hard to read… using or creating lambda expressions rarely requires understanding the signature. That’s what is so cool about what they did. They added this conversion of lambda expressions to functional interfaces to anonymous inner classes, but from a developers perspective, all we have to know how to do is write a simple one-line lambda expression! Very cool they way they added this on without breaking the language.

The second thing I love is they included parallel streams in the very first version! It’s so awesome to be able to have built-in easy support for concurrency without having to create/manage/shutdown an executor service. One feature request for Java 9? I *really* would prefer a way to set the number of threads in a parallel stream, such as stream.parallel(10) for 10 threads. Currently, it’s controlled by the JVM based on the number of threads on the computer and unable to be changed by a developer. Here’s hoping they add it to a future version of Java!

There’s still so much more to love about Java 8! As I was saying on Night 7, Java 7 improved the Concurrency API while introducing NIO.2, but both became even more powerful in Java 8. Creating Runnable and Callable instances using anonymous inner classes was already common prior to Java 8, but it was at times verbose. You had to create a class definition, override a method, set up a generic return type for Callable, etc. While not difficult to do, it did take up multiple lines of bloated code, copied over and over again for each task. Lambda expressions fit perfectly in the Concurrency API, better than any other API (with the possible exception of Collections), in that it allowed developers to submit tasks to a thread executor in a single, simple line of code using a lambda expression. In other words, they made Concurrency, one of the arguably most difficult spaces for developers to work in, much easier to understand and implement.

The 8 Nights of Java – Night 6

Posted on by
Reply

Continuing on our 8 Nights of Java series, we move on to Java 6. Java 6 was about making Java “more”. As a result, a lot of the changes were important, but didn’t affect a developers day-to-day tasks. For example, annotations affected tool and library developers but were mostly unused for regular developers. Java 6 was initially released by Sun Microsystems, and later taken over by Oracle as part of the acquisition. This was also the last version of Java in which the Professional certification (SCJP renamed to OCP) could be completed with a single exam. Starting with Java 7 and continuing in Java 8, two exams are required to obtain an OCP certification.

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 6 Notable Features
Sun released Java 6 (codename Mustang) on December 11, 2006. Notice they dropped “.0” from the version number, going from Java 5.0 to 6? This would be the last version of Java released by Sun, with Oracle taking over the Java 6 updates in 2010. Of all the versions of Java, version 6 was out there the longest, with 5 years (and 131 updates) before the release of Java 7.  Key new functionality included:

  • Renaming J2SE to Java SE
  • Common annotations support
  • JavaScript Rhino support
  • Performance improvements
  • JDBC 4.0

From Jeanne:

I have no memories of Java 6. I remember using it. While it was nice to finally ditch the “2” from the name of J2SE, I can’t think of a single thing that was new in it that I cared about. That said, the commons annotations support was a big deal. It let libraries like JUnit and Spring use custom annotations to be more expressive and easy to use. I do appreciate the feature and know it came from language updates. But since I used it when the libraries came out rather than when Java 6 came out, I don’t intuitively think of it as a Java 6 feature.

This does seem like a good place to reflect on the change in stewardship. We’ve been hearing about Oracle’s takeover spelling the death of Java since at least 2009. That’s right. The worries started even before Oracle acquired Sun. The rumors are still with us and stronger. They’ve moved more to the Java EE space more than in the core Java space. Oracle did rename the certifications from things like SCEA (Sun Certified Enterprise Architect) to OCEA (Oracle Certified Enterprise Architect). No surprise there. They also controversially added a requirement to take a class to a few certs to be more consistent with the database cert. Luckily, this requirement does not exist for the certifications Scott and I have written books about!

From Scott:

I have to agree with Jeanne on this. While Java 6 was a maturing release, with lots of new methods and features built on top of existing APIs, it paled in comparison to the Java 5.0 release in terms of scope. In other words, there wasn’t a compelling reason to go out and install Java 6 on all of your servers and desktops. As Jeanne started, the biggest change was really about Oracle’s acquisition of Java and handover of the platform and staff (remember Sun employees overnight became Oracle employees!). Java 7 was delayed almost 5 years because of this transition. As I said on Night 1, people have been predicting the death of Java since the first year it existed and the acquisition by Oracle was no different. While Oracle did make changes to Java, especially to the certifications, it’s fair to say they kept most things intact, helping Java to continue to thrive today.

One other important note. Java 6 had the most number of updates and patches, in part because so many “zero day” bugs were discovered. I’m not sure this was a deficit in Java, so much as this was Java spreading as a server platform across the web. Any server technology must be constantly kept up-to-date, as exploits are discovered all the time in the wild. As of April 2015, Oracle no longer publicly supports Java 6. Any servers running Java 6 must be updated and any that are not are prime targets for hackers.