Having been through a bunch of refactors in other projects, I would suggest
doing small incremental patches isolated in related parts of the code. It would
also be nice if you could give us a heads up on changes you're making.
Best of luck!
Dinesh
On Tuesday, March 20, 2018, 3:04:43 PM PDT,
+1 - can help with sections of the code
--
Rahul Singh
rahul.si...@anant.us
Anant Corporation
On Mar 21, 2018, 4:25 PM -0500, Lerh Chuan Low , wrote:
> For reasons others have mentioned (nightmare to continuously update branch
> and resolve merge conflicts, existing patches/big features..) it wi
Please please please ping the list and ask if anyone has big commits ready to
merge before actually committing any huge automated refactors - people who may
be sitting on big patches will thank you if they don’t have to rebase against
huge IntelliJ refactors .
--
Jeff Jirsa
> On Mar 21, 201
+1 if you are willing to take it on. As the person who performed the
Table->Keyspace rename of 2.0, I say good luck! From hindsight of doing that,
as others suggested, I would come at this in multiple tickets.
I would suggest a simple class rename with intellij refactoring tools or
something a
For reasons others have mentioned (nightmare to continuously update branch
and resolve merge conflicts, existing patches/big features..) it will be a
nightmare. It seems like in software projects (just basing it off personal
experience) people typically refactor if a ticket they are working on
touc
Well, that was quick. TL;DR Redistributing any part of the OpenJDK is
basically a no-go.
Thus, that option is off the table.
On Wed, Mar 21, 2018 at 10:46 AM, Jason Brown wrote:
> ftr, I've sent a message to legal-discuss to inquire about the licensing
> aspect of the OpenJDK as we've been disc
ftr, I've sent a message to legal-discuss to inquire about the licensing
aspect of the OpenJDK as we've been discussing. I believe anyone can follow
the thread by subscribing to the legal-discuss@ ML, or you can wait for
updates on this thread as I get them.
On Wed, Mar 21, 2018 at 9:49 AM, Jason
If we went down this path, I can't imagine we would build OpenJDK
ourselves, but probably build a release with jlink or javapackager. I
haven't done homework on that yet, but i *think* it uses a blessed OpenJDK
release for the packaging (or perhaps whatever JDK you happen to be
compiling/building w
The idea was not about building a custom JDK and ship it along with
Cassandra, rather than using the new modular run-time images feature [0]
introduced in Java 9. See also the link posted by Jason [1] for an
practical introduction.
[0] http://openjdk.java.net/jeps/220
[1]
https://steveperkins.com/
On 03/21/2018 04:52 PM, Josh McKenzie wrote:
This would certainly mitigate a lot of the core problems with the new
release model. Has there been any public statements of plans/intent
with regards to distros doing this?
Since the latest official LTS version is Java 8, that's the only one
with pu
On Wed, 21 Mar 2018 10:52:06 -0400, you wrote:
>> Even if you are not running say Debian, or RedHat, those distributions
>> will be backporting critical fixes to their JVMs; This work is going
>> to be done, and will be available to anyone.
>This would certainly mitigate a lot of the core problems
fwiw, a naive internet search turned up [1]. tl;dr use the java 9's jlink
(or java8's javapackager) to build a full app+jre package for distribution.
I started digging into the legal aspects, and (trying to) searching
legal-discuss@. May just send an email to them later today to speed up this
disc
On 21.03.2018 15:41, Ariel Weisberg wrote:
> I'm not clear on what building and bundling our own JRE/JDK accomplishes?
If we talk about OpenJDK, there will be only a single Java version
supported at any time and that is the latest Java version (11, 12, ..).
There is no overlap between supported v
> Even if you are not running say Debian, or RedHat, those distributions
> will be backporting critical fixes to their JVMs; This work is going
> to be done, and will be available to anyone.
This would certainly mitigate a lot of the core problems with the new
release model. Has there been any publ
Hi,
I'm not clear on what building and bundling our own JRE/JDK accomplishes? What
is our source for JRE updates going to be? Are we going to build our own and
does Oracle release the source for their LTS releases? Are we going to extract
LTS updates from CentOS?
If the goal of bundling is to
On Wed, Mar 21, 2018 at 9:21 AM, Gerald Henriksen wrote:
> On Wed, 21 Mar 2018 14:04:39 +0100, you wrote:
>
>>There's also another option, which I just want to mention here for the
>>sake of discussion.
>>
>>Quoting the Oracle Support Roadmap:
>>"Instead of relying on a pre-installed standalone JR
> On Mar 21, 2018, at 7:21 AM, Gerald Henriksen wrote:
>
>> On Wed, 21 Mar 2018 14:04:39 +0100, you wrote:
>> Bundling a custom JRE along with Cassandra, would be convenient in a way
>> that we can do all the testing against the bundled Java version. We
>> could also switch to a new Java versi
On Wed, Mar 21, 2018 at 9:00 AM, Josh McKenzie wrote:
>> Wasn't portability supposed to be one of the
>> big selling points of Java?
> Historically, yes, but their change in release cadence and support
> structure is something they're pushing, not us. We have to figure out
> how to make the best o
On Wed, 21 Mar 2018 14:04:39 +0100, you wrote:
>There's also another option, which I just want to mention here for the
>sake of discussion.
>
>Quoting the Oracle Support Roadmap:
>"Instead of relying on a pre-installed standalone JRE, we encourage
>application developers to deliver JREs with their
I was reading up on the bundling possibility the other day as well. I like the
idea from release standpoint. And if someone wants to use a different version
they can always recompile it themselves.
As Stefan pointed out, the main issue I see is the one of how licensing plays
out with this.
-Jer
> Wasn't portability supposed to be one of the
> big selling points of Java?
Historically, yes, but their change in release cadence and support
structure is something they're pushing, not us. We have to figure out
how to make the best of a change that is, at best, orthogonal to our
interests as a p
On Wed, Mar 21, 2018 at 8:04 AM, Stefan Podkowinski wrote:
> There's also another option, which I just want to mention here for the
> sake of discussion.
>
> Quoting the Oracle Support Roadmap:
> "Instead of relying on a pre-installed standalone JRE, we encourage
> application developers to deliv
On Wed, Mar 21, 2018 at 3:48 AM, Sylvain Lebresne wrote:
[ ... ]
> - pure code renaming is one reasonably simple aspect, but quite a few
> renaming may have user visible impact. Particularly around JMX where many
> things are name based on their class, and to a lesser extend some of our
> tools
Similar to Josh, I like Stefan's idea, a lot. iirc, the Basho folks used to
ship a specific version of erlang with Riak, so it's not a new precedent in
the (nosql) database space.
I'm not sure about the licensing, though, as openjdk is GPLv2 w/ classpath
exception - but I can ask Apache Legal about
As a gut check, the idea of bundling a JRE with C* appeals to me from
a "control your variables" perspective. Simplifies quite a bit of this
problem imo.
On Wed, Mar 21, 2018 at 9:04 AM, Stefan Podkowinski wrote:
> There's also another option, which I just want to mention here for the
> sake of d
There's also another option, which I just want to mention here for the
sake of discussion.
Quoting the Oracle Support Roadmap:
"Instead of relying on a pre-installed standalone JRE, we encourage
application developers to deliver JREs with their applications."
I've played around with Java 9 a whil
I really don't think anyone has been recently against such renaming, and in
fact, a _lot_ of renaming *has* already happen over time. The problem, as
you carefully noted, is that it's such a big task that there is still a lot
to do. Anyway, I've yet to see a patch renaming things to match the CQL
n
I agree that the refactoring make sense but I also know the pain of merging
branches with smaller refactorings. When you have to make a patch for
several branches and that you have to go through several round of reviews
it can be pretty painful.
I know that pain too well so I am not in favor of the
As someone who came to the codebase post CQL but prior to thrift being
removed, +1 to refactor. The current mixing of terminology is a complete
nightmare. This would also give a good opportunity document a lot of code
that simply isn't documented (or incorrect). I'd say it's worth doing it in
multi
+10
There are 2 hard problems in CS: naming things and cache invalidation
Le 20 mars 2018 23:04, "Jon Haddad" a écrit :
> Whenever I hop around in the codebase, one thing that always manages to
> slow me down is needing to understand the context of the variable names
> that I’m looking at. We’
30 matches
Mail list logo
