Life In 19x19

Morgoth Bauglir wrote:Why the sudden accusation of nastiness? Are you projecting?

I normally stay out of these types of disputes. But go back and read the thread. People were just saying (1) a new java update came out (2) therefore, I very well could have problems with KGS and (3) that's bad thing. They weren't blaming java, and there was no KGS development vs. Java debate until your post. You may have your own reasons for reading other things into the posts--I suspect that because the posts weren't accompanied by a direct criticism of KGS development, you assumed they were inherently attacking Java and defensive of KGS. Who is the one projecting?

macelee wrote:Eventually the solution is a new HTML-based client to replace the outdated Java client all together. But I am slightly dismayed by the progress. Surely writing a new client is not easy, but it should not take a professional more than a couple of months to do it. To put this in context, it took me 3 nights to create a usable HTML5-base SGF viewer for Go4Go.net, and no more than a week to sort out all the bugs. I do have a day job, have never used HTML5 before, and only has Google as reference.

Yeah, an sgf viewer is not at all the same as an application that has resizeable components, continual server requests, all the game markers KGS supports, menus, and so on.

Morgoth Bauglir wrote:

daal wrote:Why all the nastiness? It's just a fact that KGS software is not being updated, and that Java updates can have undesired consequences. In this thread, neither is Java being blamed, nor is an admin defending KGS' policies. Just another example of a disgruntled user looking for an excuse to lambast KGS?

Why the sudden accusation of nastiness? Are you projecting?

The fact KGS admins now like to explain issues with CGoban as due to Java "bugs", and users are lead to believe that all the issues are due to Java. This thread is a fine example of how KGS users are brainwashed into think how Java is the source of all evil.


Their logic is impeccable, isn't it ? After all, CGoban isn't being updated and Java is. If CGoban works fine with the previous versions of Java and no longer works with this version of Java, it must be due to more and more Java "bugs".

Dear Dark Lord of Middle Earth,

The bugs are caused by Java updates not being backwards compatible, some KGS admins term this as a 'Java bug'. I fully accept that this short description does not give a full understanding of the situation. However, at no point, do we say that Java is the source of evil, for we are fully aware that you are the source of evil in this middle earth, oh Dark One.

Regards,

I find it disingenuous to term it as Java being "not backward compatible" too.

Bugfixs in frameworks more often reveal bugs in programs relying on them.


An example:

Suppose you must take a preflight check before taking off.

Do_a_preflight_checklist()
Take_off()

But in your program, you simply do a Take_off() and it works.

The program is wrong but version 136 of the framework doesn't check for it and lets it slide.

Then version 137 comes out which does the correct thing and your Take_off() fails without because you didn't do a Do_a_preflight_checklist() first.

Your program now crash and burn.

Framework version 137 is in fact fully backward compatible with version 136. The error is in your own program.

The fact that your program runs in version 136 is not proof that it is error free.

This is why any software needs to be maintained or do you expect Java to be backward compatible with any mistakes in CGoban too?

Morgoth Bauglir wrote:Framework version 137 is in fact fully backward compatible with version 136. The error is in your own program.

your example is the very definition of not being backwards compatible.

Morgoth Bauglir wrote:I find it disingenuous to term it as Java being "not backward compatible" too.

Congratulations. You succeeded in starting a fight in a thread in which a fight did not previously exist.

xed_over wrote:your example is the very definition of not being backwards compatible.

I'm not sure "backwards compatible" is the best phrase for anyone to argue over here. Bug fixes, for example, deliberately break code that used to execute successfully. Buggy code. "Backwards compatibility", in my view, is more of a philosophy: good, clean code should last even when Java has to update, i.e. updates should break nothing that isn't already broken. But sometimes code that looks good and clean actually contains a subtle bug, loophole or security flaw no one had spotted before, and when it's spotted, Java has to push through an update and the coder has to update their code.

I think this thread did hint at the argument.

Why else would he be worried by a JAVA update? Because KGS has failed its users repeatedly.



Its like they said before, just because kgs code worked on a previous java doesn't mean it is java's fault that it doesn't work with the new java. It is the coder's or programmer's job to update it with the current software, and if he cannot handle it, ask for help.

Someone can do it for free and would be willing to im sure. The problem to me is wms thinks of kgs as his baby, which is fine, but if you cannot help your users then I think they should come before your pride.

How come his pride in not letting anyone help him with kgs is more important than users not being able to hear sound for over 2 years? What about the lack of an update for graphics, Time stamps, one color go, kibitz tools, etc.?


Im sure there are coders with code already written for these things, but kgs won't implement it (C-Goban H). Like, if it is out there and it helps the users, why is your pride more important than the users getting a good experience? That to me is disrespectful.

Volatile wrote:I think this thread did hint at the argument.

Why else would he be worried by a JAVA update? Because KGS has failed its users repeatedly.



Its like they said before, just because kgs code worked on a previous java doesn't mean it is java's fault that it doesn't work with the new java. It is the coder's or programmer's job to update it with the current software, and if he cannot handle it, ask for help.

Someone can do it for free and would be willing to im sure. The problem to me is wms thinks of kgs as his baby, which is fine, but if you cannot help your users then I think they should come before your pride.

How come his pride in not letting anyone help him with kgs is more important than users not being able to hear sound for over 2 years? What about the lack of an update for graphics, Time stamps, one color go, kibitz tools, etc.?


Im sure there are coders with code already written for these things, but kgs won't implement it (C-Goban H). Like, if it is out there and it helps the users, why is your pride more important than the users getting a good experience? That to me is disrespectful.

I don't care about that. It's fine if KGS doesn't want to maintain its software, but don't go blaming the bitrot on Java "bugs".

Morgoth Bauglir wrote:don't go blaming the bitrot on Java "bugs".

I'm pretty sure everyone realises that Java isn't intentionally adding more bugs in subsequent updates, and I haven't seen anyone accuse them of this. We're all very well aware that wms hasn't updated KGS forever.

Morgoth Bauglir wrote:
I don't care about that. It's fine if KGS doesn't want to maintain its software, but don't go blaming the bitrot on Java "bugs".

I'm not sure why bugs is in quotes, the fact that JDK6 tried to rework how it handled sounds and broke some things is not a secret:
http://bugs.sun.com/bugdatabase/view_bu ... id=7095006

Mef wrote:
I'm not sure why bugs is in quotes, the fact that JDK6 tried to rework how it handled sounds and broke some things is not a secret:
http://bugs.sun.com/bugdatabase/view_bu ... id=7095006

The sound bug is proven but everything from broken network connections, frozen cursor , repaint issue and lag is being blamed on Java issues by admins.

And so what if its a Java bug? Working around framework bugs is half the job of a programmer. If we don't do that, no software will be working at all! We don't say it's a framework bug, throw up our hands and say we can't do anything about it. We find a workaround for it. The sound bug is an prime example of CGoban bitrot.


In my observation on KGS, Senior Admin Mef is one of the leading admin in spreading this propaganda. Do you have proof that Java is responsible for other issues too or is it just nudge nudge wink wink and some url about Java vulnerability? Or is it your logic that the sound bug is proof enough other issues are Java based too ?

Just be straight with users and say that CGoban is unmaintained and it is going to develop more and more issues and that admins can't do anything about it.

The sound issue occurred because Java is not backwards compatible, in saying that I am using the computer science definition of backwards compatible.
Network connectivity issues are unlikely to have anything whatsoever to do with Java...

Morgoth Bauglir wrote:

Mef wrote:
I'm not sure why bugs is in quotes, the fact that JDK6 tried to rework how it handled sounds and broke some things is not a secret:
http://bugs.sun.com/bugdatabase/view_bu ... id=7095006

The sound bug is proven but everything from broken network connections, frozen cursor , repaint issue and lag is being blamed on Java issues by admins.

...

In my observation on KGS, Senior Admin Mef is one of the leading admin in spreading this propaganda. Do you have proof that Java is responsible for other issues too or is it just nudge nudge wink wink and some url about Java vulnerability? Or is it your logic that the sound bug is proof enough other issues are Java based too ?

You must be confusing me with someone else. While I do consider the sound issue to be a java bug, and while I do spend quite a bit of time trying my best to help people get their sound back when they ask me for help...the other things you are talking about sound like complete fabrication.

Blaming network connections or lag on java sounds silly (like blaming traffic on the fact they you're driving a Prius). I've never heard of a repeatable issue with frozen cursors, and I have no idea what the "repaint" issue is (unless it's the Java7 textarea bug that sometimes affects chat).

It is true that when people have a problem that appears to be unique to them, frequently two of the suggestions they are given are clearing the Java Cache and reinstalling their JRE. This isn't necessarily due to "java bugs", it's simply a quick way to eliminate a lot of one-off problems (much like restarting a computer).

It is also true that when multiple 0 day vulnerabilities were announced in Java 07 and it was advised that users rollback to Java 6 I made mention of it on KGS, as every single user there would have been running a form of Java. Presumably they might be interested in learning about the security advisory and likewise might have been interested in being pointed to the appropriate patch (once it was released).

Hi Mef,

I would like to sincerely apologize if I was mistaken.


Regarding bug id 7095006 which you linked to, it is not a Java bug but an error in the submitter's own code. Perhaps you meant some other bug instead?

The code submitted in the bug report is supposed to play files of any audio format Java supports.

To play an audio file, you need to pass the file as a stream to Java.

Java will then take the list of audio format parsers it supports and try them one by one on the stream.

If a parser doesn't work, Java will reset the stream to its beginning and try it again on another parser till the list of parsers is exhausted.

The code in the bug report lacks the capability to let Java reset the stream to its beginning.

The only reason it worked in Java 6 is that coincidentally the first audio format parser in the list is the Wave format parser.

Hence, Java 6 did not not need to invoke the stream reset function. But even in Java 6, the code would have only worked on wave files and not on all Java supported audio formats like it was supposed to.

In Java 7, the order of the list of audio file parsers changed and the submitter's buggy code stopped working.



This is well documented by the Java API.
http://docs.oracle.com/javase/1.5.0/docs/api/javax/sound/sampled/AudioSystem.html#getAudioInputStream(java.io.InputStream)