glu and java 8

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

glu and java 8

frenchyan
Administrator
Hi

I was wondering if anybody was running glu with java 8. If yes, have you been experiencing problems?

I am also curious about the needs to compile glu natively with java 8 (like 4.7 vs 5.0 branch for java 6 vs java 7).

Thanks
Yan
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

sodul
We are on 7 but I'll update our Dev/QA console to Java 8 and let you know in a few days. If all looks good we'll do the same with the agents (might be a little bit longer since our Ops teams will take care of that part).
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

sodul
This post was updated on .
sodul wrote
So far nothing to report about running the console with Java 8. We've had dozens of releases without a glitch.
I retract this, it turns out that I set our JVAV_HOME to 1.8 but not in pre_master_conf.sh that was still pointing to 1.7. I tried 1.8 tonight on a 5.5.x console and got a 503 service unavailable error:
2015/04/03 07:57:13.948 ERROR [ContextLoader] Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'pluginManager' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.NullPointerException: Cannot invoke method getAt() on null object
	at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:775)
	at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:424)
	at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:767)
	at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249)
	at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
	at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
	at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
	at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
	at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
	at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
	at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
	at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
	at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
	at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
	at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
	at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
	at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
	at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
	at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
	at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
	at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
	at org.eclipse.jetty.server.Server.doStart(Server.java:280)
	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
	at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1259)
	at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1182)
	at org.eclipse.jetty.start.Main.invokeMain(Main.java:473)
	at org.eclipse.jetty.start.Main.start(Main.java:615)
	at org.eclipse.jetty.start.Main.main(Main.java:96)
Caused by: java.lang.NullPointerException: Cannot invoke method getAt() on null object
	... 34 more
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

mikis
Same problem here as sodul.

Downloaded the newest 5.5.5 and tried to start the tutorial with Java8 (MacOS, Java 1.8.0_40-b27 and Groovy 2.4.1). The console-server failed with the 'Cannot invoke method getAt() on null object' stacktrace.
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

frenchyan
Administrator
In addition to your feedback, I noticed this yesterday from Oracle: Oracle Java SE Support Roadmap http://www.oracle.com/technetwork/java/javase/downloads/eol-135779.html

It means that java 7 will no longer be publicly supported at the end of this month (April 2015). Of course you can still pay Oracle to get support.

So I think I need to start working on the next version / upgrade path like for the transition to Java 7: first upgrade all libraries to latest (glu 5.6.0 still java 7), then have a glu 5.6.1 which can use java 7 or 8 and a glu 6.0.0 which is java 8 only.

So much work to just do this (with not even a new feature) :( It is going to take a while

If you have any feedback and/or comments prior to this please le me know.

Yan
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

sodul
FYI Atlassian (makers of Jira) has a policy of not supporting unsupported products. They dropped support for Java 7 this month since Oracle dropped support for it. They announced a few months ago just after Oracle announce the OEL for Java 7.
I tend to agree with this policy as I have had much more production troubles with trying to keep dependencies the same rather than staying up to date: the effort of doing a large upgrade all at once is much higher than doing continuous incremental upgrades because of a high number of variables all changing at once.
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

frenchyan
Administrator
Sorry Stephane, I am not sure I understand your last post. Are you saying you are in agreement with a java 8 upgrade? Are you saying that you would prefer continuous incremental upgrade (like for example the fact that all libraries are now "old")? Can you clarify what you meant exactly?

Thanks
Yan
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

sodul
I mean: "upgrade or die" .

I'm not very fond of the practice to stick with 'know working version from years ago' because when you are eventually forced to upgrade to something newer, the delta of changes is so large that it becomes more difficult to upgrade.

In my previous comment I meant that even big players like Atlasssian have already deprecated the use of Java 7 and no longer support it. In the same spirit I think Glu should not support versions of Java that are not officially supported: let's move to Java 8. Keep in mind that the version of Java that Glu uses has nothing to do with the version of Java that the Glu managed applications use, or at least it should not.
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

frenchyan
Administrator
As you may have noticed, glu now supports Java 8.

I do understand the "upgrade or die" mantra, that being said I also want to be careful as the deployment characteristics of glu are very different from other deployments... Sure the console is easy to upgrade (or Atlassian product). The agent is a total different ball game with potentially thousands of machines to upgrade.

Playing the catch up game with latest libraries would also be a full time job. There is a huge regression risk with every upgrade (see example with transition to java 7 when groovy issue triggered a memory leak in glu agent). That means that every upgrade must be fully tested and regressed and to be honest with you there is so much I can do on my laptop. And also to be honest I am not sure the gains are always that obvious with new bugs potentially introduced.

FYI, during the Java 8 transition I HAD to upgrade grails/groovy due to the exception that was reported and I also upgraded libraries as much as I could. I tried to upgrade to the latest and greatest grails (3.0 line). Invested significant amount of time using all dependencies required by this (and BTW the effort to migrate to grails 3.0 is HUGE as they have changed the framework quite drastically). One thing to know is that grails 3.0 is SO different, that EVERY plugin needs to be repackaged/upgraded to 3.0 (which in my mind is a bad decision on the grails part). And then I found the hard way that Shiro, which is used for the authentication layer, has not been upgraded (several months after...). So that was a roadblock... had to throw all the work away and stick with latest version of grails prior to 3.0, which also FYI I had NO clue at this stage whether that was even going to be fixing the issue we were seeing... so it was a total shoot in the dark... It worked but that was a big effort.

But I am more than willing to accept contributions of libraries upgrade if whoever is contributing can demonstrate that they have tested it "at large".

Yan
Reply | Threaded
Open this post in threaded view
|

Re: glu and java 8

sodul
Yes, I understand all the work involved.

To make your work a bit easier I really think we should look into adding some good CI to the Glu project. A quick search turned https://travis-ci.org as a potential 'CI for open source projects' place (and free as in beer). It will let you run against OpenJDK vs OracleJDK (6, 7, and 8) and integrates with GitHub quite nicely.

Seeing that contributors run their pull request through TravisCI first would give you confidence that the contributions did not break existing tests. And will let you know how it fares with various versions of Java automagically.