Re: [wlug] WLUG Meeting is tonight
The language doesn't have to be interpreted. Java is a compiled language. It's just not compiled to the native machine code.
Most JVMs compile to native code, either JIT or ahead-of-time.
Yes I know that the JVM does a certain amount of byte code to native code translation. But this is implementation specific and not guaranteed. It's called a virtual machine for a reason.
Please clarify in your mind the differences among the language, the libraries and the JVM. Then you will realise that the specification for the Java language is silent about whether it is to be interpreted, byte-compiled or compiled to machine code. That is why I responded to your incorrect statements: "Java is a compiled language. It's just not compiled to the native machine code." by explicitly mentioning the JVM. You will also then realise why your claim that IBM has "forked" java is incorrect. (Aristotle points this out to you). As to fears of forking, they are genuine. here is a link for you: http://firebird.sourceforge.net/ And here is an excerpt from one of the pages from that site: --QUOTE------------------------------------------------------------- In August 2000, Borland Software Corp. (formerly known as Inprise) released the beta version of InterBase 6.0 as open source. The community of waiting developers and users preferred to establish itself as an independent, self-regulating team rather than submit to the risks, conditions and restrictions that the company proposed for community participation in open source development. A core of developers quickly formed a project and installed its own source tree on SourceForge. They liked the Phoenix logo which was to have been ISC's brandmark and adopted the name "Firebird" for the project. Because Borland's open source efforts regarding InterBase never really took off beyond prime release of the source code and the company returned its focus to closed commercial development, Firebird became THE Open Source version of InterBase. --END OF QUOTE-------------------------------------------------------- <ethical_rant> You see what these f--ks did? Now I don't give a shit what reasons they had, they should have gotten over it like Netscape/Mozilla did. It goes against the values I hold -- respect the company for the steps they took to open their sources and work with them for the benefit of all. If you have a problem, get some self-respect and write your own damn code from scratch. As more companies open their sources, I hope that similar sentiments to mine will enter the hacker ethic. </ethical_rant>
The main reason is so that Java's fortunes are not tied to Suns fortunes. Which frankly are looking a little bleak. ...
Java as a platform is not tied to Sun's fortunes. Read the license, write code and give the code to Sun. You, IBM and MS can all do that. So far I have seen two arguments for "open sourcing" Java that are worth considering: (1) It will be convenient for Debian users since it will enable apt to transparently manage any packages. (2) Freedom will be good for the platform. To (1): This is a problem with Debian and apt. It can't be the download (I do it on my 33K) it is the hoops that /Debian/ and /apt/ require us to jump through. To (2): Yes. Let us hope that if it happens, we get a license similar in spirit to that of freedom, that Sun is given the respect it deserves and is able to profit fairly from it. And boy if I see the Firebird faction turning their evil green eyes thataway ... Sid
You see what these f--ks did? Now I don't give a shit what reasons they had, they should have gotten over it like Netscape/Mozilla did.
Which f--ks are that? Borland? I was using a lot of Borland products at the time, so I remember the release of Interbase quite clearly. It definitely had the feel of a company wishing to keep dead code alive. Interbase was a good RDBMS, but it was losing marketshare to SQL Server. IMO, the move to open source Interbase was pushed by this, and not neccesarily out of any good will to the world.
It goes against the values I hold -- respect the company for the steps they took to open their sources and work with them for the benefit of all. If you have a problem, get some self-respect and write your own damn code from scratch.
Now you seem to be talking about the Firebird developers (where did the Netscape analogy go?) What's wrong with forking a codebase? Especially if you think that the original codebase was released by a company in trouble, as a way to wipe their hands of a dying product. Don't get me wrong, I'm dead again the zillion-opensource-products-to-do-the-one-thing sort of mentality (yet another emacs with wordstar bindings and tetris.... what's the point?), but in the case where you have taken a supposedly open sourced product, and found that the group in charge of it is being slow or tedious to get patches accepted, and in fact don't even seem to *care* any more, what's the problem with forking it? It is better to fork it than lose ongoing development entirely, surely?
As more companies open their sources, I hope that similar sentiments to mine will enter the hacker ethic.
Your sentiment being "Always write your own code from scratch, rather than take a useful codebase and work on it"? I hope not. You're missing out on one of the most powerful aspects of open source - you can take a project and modify it and release that, legally. Maybe I should point out where a fork has been beneficial: Samba and Samba-TNG (The Next Generation). Samba TNG was forked at a time where some of the developers thought the direction the main Samba team was going was wrong. TNG was aimed at rewriting parts of the core of Samba to do things much closer to the way windows does it. Now, if Luke Leighton got "some self-respect and wrote [his] own code from scratch", TNG would never have taken off. Far too much work. How is TNG beneficial? There is no hostility between the two projects. Code is moved back and forth between the two groups when they agree on a particular area. TNG even pushes a lot of its users back towards the main branch of samba, simply because their needs do not require the TNG codebase and the Samba main branch is more stable and has more documentation. There is active development on Samba, and semi-active development on TNG, and both are trying to solve the same thing in a different way. How is this a BAD thing?
To (1): This is a problem with Debian and apt. It can't be the download (I do it on my 33K) it is the hoops that /Debian/ and /apt/ require us to jump through.
If the license says you can't redistribute it, then any distribution which prefers to maintain it's own repositories will have this problem. Phil pointed out you can do it on BSD, but he seemed to imply that involves manually downloading files. I know in Gentoo you can do it, because the ebuild just grabs the files from Sun's servers for you. How does FC handle this? Sure, you can always download it manually. And you can go and set up your environment manually to path it correctly. And you can setup binfmt so that you can just run a java app without having to know it's java. What happens when you want to put a package that depends on the jvm into your repository however? It is *really* messy having a dependancy installed from source.
To (2): Yes. Let us hope that if it happens, we get a license similar in spirit to that of freedom, that Sun is given the respect it deserves and is able to profit fairly from it.
And boy if I see the Firebird faction turning their evil green eyes thataway ...
Get over it. If Borland stopped development of Interbase after releasing it, it was because Borland didn't care enough about it. Firebird did nothing wrong, other than force Mozilla to change the name of it's browser a second time in short order. Daniel
On Tue, Jun 29, 2004 at 10:44:16PM +1200, s swami wrote:
You will also then realise why your claim that IBM has "forked" java is incorrect. (Aristotle points this out to you).
Despite the myths, java is not "write once, run anywhere". If you develop on one particular version of one particular vendor's virtual machine, your program may behave differently on other versions or other vendor's implementations. I've seen this... a graphical app 1) left mouse trails 2) drew text everywhere when dragging a text thing around 3) sometimes didn't render text when used on a different JVM (in this case, Apple's one). Now, some people will say that this is our java developer's fault for using non-portable constructs, or not testing enough, but then this isn't that much difference to writing in another language, like c++ with qt or wxwindows.
To (1): This is a problem with Debian and apt. It can't be the download (I do it on my 33K) it is the hoops that /Debian/ and /apt/ require us to jump through.
I wanted to try a java program on my home machine once. So I did what you suggested, I went to sun and downloaded some massive java runtime environment for linux x86, since debian aren't allowed to redistribute it. After an eternity downloading, it didn't work. Any attempt to invoke the interpreter caused a bus error. From my attempts at debugging, it appeared to have problems doing some basic libc stuff. I suspect this is because it was built and dynamically linked against red-hat specific versions of things, and the libc in my distribution was sufficiently different to red hat's version. Maybe you're lucky that your slackware version of libc is sufficiently close to their version for things to work. But I merely removed java in disgust.
To (2): Yes. Let us hope that if it happens, we get a license similar in spirit to that of freedom, that Sun is given the respect it deserves and is able to profit fairly from it.
If they don't make java free enough for linux users and distributions to redistribute it, people will use the alternatives, and java will remain a platform that has some use in some enterprise servers and a tiny niche on the desktop, instead of a platform that has hundreds of thousands of open source developers writing java apps for linux that happen to work on any other supported platform. John McPherson
John said:
Despite the myths, java is not "write once, run anywhere". If you develop on one particular version of one particular vendor's virtual machine, your program may behave differently on other versions or other vendor's implementations. I've seen this... a graphical app 1) left mouse trails 2) drew text everywhere when dragging a text thing around 3) sometimes didn't render text when used on a different JVM (in this case, Apple's one). Now, some people will say that this is our java developer's fault for using non-portable constructs, or not testing enough, but then this isn't that much difference to writing in another language, like c++ with qt or wxwindows.
Swing has rectified many of these problems. There has also been a complete change in the focus policy.
I wanted to try a java program on my home machine once. So I did what you suggested, I went to sun and downloaded some massive java runtime environment for linux x86, since debian aren't allowed to redistribute it.
Debian chooses not to.
After an eternity downloading, it didn't work. Any attempt to invoke the interpreter caused a bus error. From my attempts at debugging, it appeared to have problems doing some basic libc stuff. I suspect this is because it was built and dynamically linked against red-hat specific versions of things, and the libc in my distribution was sufficiently different to red hat's version. Maybe you're lucky that your slackware version of libc is sufficiently close to their version for things to work. But I merely removed java in disgust.
You have my sympathies. Here is _old_ info from Sun re 1.4.2 that it supports on IA32 Linux: IA32 Linux ---------- Red Hat Enterprise Linux WS 2.1 Gnome-sawfish 1.0 Red Hat Enterprise Linux ES 2.1 Gnome-sawfish 1.0 Red Hat Enterprise Linux AS 2.1 Gnome-sawfish 1.0 SUSE 8.0 Gnome-sawfish 2.0 TurboLinux 7.0 Gnome-sawfish 1.0 SUSE Linux Desktop (SLD) 8 Gnome2-metacity 2.4.34 SUSE 8.2 personal Gnome2.2-Metacity 2.4 Red Hat Enterprise Linux 3.0 WS Gnome2.2-Metacity 2.4 Red Hat Enterprise Linux 3.0 ES Gnome2.2-Metacity 2.4 Red Hat Enterprise Linux 3.0 ASGnome2.2-Metacity 2.4 Sun Java Desktop System 2003 Gnome2-metacity 2.4 SUSE Linux Enterprise Server (SLES) 8 Gnome2-metacity 2.4 SUSE 9.0 professional Gnome2.2-Metacity 2.4 This should enable you to verify what libc you need. This again is a Debian problem because the libc above is pretty standard and uptodate.
To (2): Yes. Let us hope that if it happens, we get a license similar in spirit to that of freedom, that Sun is given the respect it deserves and is able to profit fairly from it.
If they don't make java free enough for linux users and distributions to redistribute it, people will use the alternatives, and java will remain a platform that has some use in some enterprise servers and a tiny niche on the desktop, instead of a platform that has hundreds of thousands of open source developers writing java apps for linux that happen to work on any other supported platform.
Again I ask, apart from Debian, what major distribution has an issue. Cheers, Sid.
participants (3)
-
Daniel Lawson -
John R. McPherson -
s swami