Sun is killing Java Fisrt goal every day....

Miscellaneous Topics
#1

I wanted to response directly in the concerned threads but as it is related to severals posts/threads read here on JGO I started a new one.

There are soooo much compatibilty issue in Java on all newest JRE that I really think that Sun is killing the “Primary Java philosophy” (At least the one why I jumped into Java ) day by day…

I am really unable to understand why Sun doen’t keep a nice & bugless Java core and do not provide third party libraries for all other stuff like graphics / sound / network and other …

really it would be a lot more stable in this way :

  • Core Java => no change or very few (as other languages…)
  • third party versionned libraries for all fancy JRE stuff

This way someone who have made a software using Java will not get into trouble when some update will be made on the JRE.

Like if it use swing1.02.jar when swing1.03.jar get out all will still work fine for him as it still use the previous version.

Also separating the core/real java language from libraries seems to me to be a lot more clean.

This will also enable two software using two different version of some libraries sound/video/network etc… to run fine on the same plateform without the need to embed the whole JRE inside both.

The problem is that in current Sun plugin all libraries are versionned together and they are all putted in a single Package called JavaX.XX. => this cause thousands of regression and bugs that will soon make Java become one of the most incompatible ways to developp with.

I really dont understand the way it is going , what will be the size of the next JRE and who will use Java tomorrow if it always crash ??

The main reason why I still use Java 1.1 coding is not the MS JVM but rather because this is the only way to be sure (or nearly sure) it will run on any Java version.

Sorry but I have a dream that sun “Separate libraries from each other and from Java core” and stop Spamming a new JRE every two monthes.

#2

It has indeed come so far that Swing has become highly unreliable across versions. Hardware acceleration obviously makes it worse, but that’s not the main point here. I’ve had so many troubles getting complex Swing applications to work reliably across ‘all’ versions, that it’s just rediculous. Plugin problems not even mentioning.

When you browse through the Swing sourcecode, you see bug fixes just about everywhere. Now that might be a good thing, but as we have to support all Swing versions, we cannot rely on those bugs to be fixed, so to make complex components work reliably (like not firing double or triple events under certain circumstances), I have to check the “java.version” property, and write different code for different versions. This, obviously, lead to nearly infinite possibilities after more and more bugfixes are applied.

In short: backwards compatibility simply doesn’t work after 1 bugfix, as you never know what code relied on that bug. The only way to ensure your app works, is to use a private JRE.

#3

I agree, it’s tough. PulpCore has several places that runs code only on certain JREs. Plus, I’ve been logging exceptions for a while, and there are certain methods that throw exceptions on some JREs even though the documentation doesn’t say anything about it. And then there’s IBM’s JRE which has bizarre problems. It’s tough for people making applets from scratch, if they want the applets to work everywhere.

However, I think it’s getting better, not worse. I haven’t into any problems with 6u10 and above. Plus the auto-updating feature is a huge benefit.

As far as libraries go, there are plans for modularization in JDK7 (Project Jigsaw). Perhaps that will help.

#4

That is a common mis-conception - improving quality of subsequent releases does not help rectify fragmentation.
If a new release fixes an old bug, fragmentation has increased.
If a new release introduces a new bug, fragmentation has increased.

New releases always increase fragmentation irrespective of their overall quality.

The only factor that reduces fragmentation is obsolescence.

Unfortunately, the philosophy for too long has been that of backward compatibility; which in general is considered a ‘good thing’.
However, it does have the nasty side-effect of slowing down the rate of obsolescence.

There is something to be said for learning from past mistakes, wiping the slate clean, and beginning again.
I think we’re seeing this happen in the mobile market (arguably the most fragmented sector of all), with the renaissance offered by Google’s Dalvik powered Android platform.

#5

Well, personally, it’s not fragmentation that’s the problem because I don’t support older versions of Java (ie PulpCore considers them obsolete). Java 1.1 had lots of bugs, and when I stopped supporting it I could remove a bunch of work-arounds. Soon I’ll stop supporting Java 1.4, which will mean the removal of more work-arounds. If Java 6u10+ has no workarounds, then the situation is getter better, not worse.

As for Dalvik, yikes, it doesn’t even have a JIT yet. Plus, Android has the same problem:

#6

[quote]Google have tested a number of the most popular Android apps available from the Android Market and have discovered that a large number were broken due to “bad techniques” within the development.
[/quote]
ha ha google is really funny, I was LOL really when I read that, they dont make regression… developpers did bad jobs… LOL … maybe they found the solution fo Sun that is to said developpers have made error that’s why their applications wont run on the newest JRE… that’s really amazing to talk like that and to think that people are so stupid… they really take themself for god…

#7

Err, if people are coding against the standard, then they are using bad techniques and google is absolutely right. For example, using internal sun.* classes, or making assumptions about the file system, or even the dir separator, are all great ways of making java programs that will not port.
It’s like when people made html pages that ran in IE. People need to stop doing that crap and follow the specification instead of just doing whatever works on their particular machine and get upset when it doesn’t work on some other machine.

#8

[quote]It’s like when people made html pages that ran in IE
[/quote]
hum, not really the same here it is about the same API (there are few regression between IE version):

  • they provide an API
  • developpers made all those “populars application”
  • they change API
  • and “populars applications” doesn’t work any more
#9

Afaik this is beeing worked on but there was a deathlock between sun and osgi ppl - See the modules JRS-es

You can laugh at me then but I don’t think that is such a crazy idea. Try googling java + “but it works on my pc” Or think of all the silly ppl who don’t use layoutmanagers and whine why resizing is so screwy. Try teaching ppl in high school or uni/collage java and see how they are telling the computer to do the wrong thing and why how it is a bug and then invent crazy, crazy workarounds. I don’t think this goes away as you get more knowledgeable just much less frequent, in much more obscure and advanced ways.

Now on the flipside,

  • the Sun and google teams suffer just the same from this.
  • they also acknowledge it’s only part of the bugs. (and also a large number could still be relatively a small percentage try taking 5% of the world population)
  • Android is newish, so it wouldn’t be a bad assumption that the number is going to be significantly higher

(Markus, probably said it better)

yeah that, I don’t support stuff that the vendor has deemed end of life. It will always lead to a world of hurt. By telling your users that they are running a insecure version your probably actually helping them.

I think your lieing to yourself here I’ve seen shitloads and shitloads of pages becoming impossible to use between IE versions. You think we have stuff like quicks-mode and on pretty much every webdevelopment forum adleast one thread about how to differentiate between versions?

#10

[quote]You can laugh at me then but I don’t think that is such a crazy idea. Try googling java + “but it works on my pc” Or think of all the silly ppl who don’t use layoutmanagers and whine why resizing is so screwy. Try teaching ppl in high school or uni/collage java and see how they are telling the computer to do the wrong thing and why how it is a bug and then invent crazy, crazy workarounds. I don’t think this goes away as you get more knowledgeable just much less frequent, in much more obscure and advanced ways.
[/quote]
but I understand what google said as : “all developpers have made code that sucks”
It would be better if they reconised their error and said, ok we forget to give right explanation for unstable functionnalities or we done some regression, but that “our fault” it can be due to lack of informations or poor quality API but that’s google not developpers fault.

I think that if you give a tools to someone (any tool) he will learn all he can learn on this tool by using it (difference between reality & theorie) and if you forgot to mention dont use that in bold characters that’s your fault if he has used it. I mean how did you learn Word / 3DS Max / PaintShop , probably yourself and if in newer releases one functionnality is missing even if it is not a functionnality that you will have learned in a “formation” this is not a correct attitude for those software publisher. API are like software, if something is alpha just dont release it, no ?

[quote]I think your lieing to yourself here I’ve seen shitloads and shitloads of pages becoming impossible to use between IE versions. You think we have stuff like quicks-mode and on pretty much every webdevelopment forum adleast one thread about how to differentiate between versions?
[/quote]
I always lie to myself, the funny thing is that DzzD always trust what I said to him :slight_smile:

#11

Aye, but at google they understand that too or so they should: http://video.google.com/videoplay?docid=-3733345136856180693
Practice is a different thing I suppose. I don’t know, that part of writing software is hard.