You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Uwe Schindler <uw...@thetaphi.de> on 2014/03/08 17:17:23 UTC
[VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Hi all,
Java 8 will get released (hopefully, but I trust the release plan!) on March 18, 2014. Because of this, lots of developers will move to Java 8, too. This makes maintaining 3 versions for developing Lucene 4.x not easy anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for your Windows Explorer - or similar stuff in Linux/Mäc).
We already discussed in another thread about moving to release trunk as 5.0, but people disagreed and preferred to release 4.8 with a minimum of Java 7. This is perfectly fine, as nobody should run Lucene or Solr on an unsupported platform anymore. If they upgrade to 4.8, they should also upgrade their infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as soon as it is released (in 10 days).
Now the good things: We don't need to support JRockit anymore, no need to support IBM J9 in trunk (unless they release a new version based on Java 8).
So the vote here is about:
[.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
[.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
You can vote separately for both items!
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Yonik,
> Excuse me? I assume that's aimed at me?
No, that was not aimed at you. It was a general comment. There are many examples of companies /users that fork trunk. Lucid Imagination was one of them (the product LucidWorks was initially based on trunk, as far as I remember). Also P.S. has a forked Solr distribution. And I think HelioSearch, too.
So it was not against you. It was just a comment, that those people should not fork trunk and release it, but instead fork branch_4x and do their releases from there. Trunk is playground.
> Your'e insinuating I voted against moving to Java8 right now because of my
> corporate interests?
The whole discussion with Java 8 was clearly about corporate interests, every reply had some wording around "company" in it. Trunk is playground and we are free to use Java 8 there, without taking care of users. Trunk is for developers, not the users. If we have a feature for release, we may backport to 4.x (at the moment). Unfortunately we do the backport quite often too early, releasing unbaked APIs.
> I'd appreciate it if you didn't try to disparage my character every time we
> happen to disagree.
Sorry, wasn't my intention. I like you very much as a character, we met several times and had great discussions. I have no personal problem with you.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Yonik Seeley <yo...@heliosearch.com>.
On Mon, Mar 10, 2014 at 9:00 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> I agree with you: "trunk" is our development branch, I see no problem with making it Java 8 only. From the other issue, we have no important news to actually release this as 5.0 soon, so we can for sure play with it for long time. To me it looks like some of our committers have forks off trunk they want to sell to their customers.
Excuse me? I assume that's aimed at me?
Your'e insinuating I voted against moving to Java8 right now because
of my corporate interests?
I'd appreciate it if you didn't try to disparage my character every
time we happen to disagree.
-Yonik
http://heliosearch.org - native off-heap filters and fieldcache for solr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
Solr/Lucene 4.8 -> Java 7
+1
I'm not too sure about moving trunk to java 8 . Let's keep it at java 7 and
make a call when we are closer to Lecene-Solr 5.0. Organizations move to
newer versions of java very slowly.
On Mon, Mar 10, 2014 at 6:30 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi Robert,
>
> > the vote must be held open for 72 hours. I haven't even had a chance to
> > formulate my VOTE+reasoning yet, and i dont agree with this crap here.
>
> Indeed, there is no need to hurry! I just wanted more discussions coming
> in.
> The merges I prepared already are stable and pass all tests, smokers,...
> So no problem to wait 2 more days, it is not urgent to commit my branch_4x
> checkout.
>
> As said in the thread already, I expected the reaction from our
> company-users/company-committers. I disagree, too, but it looks like more
> people are against this and that won't change anymore.
> I agree with you: "trunk" is our development branch, I see no problem with
> making it Java 8 only. From the other issue, we have no important news to
> actually release this as 5.0 soon, so we can for sure play with it for long
> time. To me it looks like some of our committers have forks off trunk they
> want to sell to their customers.
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Robert Muir [mailto:rcmuir@gmail.com]
> > Sent: Monday, March 10, 2014 1:34 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in
> trunk
> > (once officially released)
> >
> > On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de>
> > wrote:
> > > Hi,
> > >
> > > it looks like we all agree on the same:
> > >
> > > +1 for Lucene 4.x requirement on Java 7.
> > > -1 to not change trunk (keep it on Java 7,too).
> > >
> > > I will keep this vote open until this evening, but I don't expect any
> other
> > change. Indeed, there are no real technical reasons to not move.
> >
> > the vote must be held open for 72 hours. I haven't even had a chance to
> > formulate my VOTE+reasoning yet, and i dont agree with this crap here.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> > commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
-----------------------------------------------------
Noble Paul
RE: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Robert,
> the vote must be held open for 72 hours. I haven't even had a chance to
> formulate my VOTE+reasoning yet, and i dont agree with this crap here.
Indeed, there is no need to hurry! I just wanted more discussions coming in.
The merges I prepared already are stable and pass all tests, smokers,... So no problem to wait 2 more days, it is not urgent to commit my branch_4x checkout.
As said in the thread already, I expected the reaction from our company-users/company-committers. I disagree, too, but it looks like more people are against this and that won't change anymore.
I agree with you: "trunk" is our development branch, I see no problem with making it Java 8 only. From the other issue, we have no important news to actually release this as 5.0 soon, so we can for sure play with it for long time. To me it looks like some of our committers have forks off trunk they want to sell to their customers.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Robert Muir [mailto:rcmuir@gmail.com]
> Sent: Monday, March 10, 2014 1:34 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
> (once officially released)
>
> On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > Hi,
> >
> > it looks like we all agree on the same:
> >
> > +1 for Lucene 4.x requirement on Java 7.
> > -1 to not change trunk (keep it on Java 7,too).
> >
> > I will keep this vote open until this evening, but I don't expect any other
> change. Indeed, there are no real technical reasons to not move.
>
> the vote must be held open for 72 hours. I haven't even had a chance to
> formulate my VOTE+reasoning yet, and i dont agree with this crap here.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> it looks like we all agree on the same:
>
> +1 for Lucene 4.x requirement on Java 7.
> -1 to not change trunk (keep it on Java 7,too).
>
> I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
the vote must be held open for 72 hours. I haven't even had a chance
to formulate my VOTE+reasoning yet, and i dont agree with this crap
here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Mar 10, 2014 at 8:49 AM, Yonik Seeley <yo...@heliosearch.com> wrote:
>
> Also, please show respect for the opinions of others. If they happen
> to disagree with you,
> do not assume it's "crap" and driven by corporate interests.
>
No assumptions had to be made. it was explicitly worded in the VOTEs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Yonik Seeley <yo...@heliosearch.com>.
On Mon, Mar 10, 2014 at 8:44 AM, Robert Muir <rc...@gmail.com> wrote:
> When making votes like this, please do what you think is best for the
> open source project, instead of what you think is best for your
> corporation.
Also, please show respect for the opinions of others. If they happen
to disagree with you,
do not assume it's "crap" and driven by corporate interests.
-Yonik
http://heliosearch.org - native off-heap filters and fieldcache for solr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Robert Muir <rc...@gmail.com>.
On Mon, Mar 10, 2014 at 8:37 AM, Jan Høydahl <ja...@cominvent.com> wrote:
> Rob, in my view, what's best for Lucene as a project is tightly linked to what's best for its users. And the users tend do be corporate. I think users are so important that we should even consider rolling a bugfix-release from the 4.7 branch after 4.8 is released, if there is sufficient user demand for it. I hope we'll see trunk on Java8 before summer, but *today* is a tad too aggressive :)
>
Not our trunk. Trunk is *all about developers*. Users are unimportant there.
Valid reasons for not wanting to move trunk to java 8? "I'm concerned
about the stability of IDE support for java 8". "I'm worried there are
not enough best-practices/publications to prevent the codebase from
going crazy", etc
Invalid reasons for not wanting to move trunk to java 8? Corporate
policies, production policies, anything about production whatsoever.
Trunk is intentionally supposed to be separate from the stable branch
for reasons like this. It should only be limited by our imagination.
When making votes like this, please do what you think is best for the
open source project, instead of what you think is best for your
corporation.
I'm +1 for both proposals myself. But i think its also ok to wait a
month or so after java8 release before moving trunk to it, to see what
the adoption is like.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
I tend to think Java 8 still requires a fair share of testing before
it'll make it to production... Check out this recent marvel :)
http://marc.info/?l=openjdk-compiler-dev&m=139410546908373&w=2
On Mon, Mar 10, 2014 at 1:37 PM, Jan Høydahl <ja...@cominvent.com> wrote:
> +1 for 4.x on Java7
> -0 for rushing trunk to 8 now
>
> Rob, in my view, what's best for Lucene as a project is tightly linked to what's best for its users. And the users tend do be corporate. I think users are so important that we should even consider rolling a bugfix-release from the 4.7 branch after 4.8 is released, if there is sufficient user demand for it. I hope we'll see trunk on Java8 before summer, but *today* is a tad too aggressive :)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 10. mars 2014 kl. 12:57 skrev Robert Muir <rc...@gmail.com>:
>
>> Its too sad this decision isn't about what is best for attracting new
>> developers, but instead corrupted by corporate policies around JVM
>> versions and the like.
>>
>> what a shame, open source isn't supposed to be like that.
>>
>> On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> Hi,
>>>
>>> it looks like we all agree on the same:
>>>
>>> +1 for Lucene 4.x requirement on Java 7.
>>> -1 to not change trunk (keep it on Java 7,too).
>>>
>>> I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
>>>
>>> I was expecting the fact that the majority -1 on trunk with Java 8. Simon said, that we may provide closures in the API in the future, but for our public API that’s still not a must to actually be on Java 8: If we define our interfaces nicely (using 1-method functional *interface*, no abstract classes, only interfaces!), everybody on Java 8 can use closures although Lucene is on Java 7. Maybe in the future we can have a TokenStream variant with push-semantics using closures!
>>>
>>> I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the backport. The initial patch covering many commits is already ready to commit. I just have to take the time until this vote finishes, to check that all stuff like smoke tester, javadocs linting,... work as expected.
>>>
>>> Theoretically, we might also only change Lucene 4.x's build to Java 7 without any code change, but we should also provide some real reason for the move! Otherwise people will start to complain and "patch" Lucene 4.8 to still support Java 6 and Android mobile phones :-)
>>>
>>> The backported issues bring real improvements to the user and make usage with Java 6 impossible:
>>> - Use of FileChannel's new open method (this allows deleting files while open on Windows)
>>> - Use of Long.compare(long,long) and Integer.compare(int,int) instead of the hacks with Long.signum() or 3 way branches. Hotspot aggressively handles those methods and they may get intrinsics in the future. So we should really use them.
>>> The above issue has primarily focused on backporting these changes and reverting "quick fix commits in 4.x" (after failed Jenkins builds).
>>>
>>> In the future we have now only one supported Java version, so backports are very easy. Also releasing 4.x is much easier now, because Javadocs look fine now by default. We can now also proceed with using diamond operator and try-with-resources (much more important than diamond), without the need for backports being hard. So feel free to commit any Java 7 syntax once LUCENE-5514 is resolved!
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>> -----Original Message-----
>>>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>>>> Sent: Saturday, March 08, 2014 5:17 PM
>>>> To: dev@lucene.apache.org
>>>> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
>>>> officially released)
>>>>
>>>> Hi all,
>>>>
>>>> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
>>>> 2014. Because of this, lots of developers will move to Java 8, too. This makes
>>>> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
>>>> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
>>>> your Windows Explorer - or similar stuff in Linux/Mäc).
>>>>
>>>> We already discussed in another thread about moving to release trunk as 5.0,
>>>> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
>>>> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
>>>> platform anymore. If they upgrade to 4.8, they should also upgrade their
>>>> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
>>>> soon as it is released (in 10 days).
>>>>
>>>> Now the good things: We don't need to support JRockit anymore, no need to
>>>> support IBM J9 in trunk (unless they release a new version based on Java 8).
>>>>
>>>> So the vote here is about:
>>>>
>>>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
>>>> related issues (FileChannel improvements, diamond operator,...).
>>>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
>>>> would make some APIs much nicer. Our infrastructure mostly supports this,
>>>> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
>>>> with all its crazy new stuff.
>>>>
>>>> You can vote separately for both items!
>>>>
>>>> Uwe
>>>>
>>>> -----
>>>> Uwe Schindler
>>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>>> http://www.thetaphi.de
>>>> eMail: uwe@thetaphi.de
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>>> commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Jan Høydahl <ja...@cominvent.com>.
+1 for 4.x on Java7
-0 for rushing trunk to 8 now
Rob, in my view, what's best for Lucene as a project is tightly linked to what's best for its users. And the users tend do be corporate. I think users are so important that we should even consider rolling a bugfix-release from the 4.7 branch after 4.8 is released, if there is sufficient user demand for it. I hope we'll see trunk on Java8 before summer, but *today* is a tad too aggressive :)
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
10. mars 2014 kl. 12:57 skrev Robert Muir <rc...@gmail.com>:
> Its too sad this decision isn't about what is best for attracting new
> developers, but instead corrupted by corporate policies around JVM
> versions and the like.
>
> what a shame, open source isn't supposed to be like that.
>
> On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi,
>>
>> it looks like we all agree on the same:
>>
>> +1 for Lucene 4.x requirement on Java 7.
>> -1 to not change trunk (keep it on Java 7,too).
>>
>> I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
>>
>> I was expecting the fact that the majority -1 on trunk with Java 8. Simon said, that we may provide closures in the API in the future, but for our public API that’s still not a must to actually be on Java 8: If we define our interfaces nicely (using 1-method functional *interface*, no abstract classes, only interfaces!), everybody on Java 8 can use closures although Lucene is on Java 7. Maybe in the future we can have a TokenStream variant with push-semantics using closures!
>>
>> I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the backport. The initial patch covering many commits is already ready to commit. I just have to take the time until this vote finishes, to check that all stuff like smoke tester, javadocs linting,... work as expected.
>>
>> Theoretically, we might also only change Lucene 4.x's build to Java 7 without any code change, but we should also provide some real reason for the move! Otherwise people will start to complain and "patch" Lucene 4.8 to still support Java 6 and Android mobile phones :-)
>>
>> The backported issues bring real improvements to the user and make usage with Java 6 impossible:
>> - Use of FileChannel's new open method (this allows deleting files while open on Windows)
>> - Use of Long.compare(long,long) and Integer.compare(int,int) instead of the hacks with Long.signum() or 3 way branches. Hotspot aggressively handles those methods and they may get intrinsics in the future. So we should really use them.
>> The above issue has primarily focused on backporting these changes and reverting "quick fix commits in 4.x" (after failed Jenkins builds).
>>
>> In the future we have now only one supported Java version, so backports are very easy. Also releasing 4.x is much easier now, because Javadocs look fine now by default. We can now also proceed with using diamond operator and try-with-resources (much more important than diamond), without the need for backports being hard. So feel free to commit any Java 7 syntax once LUCENE-5514 is resolved!
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>> -----Original Message-----
>>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>>> Sent: Saturday, March 08, 2014 5:17 PM
>>> To: dev@lucene.apache.org
>>> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
>>> officially released)
>>>
>>> Hi all,
>>>
>>> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
>>> 2014. Because of this, lots of developers will move to Java 8, too. This makes
>>> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
>>> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
>>> your Windows Explorer - or similar stuff in Linux/Mäc).
>>>
>>> We already discussed in another thread about moving to release trunk as 5.0,
>>> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
>>> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
>>> platform anymore. If they upgrade to 4.8, they should also upgrade their
>>> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
>>> soon as it is released (in 10 days).
>>>
>>> Now the good things: We don't need to support JRockit anymore, no need to
>>> support IBM J9 in trunk (unless they release a new version based on Java 8).
>>>
>>> So the vote here is about:
>>>
>>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
>>> related issues (FileChannel improvements, diamond operator,...).
>>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
>>> would make some APIs much nicer. Our infrastructure mostly supports this,
>>> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
>>> with all its crazy new stuff.
>>>
>>> You can vote separately for both items!
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>> commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Simon Willnauer <si...@gmail.com>.
I agree with you on the fact that we should always try to innovate.
Moving to Java8 is innovation and we should do it rather sooner than
later. I just don't think we should move there right before it's even
released. I can totally see this vote coming in in a couple of month
once we have fixed the bugs taht come with such a huge thing and then
move. It might also help us in the future to think more about what we
should make trunk only etc.
I can totally see that a large user base might have problems with
using 1.8 in production but that is still a year out or so anyways
(Lucene 5.0 I mean). It's controversal but we should rethink more
often as we do now and move forward on 4.x.... I think it's good!
progress over perfection :)
simon
On Mon, Mar 10, 2014 at 12:57 PM, Robert Muir <rc...@gmail.com> wrote:
> Its too sad this decision isn't about what is best for attracting new
> developers, but instead corrupted by corporate policies around JVM
> versions and the like.
>
> what a shame, open source isn't supposed to be like that.
>
> On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi,
>>
>> it looks like we all agree on the same:
>>
>> +1 for Lucene 4.x requirement on Java 7.
>> -1 to not change trunk (keep it on Java 7,too).
>>
>> I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
>>
>> I was expecting the fact that the majority -1 on trunk with Java 8. Simon said, that we may provide closures in the API in the future, but for our public API that’s still not a must to actually be on Java 8: If we define our interfaces nicely (using 1-method functional *interface*, no abstract classes, only interfaces!), everybody on Java 8 can use closures although Lucene is on Java 7. Maybe in the future we can have a TokenStream variant with push-semantics using closures!
>>
>> I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the backport. The initial patch covering many commits is already ready to commit. I just have to take the time until this vote finishes, to check that all stuff like smoke tester, javadocs linting,... work as expected.
>>
>> Theoretically, we might also only change Lucene 4.x's build to Java 7 without any code change, but we should also provide some real reason for the move! Otherwise people will start to complain and "patch" Lucene 4.8 to still support Java 6 and Android mobile phones :-)
>>
>> The backported issues bring real improvements to the user and make usage with Java 6 impossible:
>> - Use of FileChannel's new open method (this allows deleting files while open on Windows)
>> - Use of Long.compare(long,long) and Integer.compare(int,int) instead of the hacks with Long.signum() or 3 way branches. Hotspot aggressively handles those methods and they may get intrinsics in the future. So we should really use them.
>> The above issue has primarily focused on backporting these changes and reverting "quick fix commits in 4.x" (after failed Jenkins builds).
>>
>> In the future we have now only one supported Java version, so backports are very easy. Also releasing 4.x is much easier now, because Javadocs look fine now by default. We can now also proceed with using diamond operator and try-with-resources (much more important than diamond), without the need for backports being hard. So feel free to commit any Java 7 syntax once LUCENE-5514 is resolved!
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>> -----Original Message-----
>>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>>> Sent: Saturday, March 08, 2014 5:17 PM
>>> To: dev@lucene.apache.org
>>> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
>>> officially released)
>>>
>>> Hi all,
>>>
>>> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
>>> 2014. Because of this, lots of developers will move to Java 8, too. This makes
>>> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
>>> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
>>> your Windows Explorer - or similar stuff in Linux/Mäc).
>>>
>>> We already discussed in another thread about moving to release trunk as 5.0,
>>> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
>>> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
>>> platform anymore. If they upgrade to 4.8, they should also upgrade their
>>> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
>>> soon as it is released (in 10 days).
>>>
>>> Now the good things: We don't need to support JRockit anymore, no need to
>>> support IBM J9 in trunk (unless they release a new version based on Java 8).
>>>
>>> So the vote here is about:
>>>
>>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
>>> related issues (FileChannel improvements, diamond operator,...).
>>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
>>> would make some APIs much nicer. Our infrastructure mostly supports this,
>>> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
>>> with all its crazy new stuff.
>>>
>>> You can vote separately for both items!
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>> commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Robert Muir <rc...@gmail.com>.
Its too sad this decision isn't about what is best for attracting new
developers, but instead corrupted by corporate policies around JVM
versions and the like.
what a shame, open source isn't supposed to be like that.
On Mon, Mar 10, 2014 at 5:46 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
> it looks like we all agree on the same:
>
> +1 for Lucene 4.x requirement on Java 7.
> -1 to not change trunk (keep it on Java 7,too).
>
> I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
>
> I was expecting the fact that the majority -1 on trunk with Java 8. Simon said, that we may provide closures in the API in the future, but for our public API that’s still not a must to actually be on Java 8: If we define our interfaces nicely (using 1-method functional *interface*, no abstract classes, only interfaces!), everybody on Java 8 can use closures although Lucene is on Java 7. Maybe in the future we can have a TokenStream variant with push-semantics using closures!
>
> I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the backport. The initial patch covering many commits is already ready to commit. I just have to take the time until this vote finishes, to check that all stuff like smoke tester, javadocs linting,... work as expected.
>
> Theoretically, we might also only change Lucene 4.x's build to Java 7 without any code change, but we should also provide some real reason for the move! Otherwise people will start to complain and "patch" Lucene 4.8 to still support Java 6 and Android mobile phones :-)
>
> The backported issues bring real improvements to the user and make usage with Java 6 impossible:
> - Use of FileChannel's new open method (this allows deleting files while open on Windows)
> - Use of Long.compare(long,long) and Integer.compare(int,int) instead of the hacks with Long.signum() or 3 way branches. Hotspot aggressively handles those methods and they may get intrinsics in the future. So we should really use them.
> The above issue has primarily focused on backporting these changes and reverting "quick fix commits in 4.x" (after failed Jenkins builds).
>
> In the future we have now only one supported Java version, so backports are very easy. Also releasing 4.x is much easier now, because Javadocs look fine now by default. We can now also proceed with using diamond operator and try-with-resources (much more important than diamond), without the need for backports being hard. So feel free to commit any Java 7 syntax once LUCENE-5514 is resolved!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>> -----Original Message-----
>> From: Uwe Schindler [mailto:uwe@thetaphi.de]
>> Sent: Saturday, March 08, 2014 5:17 PM
>> To: dev@lucene.apache.org
>> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
>> officially released)
>>
>> Hi all,
>>
>> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
>> 2014. Because of this, lots of developers will move to Java 8, too. This makes
>> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
>> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
>> your Windows Explorer - or similar stuff in Linux/Mäc).
>>
>> We already discussed in another thread about moving to release trunk as 5.0,
>> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
>> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
>> platform anymore. If they upgrade to 4.8, they should also upgrade their
>> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
>> soon as it is released (in 10 days).
>>
>> Now the good things: We don't need to support JRockit anymore, no need to
>> support IBM J9 in trunk (unless they release a new version based on Java 8).
>>
>> So the vote here is about:
>>
>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
>> related issues (FileChannel improvements, diamond operator,...).
>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
>> would make some APIs much nicer. Our infrastructure mostly supports this,
>> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
>> with all its crazy new stuff.
>>
>> You can vote separately for both items!
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
it looks like we all agree on the same:
+1 for Lucene 4.x requirement on Java 7.
-1 to not change trunk (keep it on Java 7,too).
I will keep this vote open until this evening, but I don't expect any other change. Indeed, there are no real technical reasons to not move.
I was expecting the fact that the majority -1 on trunk with Java 8. Simon said, that we may provide closures in the API in the future, but for our public API that’s still not a must to actually be on Java 8: If we define our interfaces nicely (using 1-method functional *interface*, no abstract classes, only interfaces!), everybody on Java 8 can use closures although Lucene is on Java 7. Maybe in the future we can have a TokenStream variant with push-semantics using closures!
I opened https://issues.apache.org/jira/browse/LUCENE-5514 to manage the backport. The initial patch covering many commits is already ready to commit. I just have to take the time until this vote finishes, to check that all stuff like smoke tester, javadocs linting,... work as expected.
Theoretically, we might also only change Lucene 4.x's build to Java 7 without any code change, but we should also provide some real reason for the move! Otherwise people will start to complain and "patch" Lucene 4.8 to still support Java 6 and Android mobile phones :-)
The backported issues bring real improvements to the user and make usage with Java 6 impossible:
- Use of FileChannel's new open method (this allows deleting files while open on Windows)
- Use of Long.compare(long,long) and Integer.compare(int,int) instead of the hacks with Long.signum() or 3 way branches. Hotspot aggressively handles those methods and they may get intrinsics in the future. So we should really use them.
The above issue has primarily focused on backporting these changes and reverting "quick fix commits in 4.x" (after failed Jenkins builds).
In the future we have now only one supported Java version, so backports are very easy. Also releasing 4.x is much easier now, because Javadocs look fine now by default. We can now also proceed with using diamond operator and try-with-resources (much more important than diamond), without the need for backports being hard. So feel free to commit any Java 7 syntax once LUCENE-5514 is resolved!
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Saturday, March 08, 2014 5:17 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
> officially released)
>
> Hi all,
>
> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
> 2014. Because of this, lots of developers will move to Java 8, too. This makes
> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
> your Windows Explorer - or similar stuff in Linux/Mäc).
>
> We already discussed in another thread about moving to release trunk as 5.0,
> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
> platform anymore. If they upgrade to 4.8, they should also upgrade their
> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
> soon as it is released (in 10 days).
>
> Now the good things: We don't need to support JRockit anymore, no need to
> support IBM J9 in trunk (unless they release a new version based on Java 8).
>
> So the vote here is about:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
> related issues (FileChannel improvements, diamond operator,...).
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
> would make some APIs much nicer. Our infrastructure mostly supports this,
> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
> with all its crazy new stuff.
>
> You can vote separately for both items!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Simon Willnauer <si...@gmail.com>.
@Furkan,
thanks for sharing your thoughts and giving insights. I am happy that
you agree that we should move to Java 1.7 even if you had the trouble
with your legacy code. That is the right way to go here!
Regarding the vote:
+1 for moving to Java 1.7 on 4.x
-1 for moving to Java 8 on trunk I think it's too early and we should
make the decision once we are closer to a release and then features
might be more important than lambda functions so lets move the
decision to later!
simon
On Sun, Mar 9, 2014 at 3:49 PM, Furkan KAMACI <fu...@gmail.com> wrote:
> Hi All;
>
> I am not a committer yet but I want share my thoughts as a contributor and a
> Solr user to give an example from real life. I use SolrCloud for one year
> (our product is at pre-prod step) and I have hundreds of servers at my
> company and nearly half of them are SolrCloud. We also have an Hadoop
> cluster which runs Map/Reduce jobs. We also use and test Ambari and
> Hortonworks and we also use Giraph at our Hadoop side. Just a few weeks ago
> we've faced with an issue that some of projects that we use was not
> compatible with Java 7 (yes its weird.) So we had to change the Java version
> of our servers until we maintain it (I've updated a project from Java 7 to
> Java 6 just because of that.)
>
> I've separated the SolrCloud nodes from other parts of our ecosystem as
> usual and I've never faced with a problem as like that with my management. I
> use Java 1.7 u25 as recommended and because of it is stable. However I see
> that even it is more logical to upgrade to new versions of Java (if it is
> stable) sometimes there maybe some limitations for companies. If I could
> generate Solr indexes via Map/Reduce at my current architecture I was not
> able to use it because of that Java 6 problem.
>
> I'm currently reviewing Java 8 book of Manning and I know that Java 8 has
> great features. However my thought is that: Java 6 might be considered as
> outdated and it is applicable that if we don't support it. However I think
> that Java 7 will be used for a long time within companies and trunk should
> support Java 7 too at least until Java 8 has a common usage or until the end
> of life of Java 7 support (it seems that it will be supported at least until
> March 2015).
>
> Thanks;
> Furkan KAMACI
>
>
> 2014-03-09 16:07 GMT+02:00 Erick Erickson <er...@gmail.com>:
>
>> Solr/Lucene 4.8 -> Java 7
>> +1
>>
>> Solr/Lucene 5.0 -> Java8
>>
>> -1 for now. +1 as we get closer to releasing 5.0. There's still plenty
>> of cruft in trunk that's there only because of needing to support
>> Java6 in the 4.x code line, I think having a period when we can freely
>> clean up some of the Java 6 leftovers in trunk and 4.8+ without having
>> to _additionally_ deal with Java 8 changes that only apply to trunk
>> would be useful. Wouldn't it be nice to have just a few months where
>> one didn't have to even think about it ;)
>>
>> As far as 5.0 is concerned... The point that organizations move much
>> more slowly than we do in terms of adopting new Java releases is well
>> taken. I suspect that, no matter what, if we move 5.0 to Java 8, we'll
>> have quite a long period (3 years as a wild guess) where some people
>> will be unable to use 5.x because of organizational (not technical)
>> issues.
>>
>> IMO, it's perfectly legitimate to say that Solr development shouldn't
>> be held up because organization X is unwilling to use Java8 thus I
>> think we should go forward with 5x and Java8, just not quite yet.
>>
>> Just don't be surprised by people saying that they can't use Java8 in
>> 2016 and would someone backport fix/improvements X, Y, and Z :)...
>>
>>
>>
>> On Sun, Mar 9, 2014 at 9:31 AM, Tommaso Teofili
>> <to...@gmail.com> wrote:
>> >
>> >
>> >
>> > 2014-03-08 17:17 GMT+01:00 Uwe Schindler <uw...@thetaphi.de>:
>> >
>> >> Hi all,
>> >>
>> >> Java 8 will get released (hopefully, but I trust the release plan!) on
>> >> March 18, 2014. Because of this, lots of developers will move to Java
>> >> 8,
>> >> too. This makes maintaining 3 versions for developing Lucene 4.x not
>> >> easy
>> >> anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using
>> >> StExBar
>> >> available for your Windows Explorer - or similar stuff in Linux/Mäc).
>> >>
>> >> We already discussed in another thread about moving to release trunk as
>> >> 5.0, but people disagreed and preferred to release 4.8 with a minimum
>> >> of
>> >> Java 7. This is perfectly fine, as nobody should run Lucene or Solr on
>> >> an
>> >> unsupported platform anymore. If they upgrade to 4.8, they should also
>> >> upgrade their infrastructure - this is a no-brainer. In Lucene trunk we
>> >> switch to Java 8 as soon as it is released (in 10 days).
>> >>
>> >> Now the good things: We don't need to support JRockit anymore, no need
>> >> to
>> >> support IBM J9 in trunk (unless they release a new version based on
>> >> Java 8).
>> >>
>> >> So the vote here is about:
>> >>
>> >> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all
>> >> Java
>> >> 7-related issues (FileChannel improvements, diamond operator,...).
>> >
>> >
>> > +1
>> >
>> >>
>> >> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
>> >> This would make some APIs much nicer. Our infrastructure mostly
>> >> supports
>> >> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
>> >> supports Java 8 with all its crazy new stuff.
>> >
>> >
>> > -1 I think a move to Java 8 is worth only if and when Java 8 has proven
>> > to
>> > be stable, also I don't think (that's another thread though) we're (and
>> > should be) moving fast towards release 5, so there's likely plenty of
>> > time
>> > for having Java 8 out for some time before we have 5.0 out.
>> >
>> > Tommaso
>> >
>> >>
>> >>
>> >> You can vote separately for both items!
>> >>
>> >> Uwe
>> >>
>> >> -----
>> >> Uwe Schindler
>> >> H.-H.-Meier-Allee 63, D-28213 Bremen
>> >> http://www.thetaphi.de
>> >> eMail: uwe@thetaphi.de
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Furkan KAMACI <fu...@gmail.com>.
Hi All;
I am not a committer yet but I want share my thoughts as a contributor and
a Solr user to give an example from real life. I use SolrCloud for one year
(our product is at pre-prod step) and I have hundreds of servers at my
company and nearly half of them are SolrCloud. We also have an Hadoop
cluster which runs Map/Reduce jobs. We also use and test Ambari and
Hortonworks and we also use Giraph at our Hadoop side. Just a few weeks ago
we've faced with an issue that some of projects that we use was not
compatible with Java 7 (yes its weird.) So we had to change the Java
version of our servers until we maintain it (I've updated a project from
Java 7 to Java 6 just because of that.)
I've separated the SolrCloud nodes from other parts of our ecosystem as
usual and I've never faced with a problem as like that with my management.
I use Java 1.7 u25 as recommended and because of it is stable. However I
see that even it is more logical to upgrade to new versions of Java (if it
is stable) sometimes there maybe some limitations for companies. If I could
generate Solr indexes via Map/Reduce at my current architecture I was not
able to use it because of that Java 6 problem.
I'm currently reviewing Java 8 book of Manning and I know that Java 8 has
great features. However my thought is that: Java 6 might be considered as
outdated and it is applicable that if we don't support it. However I think
that Java 7 will be used for a long time within companies and trunk should
support Java 7 too at least until Java 8 has a common usage or until the
end of life of Java 7 support (it seems that it will be supported at least
until March 2015).
Thanks;
Furkan KAMACI
2014-03-09 16:07 GMT+02:00 Erick Erickson <er...@gmail.com>:
> Solr/Lucene 4.8 -> Java 7
> +1
>
> Solr/Lucene 5.0 -> Java8
>
> -1 for now. +1 as we get closer to releasing 5.0. There's still plenty
> of cruft in trunk that's there only because of needing to support
> Java6 in the 4.x code line, I think having a period when we can freely
> clean up some of the Java 6 leftovers in trunk and 4.8+ without having
> to _additionally_ deal with Java 8 changes that only apply to trunk
> would be useful. Wouldn't it be nice to have just a few months where
> one didn't have to even think about it ;)
>
> As far as 5.0 is concerned... The point that organizations move much
> more slowly than we do in terms of adopting new Java releases is well
> taken. I suspect that, no matter what, if we move 5.0 to Java 8, we'll
> have quite a long period (3 years as a wild guess) where some people
> will be unable to use 5.x because of organizational (not technical)
> issues.
>
> IMO, it's perfectly legitimate to say that Solr development shouldn't
> be held up because organization X is unwilling to use Java8 thus I
> think we should go forward with 5x and Java8, just not quite yet.
>
> Just don't be surprised by people saying that they can't use Java8 in
> 2016 and would someone backport fix/improvements X, Y, and Z :)...
>
>
>
> On Sun, Mar 9, 2014 at 9:31 AM, Tommaso Teofili
> <to...@gmail.com> wrote:
> >
> >
> >
> > 2014-03-08 17:17 GMT+01:00 Uwe Schindler <uw...@thetaphi.de>:
> >
> >> Hi all,
> >>
> >> Java 8 will get released (hopefully, but I trust the release plan!) on
> >> March 18, 2014. Because of this, lots of developers will move to Java 8,
> >> too. This makes maintaining 3 versions for developing Lucene 4.x not
> easy
> >> anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using
> StExBar
> >> available for your Windows Explorer - or similar stuff in Linux/Mäc).
> >>
> >> We already discussed in another thread about moving to release trunk as
> >> 5.0, but people disagreed and preferred to release 4.8 with a minimum of
> >> Java 7. This is perfectly fine, as nobody should run Lucene or Solr on
> an
> >> unsupported platform anymore. If they upgrade to 4.8, they should also
> >> upgrade their infrastructure - this is a no-brainer. In Lucene trunk we
> >> switch to Java 8 as soon as it is released (in 10 days).
> >>
> >> Now the good things: We don't need to support JRockit anymore, no need
> to
> >> support IBM J9 in trunk (unless they release a new version based on
> Java 8).
> >>
> >> So the vote here is about:
> >>
> >> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all
> Java
> >> 7-related issues (FileChannel improvements, diamond operator,...).
> >
> >
> > +1
> >
> >>
> >> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
> >> This would make some APIs much nicer. Our infrastructure mostly supports
> >> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
> >> supports Java 8 with all its crazy new stuff.
> >
> >
> > -1 I think a move to Java 8 is worth only if and when Java 8 has proven
> to
> > be stable, also I don't think (that's another thread though) we're (and
> > should be) moving fast towards release 5, so there's likely plenty of
> time
> > for having Java 8 out for some time before we have 5.0 out.
> >
> > Tommaso
> >
> >>
> >>
> >> You can vote separately for both items!
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Erick Erickson <er...@gmail.com>.
Solr/Lucene 4.8 -> Java 7
+1
Solr/Lucene 5.0 -> Java8
-1 for now. +1 as we get closer to releasing 5.0. There's still plenty
of cruft in trunk that's there only because of needing to support
Java6 in the 4.x code line, I think having a period when we can freely
clean up some of the Java 6 leftovers in trunk and 4.8+ without having
to _additionally_ deal with Java 8 changes that only apply to trunk
would be useful. Wouldn't it be nice to have just a few months where
one didn't have to even think about it ;)
As far as 5.0 is concerned... The point that organizations move much
more slowly than we do in terms of adopting new Java releases is well
taken. I suspect that, no matter what, if we move 5.0 to Java 8, we'll
have quite a long period (3 years as a wild guess) where some people
will be unable to use 5.x because of organizational (not technical)
issues.
IMO, it's perfectly legitimate to say that Solr development shouldn't
be held up because organization X is unwilling to use Java8 thus I
think we should go forward with 5x and Java8, just not quite yet.
Just don't be surprised by people saying that they can't use Java8 in
2016 and would someone backport fix/improvements X, Y, and Z :)...
On Sun, Mar 9, 2014 at 9:31 AM, Tommaso Teofili
<to...@gmail.com> wrote:
>
>
>
> 2014-03-08 17:17 GMT+01:00 Uwe Schindler <uw...@thetaphi.de>:
>
>> Hi all,
>>
>> Java 8 will get released (hopefully, but I trust the release plan!) on
>> March 18, 2014. Because of this, lots of developers will move to Java 8,
>> too. This makes maintaining 3 versions for developing Lucene 4.x not easy
>> anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using StExBar
>> available for your Windows Explorer - or similar stuff in Linux/Mäc).
>>
>> We already discussed in another thread about moving to release trunk as
>> 5.0, but people disagreed and preferred to release 4.8 with a minimum of
>> Java 7. This is perfectly fine, as nobody should run Lucene or Solr on an
>> unsupported platform anymore. If they upgrade to 4.8, they should also
>> upgrade their infrastructure - this is a no-brainer. In Lucene trunk we
>> switch to Java 8 as soon as it is released (in 10 days).
>>
>> Now the good things: We don't need to support JRockit anymore, no need to
>> support IBM J9 in trunk (unless they release a new version based on Java 8).
>>
>> So the vote here is about:
>>
>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java
>> 7-related issues (FileChannel improvements, diamond operator,...).
>
>
> +1
>
>>
>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
>> This would make some APIs much nicer. Our infrastructure mostly supports
>> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
>> supports Java 8 with all its crazy new stuff.
>
>
> -1 I think a move to Java 8 is worth only if and when Java 8 has proven to
> be stable, also I don't think (that's another thread though) we're (and
> should be) moving fast towards release 5, so there's likely plenty of time
> for having Java 8 out for some time before we have 5.0 out.
>
> Tommaso
>
>>
>>
>> You can vote separately for both items!
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Tommaso Teofili <to...@gmail.com>.
2014-03-08 17:17 GMT+01:00 Uwe Schindler <uw...@thetaphi.de>:
> Hi all,
>
> Java 8 will get released (hopefully, but I trust the release plan!) on
> March 18, 2014. Because of this, lots of developers will move to Java 8,
> too. This makes maintaining 3 versions for developing Lucene 4.x not easy
> anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using
> StExBar available for your Windows Explorer - or similar stuff in
> Linux/Mäc).
>
> We already discussed in another thread about moving to release trunk as
> 5.0, but people disagreed and preferred to release 4.8 with a minimum of
> Java 7. This is perfectly fine, as nobody should run Lucene or Solr on an
> unsupported platform anymore. If they upgrade to 4.8, they should also
> upgrade their infrastructure - this is a no-brainer. In Lucene trunk we
> switch to Java 8 as soon as it is released (in 10 days).
>
> Now the good things: We don't need to support JRockit anymore, no need to
> support IBM J9 in trunk (unless they release a new version based on Java 8).
>
> So the vote here is about:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java
> 7-related issues (FileChannel improvements, diamond operator,...).
>
+1
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
> This would make some APIs much nicer. Our infrastructure mostly supports
> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
> supports Java 8 with all its crazy new stuff.
>
-1 I think a move to Java 8 is worth only if and when Java 8 has proven to
be stable, also I don't think (that's another thread though) we're (and
should be) moving fast towards release 5, so there's likely plenty of time
for having Java 8 out for some time before we have 5.0 out.
Tommaso
>
> You can vote separately for both items!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
RE: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Thanks Shawn for the support!
From: Shawn Heisey [mailto:solr@elyograg.org]
> Sent: Saturday, March 08, 2014 8:23 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
> (once officially released)
>
> On 3/8/2014 9:17 AM, Uwe Schindler wrote:
> > [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java
> 7-related issues (FileChannel improvements, diamond operator,...).
>
> +1
>
> We might want to wait until 4.9, so we can use the 4.8 release to announce
> that the change is coming. My vote is still +1 even if we move before the 4.8
> release.
I don't think it would help those people, if they would get the information one release before in the release notes. We should upgrade for 4.8, only announce it on the user mailing lists and on the news section of the website once this vote succeeded.
> I know that this is going to cause heartburn for a lot of people, but honestly if
> they don't already know that Java 6 has had no public support for over a year,
> they haven't been paying attention. I no longer use Java 6 except for
> smoketester runs at release time.
>
> I doubt that our general target audience includes the subset of people that
> are willing to pay Oracle a lot of money for support. My small experience
> with non-Oracle Java 6 implementations indicates that as a group, they do
> not work well with Lucene/Solr.
>
> As already noted in other discussions, there have been some events where
> Java 7 code made it into 4.x before being caught by Jenkins or the
> smoketester. Although these are currently a trickle, I believe that if we
> continue to have Java 6 as a requirement, it will quickly turn into a flood.
Example? I only know of this, when we had that my last minute commits in one of our RCs, but this was found by the release manager. This cannot happen, because it is mandatory that the release artifacts are built with Java 6 - smoketester checks this from the manifest of the JARs!
> Do we think there is much chance of code written for (and compiled with)
> Java 6 to fail to run on Java 8? If so, that's another reason to abandon it.
No. We test the stuff with Java 8 since one year. Works perfectly fine! We found bugs in the JDK, but not in our code - except maybe bugs in solr caused by the new and unpredictable string-hashmap order.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Shawn Heisey <so...@elyograg.org>.
On 3/8/2014 9:17 AM, Uwe Schindler wrote:
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
+1
We might want to wait until 4.9, so we can use the 4.8 release to
announce that the change is coming. My vote is still +1 even if we move
before the 4.8 release.
I know that this is going to cause heartburn for a lot of people, but
honestly if they don't already know that Java 6 has had no public
support for over a year, they haven't been paying attention. I no
longer use Java 6 except for smoketester runs at release time.
I doubt that our general target audience includes the subset of people
that are willing to pay Oracle a lot of money for support. My small
experience with non-Oracle Java 6 implementations indicates that as a
group, they do not work well with Lucene/Solr.
As already noted in other discussions, there have been some events where
Java 7 code made it into 4.x before being caught by Jenkins or the
smoketester. Although these are currently a trickle, I believe that if
we continue to have Java 6 as a requirement, it will quickly turn into a
flood.
Do we think there is much chance of code written for (and compiled with)
Java 6 to fail to run on Java 8? If so, that's another reason to
abandon it.
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
-1 at this time.
That could change depending on when we expect to begin a strong effort
towards the 5.0 release. If we are beginning it soon, then we should
not require Java 8. If Java 8 proves to be very stable after release
and we expect our 5.0 efforts to begin towards the end of the year, we
can revisit. Also, we have the option of making that declaration for a
later 5.x release.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Mark Miller <ma...@gmail.com>.
[.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java
7-related issues (FileChannel improvements, diamond operator,...).
+1
[.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
This would make some APIs much nicer. Our infrastructure mostly supports
this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
supports Java 8 with all its crazy new stuff.
-1 this soon.
Mark
--
- Mark
http://about.me/markrmiller
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Sat, Mar 8, 2014 at 9:47 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
+1
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
-1
I think it is too early. Unfortunately organizations don't move as
fast as us in these things. Let us have this vote when we actually
want to release 5.0.
--
Regards,
Shalin Shekhar Mangar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Anshum Gupta <an...@anshumgupta.net>.
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java
> 7-related issues (FileChannel improvements, diamond operator,...).
>
+1 totally!
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code.
> This would make some APIs much nicer. Our infrastructure mostly supports
> this, only ECJ Javadoc linting is not yet possible, but forbidden-apis
> supports Java 8 with all its crazy new stuff.
>
-1 (right now)
--
Anshum Gupta
http://www.anshumgupta.net
RE: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
the vote is over after 72 hours. The results:
- Almost all voting committers want to move to Java 7 - only Grant Ingersoll said "-0". So I declare this as succeeded vote.
I will now proceed with committing the backports (LUCENE-5514). The Jenkins infrastructure is already upgraded. I will also add a note to the Lucene/Solr webpage to announce that Lucene/Solr 4.8 will be Java 7 minimum. I will also send mail to the *-user mailing lists.
- Most of the committers were against moving to Java 8 in trunk, but we decided, to call the vote again in a few months.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Saturday, March 08, 2014 5:17 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once
> officially released)
>
> Hi all,
>
> Java 8 will get released (hopefully, but I trust the release plan!) on March 18,
> 2014. Because of this, lots of developers will move to Java 8, too. This makes
> maintaining 3 versions for developing Lucene 4.x not easy anymore (unless
> you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for
> your Windows Explorer - or similar stuff in Linux/Mäc).
>
> We already discussed in another thread about moving to release trunk as 5.0,
> but people disagreed and preferred to release 4.8 with a minimum of Java 7.
> This is perfectly fine, as nobody should run Lucene or Solr on an unsupported
> platform anymore. If they upgrade to 4.8, they should also upgrade their
> infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as
> soon as it is released (in 10 days).
>
> Now the good things: We don't need to support JRockit anymore, no need to
> support IBM J9 in trunk (unless they release a new version based on Java 8).
>
> So the vote here is about:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-
> related issues (FileChannel improvements, diamond operator,...).
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This
> would make some APIs much nicer. Our infrastructure mostly supports this,
> only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8
> with all its crazy new stuff.
>
> You can vote separately for both items!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Robert Muir <rc...@gmail.com>.
On Sat, Mar 8, 2014 at 11:41 AM, Adrien Grand <jp...@gmail.com> wrote:
>
>> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
>
> I haven't thought too much about consequences, but if we do that, to
> me it means that we can't release Lucene/Solr 5 soon since we can't
> expect all users to be on Java 8 soon after its release. So I would
> rather like that we wait a bit before doing that in order to still
> have the opportunity to release Lucene/Solr 5 if we get some nice
> backward-incompatible changes in the next months?
>
True, but nobody is holding a gun to those users heads to force them
to upgrade to 5 either. They could just stay on 4.x.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Adrien Grand <jp...@gmail.com>.
Hi Uwe,
On Sat, Mar 8, 2014 at 5:17 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
+1 I think supporting 2 different versions is hard enough.
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
I haven't thought too much about consequences, but if we do that, to
me it means that we can't release Lucene/Solr 5 soon since we can't
expect all users to be on Java 8 soon after its release. So I would
rather like that we wait a bit before doing that in order to still
have the opportunity to release Lucene/Solr 5 if we get some nice
backward-incompatible changes in the next months?
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Yonik Seeley <yo...@heliosearch.com>.
On Sat, Mar 8, 2014 at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7
+1
> [.] Move Lucene/Solr trunk to Java 8
-1 , I think it's too early for this.
-Yonik
http://heliosearch.org - native off-heap filters and fieldcache for solr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Erick Erickson <er...@gmail.com>.
OK, it looks like Java 7 starting with Solr 4.8 is going to happen.
May I suggest we announce this sooner rather than later? Perhaps
starting with an announcement on the user's list Real Soon Now? Like
before we break people's builds that rely on Java 1.6 with a checkin
to 4x?
There will be organizations for which this is a total deal-killer for
4.8. I'm _not_ advocating that we stay on 1.6 because of that, rather
that we give them a chance to start planning/adjusting soon.
Additionally, there's a fair likelihood that some of the organizations
stuck on 1.6 have a long vetting process before 1.7 would be used, so
the more time they have the better if they consider Solr
mission-critical.
On Tue, Mar 11, 2014 at 12:31 PM, Mike Murphy <mm...@gmail.com> wrote:
> On Tue, Mar 11, 2014 at 6:11 AM, Grant Ingersoll <gs...@apache.org> wrote:
>>
>> On Mar 8, 2014, at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>
>> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
>>
>>
>> -0 -- Seems a little odd that we would force an upgrade on a minor version, which is not usually seen as best practice in development.
>
> I agree. I also do not see it making a difference to potential developers.
> What are the benefits to the project? A developer will not make their
> decision to get involved in Lucene/Solr based on branch4x being Java 6
> vs Java 7.
> If causes some users to not upgrade, that's also a bad thing for the project.
>
> -Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Mike Murphy <mm...@gmail.com>.
On Tue, Mar 11, 2014 at 6:11 AM, Grant Ingersoll <gs...@apache.org> wrote:
>
> On Mar 8, 2014, at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
>
>
> -0 -- Seems a little odd that we would force an upgrade on a minor version, which is not usually seen as best practice in development.
I agree. I also do not see it making a difference to potential developers.
What are the benefits to the project? A developer will not make their
decision to get involved in Lucene/Solr based on branch4x being Java 6
vs Java 7.
If causes some users to not upgrade, that's also a bad thing for the project.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Posted by Grant Ingersoll <gs...@apache.org>.
On Mar 8, 2014, at 11:17 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...).
-0 -- Seems a little odd that we would force an upgrade on a minor version, which is not usually seen as best practice in development. A lot of users will have to completely re-certify their whole infrastructure when changing to a new JVM, which is a significant undertaking and thus I don't think this decision should be made casually. For instance, Dawid and I found a fairly nasty little bug where J6 swallows all exceptions in the thread completion service when the blocking queue is full, whereas J7 throws the exception. Some people might be in for a rude awakening on tracking that one down if they are using ThreadCompletionService.
From what I see of our users in production, about 25% are on Java6 still, 75% are on either 7 or 8, with most of them being on 7. I think Typesafe had an interesting survey recently on Java version adoption, which might be worth examining as well.
That being said, it's never easy to get people to go forward, so some times you just need to push them forward.
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
+1. Better to do it before it is ever released and there is no time like the present. Heck, by the time 5 is released, J9 will probably be out and we can have this debate all over again!
FWIW, this thread takes me back to the repeated debates on moving from JDK 1.4 to 1.5. What a horrible bikeshed that was. Go read the archives if you like.
-Grant
--------------------------------------------
Grant Ingersoll | @gsingers
http://www.lucidworks.com
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk
(once officially released)
Posted by Andrzej Bialecki <an...@lucidworks.com>.
On 08 Mar 2014, at 17:17, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi all,
>
> Java 8 will get released (hopefully, but I trust the release plan!) on March 18, 2014. Because of this, lots of developers will move to Java 8, too. This makes maintaining 3 versions for developing Lucene 4.x not easy anymore (unless you have cool JAVA_HOME "cmd" launcher scripts using StExBar available for your Windows Explorer - or similar stuff in Linux/Mäc).
>
> We already discussed in another thread about moving to release trunk as 5.0, but people disagreed and preferred to release 4.8 with a minimum of Java 7. This is perfectly fine, as nobody should run Lucene or Solr on an unsupported platform anymore. If they upgrade to 4.8, they should also upgrade their infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as soon as it is released (in 10 days).
>
> Now the good things: We don't need to support JRockit anymore, no need to support IBM J9 in trunk (unless they release a new version based on Java 8).
>
> So the vote here is about:
>
> [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,…).
+1
> [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff.
-0 I don’t think Java 8 will reach sufficient penetration by the time of Lucene 5 release.
>
> You can vote separately for both items!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
Best regards,
Andrzej Bialecki
--=# http://www.lucidworks.com #=--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org