Bump Java dependency to Java6/7?

[ceefour]

Is there is no specific reason to use Java5, Java6/7 provides more coding conveniences.

Also Oracle no longer supports Java6.

If accepted, you can assign to me.

[linas]

Because it already works?

[githart]

RelEx works using openjdk-7-jdk.

IMO OpenJDK 7 is the preferred JDK as it's considered by Oracle and others to be the reference implementation; Oracle Java 7 is based on OpenJDK 7.

openjdk-7-jdk is specified in the git root Dockerfile; I'll repopen this issue to serve as a placeholder for updating all other JDK references in READMEs, wiki, etc.

[linas]

relex works fine with old jdk's. There is no reason to force users to upgrade.

Upgrades can be hard or impossible, depending on the age of the machine, root access and on whether other users equire the older version.

For example, I use relex on a cray that is running a 6-year-old version of red hat (centos, actually) which cannot be upgraded, for multiple technical reasons, including that the support contract ran out.

Forcing this requirements change fixes absolutely zero bugs, and adds absolutely zero features to relex. But it does introduce a regression. It is basically a BAD IDEA in all caps. This is basic software development common sense.

[ceefour]

It's okay if you don't wish to upgrade. There are a few things I need to inform.

Java 8 should work fine on CentOS 5. For 2008, I presume your Cray is running CentOS 5.2, so it should work very well. In essense, you can extract the Java8 tar.gz then set JAVA_HOME. Same for Java 7. Java 6 is 8 years old, so it should be bundled.

JRE is cross-platform enough it doesn't require the latest kernel 3.x or fancy stuff. Java doesn't require root access, if a system doesn't have Java installed or one wants to use a different JRE version, he can put the JRE in his home directory and use it. JRE is installable side-by-side pretty much the same way you can install vim and nano in the same system, in most Linux distros like CentOS/Fedora/Ubuntu you can install multiple JREs using standard apt-get/yum and choose which one is default.

As for bugs and features, Java7/8 has language constructs like try-with-resources which may reduce leaks, e.g. in certain cases current RelEx leaks 10 GB/day. BTW regarding this particular case, I'm planning I've posted a pull request to fix/reduce the leak bug. It can be done in Java5, however the Java7/8 version would be much simpler and more compact.

And that's the main feature IMHO: by simplifying code, code is easier to understand, and less code means it frees part of our brain cognition to understand more things. Other than language features, each version of Java also come with improved APIs, meaning complex boilerplate Java5 code can be reduced into simpler and more concise code. Java8 is particular because it brings memory management & performance improvements.

Hopefully this clears up some misconceptions. In any case, I still respect your decision to stay with Java5.

[linas]

But if the current code runs with java 5 6 7 or 8, then why change? what's the point? If a user wants to use java 8 they can, right? There's nothing that prevents them from using java 8, if I understand correctly.

[githart]

The issues here include java5 and java6 being depreciated by their distributors, and the ability of developers to add new features with a contemporary jdk. There has been no grand consensus decision to place RelEx into full 'maintenance mode' and no consensus on a broad red light for new features.

@linas, you are not to close issues that have been reopened by another admin for further discussion. With all respect, you will be bumped down from admin to developer on this repo if your antisocial behavior persists. This is your final and only warning.

[githart]

I mean, sure, keep java5 compatibility where it's at all practicable. E.g. a new java7 network class could coexist with the old java5 one. These kinds of explorations and insights are much more likely on issues for new features that are open rather than shutdown. Clearly superfluous new issues of course can be closed summarily, but issues of substance should be changed majorly only by consensus. Sorry if I overreacted. I just don't like authoritarianism!

[linas]

Dave Hart,

Lets stick to the facts, shall we?

This request has no merit. There is nothing that prevents this user from using Java7 if he so desires. There is no reason to change relex to accomodate this wish.

Unfortunately, he also desires that everyone else must also use Java 7, which is not acceptable. That is why I closed the bug before, and that is why I am again closing it now. This bug has no merit.

If you think that there is some technical merit to this request, then please explain what it is. Cause I sure don't see it.

As to authority: someone has to make these decisions. Just accepting any and every change, no matter how bad it is, is a recipe for chaos and disaster.

As to threatening me, I also don't get it. I've put in more work on relex than pretty much everyone-else combined, with the grand exception of Mike Ross. I think its pretty bizarre that you think you have some moral authority to even try to kick me off of a project that's been mine for the last six years.

As to end-of-life: relex is fairly putrid in its current state. It works, but is fundamentally non-extensible, and heavily laden with bad design and bad ideas. Its essentially unsalvagable without a total redesign. I mean, everything in it seemed like a good idea at the time, but now that we are all older and wiser, its time to recognize it for what it is. Once it was good, but technology marches on, and its best to recognize dead-ends and abandon them in a timely manner.

[bgoertzel]

Hi all,

I would suppose I am the natural mediator here, but I'm currently traveling with a packed schedule and erratic Internet access...

Clearly there is a larger issue going on here than just this one request, on whose merit I am personally uncertain.

As I would frame the issue in my own language and subjective view:

-- Linas, while almost surely the most important OpenCog code contributor so far (since the release of OpenCog as OSS), is often pretty obnoxious in communications. (Sometimes Linas is also extremely gracious, e.g. I remember when he spent 4 days helping Shujing merge her code after she took way way too long before merging.... But indeed, sometimes he is quite obnoxious.)

-- Dave, after watching Linas's sometime-obnoxiousness drive away a certain number of OpenCog contributors over the years, is finally feeling fed up with it.... (I think the current OpenCog contributors are largely, though obviously not entirely, adapted to Linas's style and many enjoy working with him. However, as I know from personal communications with various former OpenCog contributors, there are definitely some very good individuals who WOULD still be OpenCog contributors if they hadn't been ticked off at Linas's style and decided to go away because of that....)

...

Dave and I have agreed to discuss this stuff F2F when I get back to HK in mid-August, as it's clear he has strong feelings and many thoughts on the topic, and I don't have time to engage in such a discussion properly while on this breakneck round the world trip....

In the meantime, I hope we can somehow keep on keepin' on without too much conflict or chaos...

I believe Hendy can be a valuable contributor to OpenCog, and agree with Linas's comment that he should be more and more valuable as he gains more aand more knowledge about how the code works and what it does.

I also agree with Linas's comments about RelEx -- it may end up staying around a while, but really it's best viewed as a prototype system that has outlived its natural lifespan, and should be replaced by a system doing something similar using Atomspace representations...

This is a hastily typed email, produced in the midst of over-rapidly processing an over-full inbox, and should not be interpreted as my definitive opinion on anything. I greatly value both Dave and Linas, and expect to come to greatly value Hendy in the future, and my hope is we can all work together cooperatively and happily...

-- Ben

On Mon, Jul 14, 2014 at 1:46 AM, Linas Vepstas notifications@github.com wrote:

Dave Hart,

Lets stick to the facts, shall we?

This request has no merit. There is nothing that prevents this user from using Java7 if he so desires. There is no reason to change relex to accomodate this wish.

Unfortunately, he also desires that everyone else must also use Java 7, which is not acceptable. That is why I closed the bug before, and that is why I am again closing it now. This bug has no merit.

If you think that there is some technical merit to this request, then please explain what it is. Cause I sure don't see it.

As to authority: someone has to make these decisions. Just accepting any and every change, no matter how bad it is, is a recipe for chaos and disaster.

As to threatening me, I also don't get it. I've put in more work on relex than pretty much everyone-else combined, with the grand exception of Mike Ross. I think its pretty bizarre that you think you have some moral authority to even try to kick me off of a project that's been mine for the last six years.

As to end-of-life: relex is fairly putrid in its current state. It works, but is fundamentally non-extensible, and heavily laden with bad design and bad ideas. Its essentially unsalvagable without a total redesign. I mean, everything in it seemed like a good idea at the time, but now that we are all older and wiser, its time to recognize it for what it is. Once it was good, but technology marches on, and its best to recognize dead-ends and abandon them in a timely manner.

— Reply to this email directly or view it on GitHub https://github.com/opencog/relex/issues/102#issuecomment-48854097.

Ben Goertzel, PhD http://goertzel.org

"In an insane world, the sane man must appear to be insane". -- Capt. James T. Kirk

"Emancipate yourself from mental slavery / None but ourselves can free our minds" -- Robert Nesta Marley

[linas]

Hmm. I distinctly remember driving people away who I could not get along with. I remember one guy in particular who was given commit permissions on the day he arrived, and then proceeded to create several show-stopper bugs every day. Every morning, I would pull the latest code, find that it didn't work, spend 2-4 hours debugging and fixing, and then write an angry note complaining about it. Never once did I hear a "sorry, my mistake, won't do it again"; instead, it would happen again, the next morning. And again and again.

Its perfectly fine and normal to sometimes make mistakes, misunderstand things, and just get stuff wrong. But in many of these cases, the developer seemed to be too lazy to study the code, and too eager to make changes. He didn't understand what the code did, how it worked, before making large changes to "fix" something that typically was not even broken.

Coding has two parts: studying the existing code base, and creating new code. Some people dislike the first phase, or are incapable of doing it. These people really enjoy the creative part; they hate the analytic part. As creatives, they typically write large quantities of code that's mostly pretty interesting. But because of poor or incompetent analytics, the code typically: * duplicates existing code * fixes non-issues ** adds features that aren't needed/wanted * breaks existing code.

So, rather than accepting everything that is submitted, one should ask: -- Is it needed? -- Does it fix a real problem, or an imagined one? -- Does it break existing code? -- Does it duplicate existing features?

If the first two don't get a 'yes' and the last two don't get a 'no', then the code should be rejected. In this case, its a change request that 1) isn't needed, and 2) breaks existing code.

[TScottJ]

Perhaps I can offer some "mediation" while Ben is roaming the Serengeti. :)

Firstly, I come from the same (old) school of thought as Linas, in that code changes in general should be heavily scrutinized and justified...Ben can attest to this, based on my recent (rather vehement) argument against one of his Ethiopian developers changing the graphing library for the visualizer without providing any compelling reasons.

However, in this particular case, the submitter has provided some justification for the proposed change, in that Java 7/8 provides better language constructs and would allow existing bugs, such as memory leaks, to be fixed more efficiently. Others have also noted the lack of official support for Java 5, and the improved memory management and performance of Java 8.

Furthermore, I note that this is NOT a pull request, but rather an issue opened simply for discussion. Therefore, the bar need not be as high...no harm in keeping it open until all the points can be discussed, and a consensus reached.

I propose that this issue be kept open at least until Ben gets back next month. Meanwhile, people can post their reasons for/against the suggested version bump.

Cheers!

• Scott

[linas]

FYI, the comment about the memory leak is due to a misunderstanding by the developer about how the code works.

[linas]

the build file now requires a minimum of java 6.