You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Hugo Trippaers <hu...@trippaers.nl> on 2013/09/18 14:09:39 UTC
Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
Hey all,
Sorry for the threadomancy, but the discussion have become relevant again with the current issues with the libvirt library. Of course this could also be solved by updating the libvirt library with a jdk6 version. Still it might be good to revisit this topic.
It appears not to be possible to switch code style to 1.7 and produce a 1.6 compatible binary. I remember this working with olders versions, but didn't dig to much into this.
So the new question in this thread will be, should we switch CloudStack to jdk 1.7?
Cheers,
Hugo
On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
>> All,
>>
>> I am +1 for Java7. However, I would like to propose ridding
>> ourselves of Tomcat entirely and embedding a network stack such as
>> Netty (http://netty.io) with a servlet bridge. We have one JSP in
>> the system that generates JSON resources. It could be easily
>> eliminated with a simple servlet that generates JSON from a
>> ResourceBundle. Outside of this JSP. I don't see any other
>> requirements for a JEE container besides hosting a servlet. We
>> would gain a far simpler, self-contained deployment model (a single
>> jar). Additionally, we would gain greater control of the startup
>> and shutdown lifecycle, as well as, threading dynamics. If there is
>> interest in this approach, I have thoughts on how to achieve this
>> embedding and create a lightweight daemon framework that could be
>> used for all CloudStack daemons.
>>
>> As an aside, I also think we should replace our hand-rolled NIO code
>> with Netty as well.
>>
>
> John - could you break this and other thoughts down a little more in
> what's involved? Perhaps into its own thread. I don't know Netty. And
> my J2EE is shaky at best.
>
> It's been a previous wish on this list to have the packaging of
> cloudstack into a single easily deployable war instead of all the
> complicated packaging we do. So I'd like to hear more of that and
> other issues you describe.
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
Posted by Darren Shepherd <da...@gmail.com>.
I know rhel6 has jdk6 as the default and jdk7 is also available. Seems
silly to target 1.7 for a redhat project. If libvirt can just target 1.6 I
think that would be ideal and then we can just not change anything on our
side. Somebody can correct me if I'm wrong, but I see the vast majority of
projects targeting 1.6 unless they really need to use a 1.7 API, which
isn't all that much. Java 8 is going to be the next real jump that most
projects move to as, similar to 1.5, it has real language features people
want.
Darren
On Wed, Sep 18, 2013 at 4:02 PM, Wido den Hollander <wi...@widodh.nl> wrote:
>
>
> On 09/18/2013 06:51 PM, Darren Shepherd wrote:
>
>> I'd be relatively opposed to switching everything to jdk7. Java 6 is the
>> current lowest common denominator and using java 7 at the moment will just
>> alienate somebody I don't know the back story. Is libvirt compiled for
>> jdk7? I'd be perfectly fine with compiling just the KVM driver with jdk7
>> as any distro that has a usable KVM implementation also has java 7.
>>
>>
> A new version of libvirt-java was released, but the RedHat guys compiled
> it with jdk 7.
>
> I already got a patch in at libvirt-java to set the target version to 1.6:
> http://www.libvirt.org/git/?p=**libvirt-java.git;a=commitdiff;**h=**
> 26efdef08b0d34b75fcd5930b6510d**acc14f6637<http://www.libvirt.org/git/?p=libvirt-java.git;a=commitdiff;h=26efdef08b0d34b75fcd5930b6510dacc14f6637>
>
> I hope to get the 0.5.1 release soon which is 1.6 compatible.
>
>
> So here is what I propose (which I think is what is already being
>> proposed,
>> but I'm just being explicit). We keep the maven settings to keep building
>> 1.6 byte code. Only the KVM driver do we set it to 1.7. This means that
>> we would then have to switch to using JDK7 for jenkins, eclipse, mvn cli,
>> etc. As the majority of development is done in eclipse (i think), eclipse
>> still sets up the projects to compile against the JRE 6 library (except
>> KVM
>> will be JRE 7), so that will help prevent people from accidentally using a
>> JRE7 API in a 1.6 byte code format.
>>
>>
> As far as I know both RHEL/CentOS 6 and Ubuntu 12.04 have JRE 7 in their
> repos, so it's no problem on the packaging side if we target those two
> platforms.
>
> Wido
>
>
> And as a totally random note, OpenJDK7 on CentOS is way faster than
>> OpenJDK6 on CentOS. Regardless of whatever we compile against, everybody
>> should try use Java 7 at runtime.
>>
>> Darren
>>
>>
>> On Wed, Sep 18, 2013 at 9:29 AM, Alex Huang <Al...@citrix.com>
>> wrote:
>>
>> I don't have much problem with switching to jdk1.7. My eclipse is
>>> running
>>> with jdk1.7 as the builder and it can't find any problems in cs code.
>>> The
>>> main question I think will come from the Linux variants. Are all of them
>>> shipping with jdk1.7 now?
>>>
>>> --Alex
>>>
>>> -----Original Message-----
>>>> From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
>>>> Sent: Wednesday, September 18, 2013 5:10 AM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
>>>>
>>>> Hey all,
>>>>
>>>> Sorry for the threadomancy, but the discussion have become relevant
>>>> again
>>>> with the current issues with the libvirt library. Of course this could
>>>>
>>> also be
>>>
>>>> solved by updating the libvirt library with a jdk6 version. Still it
>>>>
>>> might be good
>>>
>>>> to revisit this topic.
>>>>
>>>> It appears not to be possible to switch code style to 1.7 and produce a
>>>>
>>> 1.6
>>>
>>>> compatible binary. I remember this working with olders versions, but
>>>>
>>> didn't
>>>
>>>> dig to much into this.
>>>>
>>>> So the new question in this thread will be, should we switch CloudStack
>>>>
>>> to
>>>
>>>> jdk 1.7?
>>>>
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>> On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>>>>
>>>> On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I am +1 for Java7. However, I would like to propose ridding
>>>>>> ourselves of Tomcat entirely and embedding a network stack such as
>>>>>> Netty (http://netty.io) with a servlet bridge. We have one JSP in
>>>>>> the system that generates JSON resources. It could be easily
>>>>>> eliminated with a simple servlet that generates JSON from a
>>>>>> ResourceBundle. Outside of this JSP. I don't see any other
>>>>>> requirements for a JEE container besides hosting a servlet. We would
>>>>>> gain a far simpler, self-contained deployment model (a single jar).
>>>>>> Additionally, we would gain greater control of the startup and
>>>>>> shutdown lifecycle, as well as, threading dynamics. If there is
>>>>>> interest in this approach, I have thoughts on how to achieve this
>>>>>> embedding and create a lightweight daemon framework that could be
>>>>>> used for all CloudStack daemons.
>>>>>>
>>>>>> As an aside, I also think we should replace our hand-rolled NIO code
>>>>>> with Netty as well.
>>>>>>
>>>>>>
>>>>> John - could you break this and other thoughts down a little more in
>>>>> what's involved? Perhaps into its own thread. I don't know Netty. And
>>>>> my J2EE is shaky at best.
>>>>>
>>>>> It's been a previous wish on this list to have the packaging of
>>>>> cloudstack into a single easily deployable war instead of all the
>>>>> complicated packaging we do. So I'd like to hear more of that and
>>>>> other issues you describe.
>>>>>
>>>>> --
>>>>> Prasanna.,
>>>>>
>>>>> ------------------------
>>>>> Powered by BigRock.com
>>>>>
>>>>>
>>>
>>>
>>
Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
Posted by Wido den Hollander <wi...@widodh.nl>.
On 09/18/2013 06:51 PM, Darren Shepherd wrote:
> I'd be relatively opposed to switching everything to jdk7. Java 6 is the
> current lowest common denominator and using java 7 at the moment will just
> alienate somebody I don't know the back story. Is libvirt compiled for
> jdk7? I'd be perfectly fine with compiling just the KVM driver with jdk7
> as any distro that has a usable KVM implementation also has java 7.
>
A new version of libvirt-java was released, but the RedHat guys compiled
it with jdk 7.
I already got a patch in at libvirt-java to set the target version to
1.6:
http://www.libvirt.org/git/?p=libvirt-java.git;a=commitdiff;h=26efdef08b0d34b75fcd5930b6510dacc14f6637
I hope to get the 0.5.1 release soon which is 1.6 compatible.
> So here is what I propose (which I think is what is already being proposed,
> but I'm just being explicit). We keep the maven settings to keep building
> 1.6 byte code. Only the KVM driver do we set it to 1.7. This means that
> we would then have to switch to using JDK7 for jenkins, eclipse, mvn cli,
> etc. As the majority of development is done in eclipse (i think), eclipse
> still sets up the projects to compile against the JRE 6 library (except KVM
> will be JRE 7), so that will help prevent people from accidentally using a
> JRE7 API in a 1.6 byte code format.
>
As far as I know both RHEL/CentOS 6 and Ubuntu 12.04 have JRE 7 in their
repos, so it's no problem on the packaging side if we target those two
platforms.
Wido
> And as a totally random note, OpenJDK7 on CentOS is way faster than
> OpenJDK6 on CentOS. Regardless of whatever we compile against, everybody
> should try use Java 7 at runtime.
>
> Darren
>
>
> On Wed, Sep 18, 2013 at 9:29 AM, Alex Huang <Al...@citrix.com> wrote:
>
>> I don't have much problem with switching to jdk1.7. My eclipse is running
>> with jdk1.7 as the builder and it can't find any problems in cs code. The
>> main question I think will come from the Linux variants. Are all of them
>> shipping with jdk1.7 now?
>>
>> --Alex
>>
>>> -----Original Message-----
>>> From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
>>> Sent: Wednesday, September 18, 2013 5:10 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
>>>
>>> Hey all,
>>>
>>> Sorry for the threadomancy, but the discussion have become relevant again
>>> with the current issues with the libvirt library. Of course this could
>> also be
>>> solved by updating the libvirt library with a jdk6 version. Still it
>> might be good
>>> to revisit this topic.
>>>
>>> It appears not to be possible to switch code style to 1.7 and produce a
>> 1.6
>>> compatible binary. I remember this working with olders versions, but
>> didn't
>>> dig to much into this.
>>>
>>> So the new question in this thread will be, should we switch CloudStack
>> to
>>> jdk 1.7?
>>>
>>> Cheers,
>>>
>>> Hugo
>>>
>>> On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>>>
>>>> On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
>>>>> All,
>>>>>
>>>>> I am +1 for Java7. However, I would like to propose ridding
>>>>> ourselves of Tomcat entirely and embedding a network stack such as
>>>>> Netty (http://netty.io) with a servlet bridge. We have one JSP in
>>>>> the system that generates JSON resources. It could be easily
>>>>> eliminated with a simple servlet that generates JSON from a
>>>>> ResourceBundle. Outside of this JSP. I don't see any other
>>>>> requirements for a JEE container besides hosting a servlet. We would
>>>>> gain a far simpler, self-contained deployment model (a single jar).
>>>>> Additionally, we would gain greater control of the startup and
>>>>> shutdown lifecycle, as well as, threading dynamics. If there is
>>>>> interest in this approach, I have thoughts on how to achieve this
>>>>> embedding and create a lightweight daemon framework that could be
>>>>> used for all CloudStack daemons.
>>>>>
>>>>> As an aside, I also think we should replace our hand-rolled NIO code
>>>>> with Netty as well.
>>>>>
>>>>
>>>> John - could you break this and other thoughts down a little more in
>>>> what's involved? Perhaps into its own thread. I don't know Netty. And
>>>> my J2EE is shaky at best.
>>>>
>>>> It's been a previous wish on this list to have the packaging of
>>>> cloudstack into a single easily deployable war instead of all the
>>>> complicated packaging we do. So I'd like to hear more of that and
>>>> other issues you describe.
>>>>
>>>> --
>>>> Prasanna.,
>>>>
>>>> ------------------------
>>>> Powered by BigRock.com
>>>>
>>
>>
>
Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
Posted by Darren Shepherd <da...@gmail.com>.
I'd be relatively opposed to switching everything to jdk7. Java 6 is the
current lowest common denominator and using java 7 at the moment will just
alienate somebody I don't know the back story. Is libvirt compiled for
jdk7? I'd be perfectly fine with compiling just the KVM driver with jdk7
as any distro that has a usable KVM implementation also has java 7.
So here is what I propose (which I think is what is already being proposed,
but I'm just being explicit). We keep the maven settings to keep building
1.6 byte code. Only the KVM driver do we set it to 1.7. This means that
we would then have to switch to using JDK7 for jenkins, eclipse, mvn cli,
etc. As the majority of development is done in eclipse (i think), eclipse
still sets up the projects to compile against the JRE 6 library (except KVM
will be JRE 7), so that will help prevent people from accidentally using a
JRE7 API in a 1.6 byte code format.
And as a totally random note, OpenJDK7 on CentOS is way faster than
OpenJDK6 on CentOS. Regardless of whatever we compile against, everybody
should try use Java 7 at runtime.
Darren
On Wed, Sep 18, 2013 at 9:29 AM, Alex Huang <Al...@citrix.com> wrote:
> I don't have much problem with switching to jdk1.7. My eclipse is running
> with jdk1.7 as the builder and it can't find any problems in cs code. The
> main question I think will come from the Linux variants. Are all of them
> shipping with jdk1.7 now?
>
> --Alex
>
> > -----Original Message-----
> > From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
> > Sent: Wednesday, September 18, 2013 5:10 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
> >
> > Hey all,
> >
> > Sorry for the threadomancy, but the discussion have become relevant again
> > with the current issues with the libvirt library. Of course this could
> also be
> > solved by updating the libvirt library with a jdk6 version. Still it
> might be good
> > to revisit this topic.
> >
> > It appears not to be possible to switch code style to 1.7 and produce a
> 1.6
> > compatible binary. I remember this working with olders versions, but
> didn't
> > dig to much into this.
> >
> > So the new question in this thread will be, should we switch CloudStack
> to
> > jdk 1.7?
> >
> > Cheers,
> >
> > Hugo
> >
> > On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <ts...@apache.org> wrote:
> >
> > > On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
> > >> All,
> > >>
> > >> I am +1 for Java7. However, I would like to propose ridding
> > >> ourselves of Tomcat entirely and embedding a network stack such as
> > >> Netty (http://netty.io) with a servlet bridge. We have one JSP in
> > >> the system that generates JSON resources. It could be easily
> > >> eliminated with a simple servlet that generates JSON from a
> > >> ResourceBundle. Outside of this JSP. I don't see any other
> > >> requirements for a JEE container besides hosting a servlet. We would
> > >> gain a far simpler, self-contained deployment model (a single jar).
> > >> Additionally, we would gain greater control of the startup and
> > >> shutdown lifecycle, as well as, threading dynamics. If there is
> > >> interest in this approach, I have thoughts on how to achieve this
> > >> embedding and create a lightweight daemon framework that could be
> > >> used for all CloudStack daemons.
> > >>
> > >> As an aside, I also think we should replace our hand-rolled NIO code
> > >> with Netty as well.
> > >>
> > >
> > > John - could you break this and other thoughts down a little more in
> > > what's involved? Perhaps into its own thread. I don't know Netty. And
> > > my J2EE is shaky at best.
> > >
> > > It's been a previous wish on this list to have the packaging of
> > > cloudstack into a single easily deployable war instead of all the
> > > complicated packaging we do. So I'd like to hear more of that and
> > > other issues you describe.
> > >
> > > --
> > > Prasanna.,
> > >
> > > ------------------------
> > > Powered by BigRock.com
> > >
>
>
RE: [DISCUSS] Java 7, tomcat 7 and further upgrades
Posted by Alex Huang <Al...@citrix.com>.
I don't have much problem with switching to jdk1.7. My eclipse is running with jdk1.7 as the builder and it can't find any problems in cs code. The main question I think will come from the Linux variants. Are all of them shipping with jdk1.7 now?
--Alex
> -----Original Message-----
> From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Wednesday, September 18, 2013 5:10 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Java 7, tomcat 7 and further upgrades
>
> Hey all,
>
> Sorry for the threadomancy, but the discussion have become relevant again
> with the current issues with the libvirt library. Of course this could also be
> solved by updating the libvirt library with a jdk6 version. Still it might be good
> to revisit this topic.
>
> It appears not to be possible to switch code style to 1.7 and produce a 1.6
> compatible binary. I remember this working with olders versions, but didn't
> dig to much into this.
>
> So the new question in this thread will be, should we switch CloudStack to
> jdk 1.7?
>
> Cheers,
>
> Hugo
>
> On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
> >> All,
> >>
> >> I am +1 for Java7. However, I would like to propose ridding
> >> ourselves of Tomcat entirely and embedding a network stack such as
> >> Netty (http://netty.io) with a servlet bridge. We have one JSP in
> >> the system that generates JSON resources. It could be easily
> >> eliminated with a simple servlet that generates JSON from a
> >> ResourceBundle. Outside of this JSP. I don't see any other
> >> requirements for a JEE container besides hosting a servlet. We would
> >> gain a far simpler, self-contained deployment model (a single jar).
> >> Additionally, we would gain greater control of the startup and
> >> shutdown lifecycle, as well as, threading dynamics. If there is
> >> interest in this approach, I have thoughts on how to achieve this
> >> embedding and create a lightweight daemon framework that could be
> >> used for all CloudStack daemons.
> >>
> >> As an aside, I also think we should replace our hand-rolled NIO code
> >> with Netty as well.
> >>
> >
> > John - could you break this and other thoughts down a little more in
> > what's involved? Perhaps into its own thread. I don't know Netty. And
> > my J2EE is shaky at best.
> >
> > It's been a previous wish on this list to have the packaging of
> > cloudstack into a single easily deployable war instead of all the
> > complicated packaging we do. So I'd like to hear more of that and
> > other issues you describe.
> >
> > --
> > Prasanna.,
> >
> > ------------------------
> > Powered by BigRock.com
> >