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

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.

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 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.

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...

_________________
North Lecale

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)