1. 13
  1.  

  2. 6

    We are still on 8 where I work. Are others here adopting new versions more quickly?

    1. 4

      nah, we’re also still on 8.

      1. 2

        We are moving to 11 right now

        1. 1

          Which version are you currently using? Are there any specific features or bug fixes that are prompting the migration?

          Edit: After upgrading to today’s (2019-03) release of Eclipse, I discovered two things: (1) The latest version of Eclipse only supports Java up to version 11; (2) Java 11 removed support for JAXB and apparently the activation framework as well. I am not ready to track down all of these external libraries yet, as it would cause my development environment (i.e. Java 12 (no JAXB or activation framework); limited to Java 11 by Eclipse) to get out of sync with our test and production environments (currently limited to Java 8 with JAXB and activation framework). We will need to hold off on Java 12 until it is specifically supported on Amazon Linux.

          1. 2

            We’re running 10 right now.

            Not that I know of, I have a coworker that works with in the infra layer on the JVM side of things (in the same team) so I don’t have deeper insights except that it works with our stack and build systems.

        2. 2

          I believe we’re rolling out 11 once we do our June release, but not yet.

          1. 1

            My Java upgrades have always been in June as well, to coincide with the Eclipse release schedule (like clockwork for 15 years, there has been a new major release every June from 2004-2018). However, a few months ago Eclipse changed their Simultaneous Release schedule, and this has thrown my usual upgrade process into chaos. I’m still using Eclipse Photon (4.8, June 2018), and I’m not even certain if this is the current version or not.

            Not to presume you’re using Eclipse, but now I’m really curious if this release cadence change is affecting anyone else’s shop.

            1. 2

              Eclipse actually released its now-quarterly release today, version 4.11 aka “2019-03”. The previous release 4.10 was labeled “2018-12”.

              1. 2

                Thanks for the heads-up. I see (after a little more reading), they basically re-named/re-numbered the service releases as major versions. Incidentally, I see that Eclipse is not yet advertising Java 12 build support.

                In case it helps anyone else, I just did (for us, an “out of band”; we’ve never jumped two major versions) update of all of our development workstations. Aside from the Windows and Linux installers failing (resorted to manual install via zip archive), the Subclipse plug-in installed without problems but IvyDE failed to install unless Contact all update sites during install to find required software was unchecked. Overall, less painful than normal for an Eclipse upgrade.

          2. 1

            My team’s on 11, but we use Clojure so we’re not affected by majority of the changes in the JDK.

          3. 5

            nope no plans for 12 in sight. will be migrating from 8 to 11 now, however.

            FreeBSD just received 11 a few days ago, big thanks to Kurt Miller http://freebsd.1045724.x6.nabble.com/JDK-11-update-td6318964.html So that’s the reason for us to kick off the migrate.

            Hope OpenBSD will follow soon with 11 support.

            Android side of the house, still Google’s ‘J++’ version of java (:-) ). So sharing code between mobile and backend will require, still, least common denominator (now between 7 and 11)

            edit: sorry I was replying to fs111, not to top level

            1. 1

              I’m still on Java 8 (OpenJDK 1.8.0, Amazon Linux package) since 2012. This has been incredibly stable for our development, test and production environments (PostgreSQL, Tomcat 8.5, Apache HTTPD 2.4 are actively maintained packages from Amazon). Upgrades and patches have been so simple: sudo yum update has never broken our production environment, nor has it ever broken our server configuration.

              However, I intend to migrate to Java 12 in my development environment as soon as possible, because it fixes an XML UTF-8 mutlti-character processing bug that is interfering with my current project. The bug itself likely dates back to Java 1.4, the advent of org.w3c.dom, which would put it at February 6, 2002. The fix will not be back-ported to pre-Java 12 JVMs.

              Currently, Amazon Linux instances only provide packages for Java 1.6, 1.7 and 1.8, so I’m in a bit of a holding pattern for my test and production servers. So, in the short term, I will upgrade to Java 12 in my development environment but still target Java 1.8 in my build processes.

              Amazon Linux 2 instances apparently also support Java 11, but IIRC they don’t provide Tomcat 8.5 packages, so I’ve got some additional decisions to make once they start providing Java 12 support.

              Edit: After re-investigating the Tomcat 8.5 support on Amazon Linux 2, I found that it is available only by installing via amazon-linux-extras install tomcat8.5. At best, this will allow me to migrate to Java 11. Once Java 12 is available on Amazon Linux 2, I’ll plan a major upgrade.

              1. 2

                Does Amazon Coretto figure into your plans at all since you’re working in AWS space?

                1. 2

                  Great question, this is the first I’ve heard of it. I use the Oracle Java SE for my development environment, and the Amazon OpenJDK for test and production. I’m not certain if Corretto is the same as the java-1.8.0-openjdk.x86_64 package I use on EC2. A yum list *corretto* turns up nothing on those instances.

                  Edit: As a follow-up, I’m going to stick with the Oracle JDK for development (closer to the source) and OpenJDK on EC2 instances (actively maintained, easy to update). I like the idea of having another alternative, but since Corretto is based on OpenJDK, that means it is two derivatives away from the source. I’d have to hear a good argument for its use before I seriously considered using it.