Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
Weekly Edition
Return to the Front page
| |||||||||||||
A new Harmony ProjectGeir Magnusson Jr. sent out a proposal for "Project Harmony" which would create an open source implementation of the Java 2 Platform, Standard Edition (J2SE) version 5 and a "community-developed modular runtime (VM and class library) architecture for independent implementations to share runtime components, all to be available under the Apache License, v2. The proposal calls for "a broad, collaborative community of contributors," and there is an impressive list of interested parties in Magnusson's proposal. We talked with Magnusson about the project, the interest which has been shown so far, and whether Sun had been approached to cut out the middleman and simply open source their implementation of J2SE to save everyone the hassle of doing it again. Magnusson said that the project "was a long time coming," but there was not a specific catalyst that made the group decide that now was the time to move forward. "Finally, we just decided that it's time." He also emphasized that Harmony is about "building communities that can collaborate...we're looking at inviting everybody who wishes to participate." With regard to Sun and open source Java, Magnusson said that "we respect Sun's right to make their decision [regarding licensing]." We also wondered whether Magnusson or someone from the Harmony project had approached Sun to confirm that the company isn't planning on an open source version of Java. Magnusson said that Sun had been made aware of the project, but that he "won't say we've gotten an assurance that they're not going to do this in the next two years." Sun's Graham Hamilton has also said that Sun will probably participate "at some level, although most of our efforts will continue to be focused on building Sun's reference implementation of J2SE." Although Hamilton puts a damper on the endorsement by adding:
I am not entirely sure if the world
really needs a second J2SE implementation, but at the same time I am also
glad to see that all the effort we put into getting the rules and the
licensing issues straightened out is actually proving useful!
Bruno F. Souza, "the number one Java Evangelist in Brazil," and another individual listed in the Harmony proposal, also comments on Harmony in his blog and on the need for a second implementation:
In this, Hamilton is wrong. How important would be J2EE if we had a single
application server? For a long time now the Java Community needs another
J2SE implementation. At this point we don't even have a proof that the JCP
specs are valid! In a recent talk with James Gosling at Café Brasil, while
we discussed Kaffe and Classpath, James commented on how important a clean
room implementation was for this very reason. The work of the FSF on the
Classpath and GCJ projects, and the teams of Kaffe, JamVM and others, are
all validating parts of the spec, what only strengthen our whole
community. The fact that these projects exists should be seen as positive
and should be supported and cherished by all developers, and not ignored
like they have been for so long.
Not only that, but another implementation promotes competition and foster innovation. An open source implementation helps in research, discussions and even in the evolution of the Compatibility Kit. Sun recognizes the value of that, that's why Mustang source code is now available on an ongoing basis, and why Sun proposed recent licensing changes to its implementation, to promote this very things. But this is not enough. Sun's licensing changes get to the edge of the water, but although noticing that the water is cold can be relaxing and beneficial, it don't really give you any of the benefits of swimming. I have already discussed elsewhere other reasons why I think an open source implementation of Java is needed. There is certainly plenty of need for an open source Java in the open source community. It's already been commented on, several times, that OpenOffice.org 2.0 has Java requirements that may pose problems for distributions that don't ship Sun's Java due to license problems. There is also the question of Java on operating systems and/or hardware architectures not supported by Sun. Magnusson agreed this was a "personal driver" for his interest in the Harmony project.
Of course, there are already efforts underway to create open source implementations of Java, such as Kaffe and GNU Classpath. Kaffe is an implementation of the Java virtual machine and class libraries to provide a Java Runtime Environment (JRE), while GNU Classpath is a project to create the core class libraries for use with virtual machines and compilers. There is also the GNU Compiler for Java (GCJ) and many other open source efforts. However, there are a few areas where Harmony may be more desirable in the long run. Firstly, Magnusson stressed the importance of certification for the Harmony project, to ensure compatibility with Sun's J2SE 5. Secondly, as an Apache project, the group may be able to draw from a wider group of contributors than Kaffe or other projects -- particularly from companies that would like to see a fully-compatible open source implementation of J2SE 5. Harmony seems to be getting quite a bit of interest already. Dalibor Topic, a contributor to both Kaffe and GNU Classpath, is one of the other individuals who have signed on to the Harmony proposal. He explains his interest in the project in his Advogato diary:
What the hell am I doing there, then, not being an Apache? Well, two
things: a) trying to help bring ASF and FSF closer together, and ASF using
and contributing to FSF's class libraries would be a pretty good thing to
happen no matter which path towards a runtime they chose, and b) the ASF
can reach a wide audience among developers programming in the Java
programming language that so far has either not heard, or been skeptical
about Free Software runtimes based on GNU Classpath. For whatever reason
the ASF seems to evoke much less fear and terror in some circles than the
FSF, which may make working with those circles through the ASF easier.
Whether the Harmony, GNU Classpath, Kaffe and other projects will be able to sort out licensing is another question. We asked Magnusson about the licensing hurdles, and he said that they are "working to fix licensing issues" and noted that the project was trying to solve licensing problems "in parallel," since "licensing discussions can bog down anything." There are also those who might prefer to forget Java altogether and concentrate on something like Mono instead. While Mono is an interesting technology, it's not always a substitute for Java and may not meet everyone's needs. It also seems unlikely we'll see broad support for Mono from all quarters soon, judging by Havoc Pennington's comments on the Java and Mono discussion with regards to Harmony:
I believe we have legitimate and non-evil reasons why we [Red Hat] can't
ship Mono. And I think open source Java looks plausible and a lot nicer
than C; Java and Classpath will even run on Mono, and if C# becomes more
viable later, experiments such as Graydon's or the Lucene port show that it
isn't hard to do a Java to C# conversion. And guess what, we need open
source Java in the desktop anyhow for OpenOffice.org and the browser plugin
at minimum.
I don't know what people expect Red Hat GNOME developers to do. We can't roll over and say "OK, we'll start hacking in C#, even though we don't see a path to shipping any of the stuff we're hacking on" - does anyone seriously expect that? ...I'm not trying to exhaustively belabor the Java vs. C# technical comparison but I am trying to point out that Java has a hell of a lot going for it including open source developer tools and libraries and huge momentum (largely open source) on the server side. Java 5 has some cute language features, too, and Tromey has shown how to make native code bindings easy. To get a general idea how long it might take for a group to implement J2SE, one might look at the Apache Geronimo project, which is an implementation of the Java 2 Platform, Enterprise Edition (J2EE). The project started in August 2003, and became an official Apache top-level project in May 2004. According to Magnusson, the Geronimo project is now working to pass Sun's TCK for J2EE 1.4, though it isn't clear how much more time will be required for it to reach full compatibility. For those interested in participating, Magnusson has sent out a FAQ about the project which includes instructions on joining the development mailing list. The project is not yet listed on the Apache Incubator site yet. If Harmony is successful, which looks quite likely given the interest it has stirred already, it will be quite beneficial to the open source community. While it would be much easier if Sun simply provided an open source implementation, the community has the tools needed to do so. (Log in to post comments)
A new Harmony Project Posted May 12, 2005 2:27 UTC (Thu) by jello (subscriber, #6083) [Link] Can someone give a pointer to what all these different Java specs are? There seem to be lots of different Free Software projects implementing all sorts of different Java compiler stuff, but the article seemed to assume the reader already knew what all these specs are.
GNOME and high-level languages Posted May 12, 2005 5:53 UTC (Thu) by dhess (subscriber, #7827) [Link] I think there's a problem brewing in the GNOME project, one which the Harmony announcement has brought out in the open again. Novell and RedHat are both drawing a line in the sand, and I think that either a GNOME fork or RedHat's endorsement of a different desktop environment is increasingly likely. Either outcome will be detrimental to the GNU/Linux desktop effort, in the short term, at least; and will give companies like Microsoft plenty of, "Same old UNIX story, they're fragmenting again" fodder.Many GNOME hackers are waking up to the fact that C isn't a very productive language for developing most kinds of interactive desktop applications. (I didn't say it was a bad language, it's just not very productive for most applications of that class.) Unfortunately, C# appears to have caught the fancy of a large number of talented GNOME hackers. Many of the exciting up-and-coming GNOME desktop applications (Beagle, F-Spot, Muine, etc.) are written in C#. Offhand, I can't think of any GNOME desktop applications being written in Java. I wouldn't be surprised if there are a few, I just haven't heard of them, and I don't recall seeing any mentioned on Planet GNOME. If nothing else, the C# crowd is winning the PR battle. Both companies have valid technical and/or legal reasons for their stances. Novell doesn't want to develop software based on the JVM because the JVM is effectively controlled by Sun, and apparently they don't think the free JVMs are mature enough to ship software on them. RedHat doesn't want to develop software based on Mono because they say they can't ship it (but can't say why). On the other hand, both companies have business reasons for their stances, too. Novell has captured a large developer mindshare with C# and knows they have the du jour "hot" language in the GNOME community. RedHat has to be feeling the pressure and is making large investments in Java tools and free JVM/class lib implementations, and is promoting that language as their champion versus C#. I think RedHat is fighting a losing battle. RedHat appears to be unable to generate any excitement in the GNOME community about Java, at least not outside the company (maybe even inside the company). This is in stark contrast to what's happening with Novell and C#. I don't know how such decisions are made by the GNOME project, but given the momentum behind C# in the GNOME developer circles, I find it hard to believe that Mono-based software won't soon be shipping with GNOME. Here's what Havoc Pennington had to say about this possibility:
I don't know what people expect Red Hat GNOME developers to do. We can't roll over and say "OK, we'll start hacking in C#, even though we don't see a path to shipping any of the stuff we're hacking on" - does anyone seriously expect that? I don't think these comments do much other than make RedHat look bad. It sounds like sour grapes at best and a threat at worst. Sorry, Havoc, but that's how it comes off. But instead of just complaining, I do have a better suggestion, and it's called Python. Why not push Python as the "officially endorsed high-level language" of the GNOME project instead of Java? There are plenty of very talented Python programmers out there. In the free software community, Python has at least as much developer mindshare momentum as C#. Code that doesn't run fast enough in Python can be written in C or C++ and wrapped with Python bindings very easily, or can be written in Pyrex. There are perfectly good GTK bindings for it. It's fantastic for rapid development. It's a community-developed language with no "ownership" issues. Every GNU/Linux distro has packages for it. Novell can make sound technical and legal arguments against requiring Java as part of GNOME, but not Python. Even one of RedHat's own, Seth Nickel, seems to think it's a good idea. So Havoc (Pennington, not the other guy with the l33t nick), if you're reading... OK, so you can't explain the reasons why RedHat can't ship Mono. Can you explain why you don't give Python the same endorsement for GNOME development as you do for Java?
GNOME and high-level languages Posted May 12, 2005 7:21 UTC (Thu) by socket (guest, #43) [Link] I think this is a hard problem for us.Sun effectively controls Java. Microsoft's history makes many free software developers wary of anything they "give away," including C#, and in my opinion, rightly so. But I realize others feel differently, and I fully expect that someone will correct me by pointing out that Microsoft doesn't really control C#. That's a debate for another time. Being language-agnostic is a wonderful goal, and I'm an active follower of Parrot's development, but despite its power, there's still a relatively small number of useful languages supported. In the meantime, it means that we're just stuck with putting SWIG wrappers around each required C library, for each language, and then eventually rewriting stuff that's commonly used in C and adding more bindings. Being able to call Perl libraries from Ruby or Python just isn't possible until we have good implementations of each on Parrot. Choosing one of Perl, Python, Ruby, OCaml, Lisp, Standard ML, Modula-3, Forth, Postscript, or anyone else's favorite scripting language leads us down another path: we choose favorites. But honestly, I've come to have several favorite languages, and would be disappointed if I couldn't use whatever I'm happiest with at that moment on my weekend project to make a better recipe manager. So here we are. I don't want my software dependent on libraries or tools controlled by Sun or Microsoft. I'm sure many of us don't want to spend our time scratching our heads at some obtuse bit of Perl from CPAN if it made up part of a core library we had to call in to. I'm sure we also grit our teeth and wish Python were more like Ruby, or the other way around. And others can't get past the parentheses of Lisp. And we all want more libraries, and desktop systems, to have support for our favorite language. It's a hard problem. I just to emphasize the point that we don't force ourselves down paths we can't backtrack from. I want us all to think about what it would really mean to say, "For this desktop environment, your development language is really just $LANG. The others will kinda sorta work, but they're not supported anywhere near as well." Our strength comes with and partly because of a diversity of ideologies related to programming languages. Let's not be so quick to throw that away.
GNOME and high-level languages Posted May 12, 2005 14:37 UTC (Thu) by ncm (subscriber, #165) [Link] "Our strength comes with and partly because of a diversity of ideologies related to programming languages."Really? From here it looks as if each of these ideologies saps our strength. Whether it's built-in garbage collection, or object orientation, "there's more than one way to do it", "lambda the ultimate, or "builds and does", we are the poorer for being locked into it, even if only in a single project. The best that might be said about a diversity of them is that it may undermine allegiance to any one of them. Even then, we are led to believe that anything common to all the languages we know is god-given. We are better off with pragmatic languages. Survey the programs on your favorite distribution, and you'll find (in order) C, C++, a few in Perl, fewer in Python. Java is largely confined to programs for people who are already obliged (by corporate diktat?) to use it, or write it. These languages rule not because they're especially good at anything particular, but because they don't pretend to know better than we do what we're trying to do: C, because it doesn't pretend to know much of anything; C++, because it is happy to get out of the way; Perl, because it's all over the place.
GNOME and high-level languages Posted May 12, 2005 16:02 UTC (Thu) by shahms (subscriber, #8877) [Link] Um, I think you'll find the actual order (at least for FC4) is going to be:C, C++, Python, Perl. Almost all of the Fedora GUI system tools are Python. There are very, very few progams that are built using Perl. automake and autoconf are the biggest ones. foomatic also uses perl and I think libtool.
Don't get me wrong, there are a lot of packages that require perl, but most of these are perl modules and not applications.
GNOME and high-level languages Posted May 12, 2005 17:20 UTC (Thu) by ncm (subscriber, #165) [Link] That was what I expected to find, but it wasn't what I found. Your mileage may vary. I didn't look at a Red Hat system, which undoubtedly has lots of Python programs not found on other distros. Python is another pragmatic language, anyway, that "plays well with others".
GNOME and high-level languages Posted May 12, 2005 23:05 UTC (Thu) by bk (guest, #25617) [Link] automake/autoconf uses m4, or am I missing something obvious?
GNOME and high-level languages Posted May 13, 2005 9:36 UTC (Fri) by wilck (subscriber, #29844) [Link] autoconf: m4automake: perl
That's what it used to be.
GNOME and high-level languages Posted May 13, 2005 4:11 UTC (Fri) by green (guest, #29086) [Link] For Fedora Core 4 the order will be C, C++, Java, Lisp/Scheme, Perl, Ada, Python, Assembly (ignoring shell scripts, most of which are auto* files anyways).
Here's the data to back this up:
AG
As I said Posted May 13, 2005 6:08 UTC (Fri) by ncm (subscriber, #165) [Link] "Java is largely confined to programs for people who are already obliged (by corporate diktat?) to use it, or write it."
Eclipse 1310322 How many of these are useful to somebody not already obliged to run Java, for being obliged to write it? Sure, Sun shoehorned the stuff into OO.o, but that's corporate diktat too.
GNOME and high-level languages Posted May 14, 2005 14:58 UTC (Sat) by ohanssen (guest, #2761) [Link] Well. I have seen examples of the opposite. People want to use Java, but are not allowed to (by some "corporate diktat"), because somebody strongly belives that dot net and C# is the right choice. And in another case, because of ideological reasons ("Java is not free software", etc. etc.).
GNOME and high-level languages Posted May 12, 2005 8:14 UTC (Thu) by vgough (guest, #2781) [Link] Quote:I think RedHat is fighting a losing battle. RedHat appears to be unable to generate any excitement in the GNOME community about Java, at least not outside the company (maybe even inside the company). This is in stark contrast to what's happening with Novell and C#. I don't know how such decisions are made by the GNOME project, but given the momentum behind C# in the GNOME developer circles, I find it hard to believe that Mono-based software won't soon be shipping with GNOME. This reminds me of RedHat's stance on KDE years ago, and it is sad to see what appears to be the same situation brewing. I was a user/supporter of RedHat for a long time, but eventually moved to Mandrake (and then Suse) because RedHat wouldn't give me what I wanted on my desktop -- KDE. Obviously both Java and C# have a significant mindshare and aren't going away anytime soon. Just like with KDE, eventually RedHat is going to have to realize they need to ship what their customers' want. Having some secret objection to C# isn't going to cut it. It is hard to garner support from open source people by displaying a closed-source mentality (the whole "we have reasons but can't talk about them" bit). In order to build bridges, the first step is open dialog.
GNOME and high-level languages Posted May 12, 2005 18:22 UTC (Thu) by tjc (subscriber, #137) [Link] Just like with KDE, eventually RedHat is going to have to realize they need to ship what their customers' want. Having some secret objection to C# isn't going to cut it. It is hard to garner support from open source people by displaying a closed-source mentality (the whole "we have reasons but can't talk about them" bit).It seems likely that there are legal issues involved here. If you've ever have legal issues, you know rule number one: don't talk about it.
GNOME and high-level languages Posted May 12, 2005 12:16 UTC (Thu) by liljencrantz (guest, #28458) [Link] I am surprised people are just accepting RedHats stance on this. Gnome is one of the largest open source projects around, and RedHat is simply saying that a cool piece of technology can't be included, but they won't say why. This makes it impossible to have a technical discussion of the problem, and thus impossible for the community to solve it. That kind of closed source mentality should not carry _any_ weight in an open source project, even if is coming from a behemoth like RH.
If the good folks at RH signed away their right to even discuss what is wrong with Mono, then they made a _huge_ mistake, and will have to bite the bullet. Either break the NDA or whatever is keeping them from discussing this and risk having to pay millions or accept that Gnome will move on without them. This does not mean Gnome would have to be forked, simply that RH would have to ship a crippled version of Gnome, just like they today cripple Gstreamer and Xmms.
C# patent problem ?? Posted May 12, 2005 13:01 UTC (Thu) by copsewood (subscriber, #199) [Link] It's one thing for Microsoft to publish a language spec as a standards proposal. But have they got patent claims on C#/mono technology users ? They might be most happy for the supposedly free world to get exited about mono if they can raise patent revenue from it from all corporate users behind closed doors.
C# patent problem ?? Posted May 12, 2005 14:30 UTC (Thu) by liljencrantz (guest, #28458) [Link] Patents are not bound to a specific standard. Given that Virtual machines all look quite a bit like each other, no matter if they parse CLR or Java bytecode, arguments about Mono being more 'dangerous' than Java, Smalltalk or Python is mostly FUD.
GNOME and high-level languages Posted May 12, 2005 13:49 UTC (Thu) by hp (subscriber, #5220) [Link] Nobody is just accepting our stance that I see.
My post said simply: if we have to bite the bullet we will bite it. I am not trying to veto what GNOME does.
It's possible we can figure out how to ship Mono eventually, even. But as I said, I don't yet see the light at the end of that tunnel.
GNOME and high-level languages Posted May 12, 2005 13:53 UTC (Thu) by liljencrantz (guest, #28458) [Link] The way I see it, the fact that no Mono applications are included in Gnome means that the foundation is accepting your stance.
GNOME and high-level languages Posted May 13, 2005 0:10 UTC (Fri) by dberkholz (subscriber, #23346) [Link] How about DotGNU?
GNOME and high-level languages Posted May 12, 2005 13:32 UTC (Thu) by jwb (guest, #15467) [Link] This is a very interesting comment and it would be a shame if so few people get to see it. Maybe it could be developed into an LWN article.Instead of picking any one favorite language, why not make the environment language- independent? This is the point of Mono, is it not? The mono runtime can support more than C#. I believe there is already a Python-Mono bridge (there is definitely Python for .NET). Does anyone remember CORBA? I know, stop laughing! GNOME was originally conceived as a language-neutral, network-transparent "object environment". Why can't it be that again, with Mono?
GNOME language independence Posted May 12, 2005 21:20 UTC (Thu) by scripter (subscriber, #2654) [Link] The libraries are where most of the power resides for most programming languages, and without a community, the libraries don't get developed.
So, if my favorite language is lisp (it's not, by the way), but all of the libraries are developed in Python.PARROT (or Python.NET), then the philosophy of the Python community is going to "leak" into my lisp program, and it may not mix according to the lisp community's satisfaction.
There's another least-common-denominator problem. For example, with the .NET CLR, libraries have to use signed integers for compatibility between languages. C# supports unsigned (and even checked) integers, but VB does not. What if all of the libraries were written in VB.NET? It wouldn't be a good thing for security.
What about exceptions? If we have Pascal.NET or Pascal.PARROT, and try to have it call C# libraries that throw exceptions, what do you do? Force Pascal to have exceptions? Perhaps there are solutions to such problems.
Blending the philosophy of separate communities is difficult. People like their communities, and they like the distinct values of those communities. Forcing everyone to to walk like a duck, talk like a duck, and waddle like a duck isn't going to go over well, IMHO.
GNOME and high-level languages Posted May 14, 2005 15:19 UTC (Sat) by ohanssen (guest, #2761) [Link] Good point. CORBA was a good idea and still is (CORBA 3 also includes a component model compatible with EJB). And this is not the only kind of middleware which comes with language independence. Just look at database management systems.
GNOME and high-level languages Posted May 12, 2005 13:41 UTC (Thu) by hp (subscriber, #5220) [Link] Obviously I know my post sounds bad. However, the post is the truth, and that's how I decided what to say, not "what sounds good." Sometimes reality isn't what one would prefer.
Re: Python, Red Hat writes basically everything GUI in PyGTK: our installer, config tools, etc. - we have used PyGTK for years, it was the first viable language binding for GNOME. I would certainly support using it in GNOME.
GNOME and high-level languages Posted May 12, 2005 14:58 UTC (Thu) by liljencrantz (guest, #28458) [Link] I would very much like to see a solution where code included in the default Gnome desktop could be written in any language so long as there was a standard way to automatically generate high quality bindings for any other supported language.
I see three ways of doing this:
1) Make sure you can always generate C bindings, and use one of the binding generators to generate all other bindings. If I'm not mistaken, Java, Mono and Python should all be able to do this. Java has a bit of a head start because you should be able to wrap something around CNI to move from C++ to C and make some form of bridge that removes the idiotic Java style strings, and makes sure the Java GC interacts nicely other GCs and with non-GC languages.
2) Try using Corba/Orb or some messaging bus. This has been tried a large number of times, and it always ends up as a spectacular failure. But maybe a less ambitious approach, like specifying a communication protocol on how to talk to libraries over DBUS, would have a chance.
3) Pick the one true VM, and make everything run on it.
GNOME and high-level languages Posted May 12, 2005 21:47 UTC (Thu) by ncm (subscriber, #165) [Link] "I would very much like to see a solution where code included in the default Gnome desktop could be written in any language..."Meaning, I have to have VMs for every godforsaken language always running because programs are cobbled together out of bits that individually need this one or that one, but of course never the same one. Any given program might need any mix of them, and who can keep track? No thanks. As it is, with C and C++ libraries, programs don't need any particular runtime support environment, and everybody (even the godforsaken) can call them. You can write C# programs, and I can ignore them. You can write Java programs, and I can ignore them too. I'm never in danger of needing to install a JVM just because, say, some bloated spreadsheet-cum-word processor project suddenly discovered a corporate need ignore all the low-impact database engines in C, and call up a slow and immature Java database instead.
GNOME and high-level languages Posted May 12, 2005 23:30 UTC (Thu) by liljencrantz (guest, #28458) [Link] I want software like Beagle, F-Spot and Tomboy to be integrated with my desktop. As for word processors, I use emacs and TeX, so I don't care what features Open office includes. But as far as I understand, Oo.o actually starts up much _faster_ in the new, evil mega-Java-bloatware version than it ever did before.
If you dont want new, cool and inovative software, but feel the need to use a slow, bloated C++-based office app like Oo.o 1.x, you and I clearly want different things out of our computers.
GNOME and high-level languages Posted May 13, 2005 6:18 UTC (Fri) by ncm (subscriber, #165) [Link] If you want programs like Beagle, F-Spot and Tomboy integrated, by all means write programs like them in an unencumbered language, and integrate them. You certainly don't need one of these crippled languages to write cool and innovative software.If OO.o starts up faster than before, you can be certain it's not because they also have to start up a VM on top of everything else. I'm betting they don't start that up until you call something that needs it, or they start it in background so it looks like it's all up while that stuff is still flapping to get airborne. (BTW, doesn't Emacs define bloat any more?)
GNOME and high-level languages Posted May 13, 2005 7:24 UTC (Fri) by liljencrantz (guest, #28458) [Link] I strongly belive that a modern high level language with garbage collection, object orientation, exceptions and such features make high level GUI software easier to write. Is there anything in Beagle that would be impossible to write in C? Of course not. But it would have taken more time, and given that time is finite, this means that the program would have less features, or maybe it wouldn't even have been released.
Allowing people to choose what language to code in allows them to be more productive, since different people like different languages, and different problems are suited to different languages. You are right that if we where to allow the core libraries to be written in Python, Java, Ruby and C#, they would be dog slow. To me, this means that the VMs have to be fixed to become leaner, not that those languages should be forbidden.
BTW, don't think that I don't like older languages like C or C++. I love C and I use it often. I just love the freedom to choose programming languages more.
As to your comments about emacs and bloat, emacs (CVS version 22.0.50) takes about 1.5 seconds to start up on my computer. This is obviously pretty bloated and far to long to be acceptable. I just tried starting OpenOffice (v1.1.2) a few times, it took about 4 seconds on average. So no, emacs does not _define_ bloat, and the fact that you ask this implies that you don't even use OpenOffice, but still you complain about what it does and how it does it.
GNOME and high-level languages Posted May 13, 2005 13:22 UTC (Fri) by ncm (subscriber, #165) [Link] Irony is lost on some people. Anyway, who's this "we"?
GNOME and high-level languages Posted May 13, 2005 16:11 UTC (Fri) by ncm (subscriber, #165) [Link] By the way, C++ is unencumbered, supports OO anywhere it's useful, has exceptions that actually work (i.e. actually reduce the amount of error-handling code in your program, instead of multiplying it), and provides the benefits of garbage collection without its ... problems.
If you're talking about modern, though, you neglected to mention compile-time type inferencing. The MLs have it, Haskell has it, C++ has it, Java and C# don't. (What good is it, anyway? It enables writing libraries that are more powerful than is possible in weaker languages.) As modernity goes, Java 1.5 and C# are stuck at about 1991; Java 1 was about 1986.
On cooperation Posted May 12, 2005 7:07 UTC (Thu) by davidw (subscriber, #947) [Link] This is interesting:
http://mail-archives.apache.org/mod_mbox/incubator-harmon...
The previous Harmony Project Posted May 12, 2005 10:18 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Funny this isn't mentioned anywhere:
GNU Harmony was a project to re-implement the (then) non-free QT library. In the end QT was released.
The previous Harmony Project Posted May 12, 2005 11:19 UTC (Thu) by petebull (guest, #7857) [Link] As I read the Headline, I had this old project in mind.And there I thought: What happened so they dug out this project, again? I'm glad I erred.
A need? Posted May 12, 2005 13:43 UTC (Thu) by ncm (subscriber, #165) [Link] Joe writes in the article, "There is certainly plenty of need for an open source Java in the open source community."This drastically overstates the case. Certainly there is a desire in some quarters for a free Java. If there was any actual need we would already have it, long since. The fact is that Java doesn't solve any problems that Free Software has. Any value it is claimed to have for application development is already provided by C++, as anyone may see by surveying the wealth of programs in common use written in it. (You probably don't know when you are running a C++ program. Could you ever say that about a Java program?) That OO.o has been adding Java components to its C++ program says a great deal more about Sun's strategic lock-in plans than it does about any need for Java. Whence this desire for Java, in those quarters? From here it looks like it's mainly proprietary software vendors who would like their customers to remain locked into the Java platform. If their customers are moving to Linux, they want to collect rents there, too. Those customers who break free of Java find themselves with no need for that massively bloated "middleware" their erstwhile brethren have grown used to paying for.
A need? Posted May 12, 2005 21:50 UTC (Thu) by jonabbey (subscriber, #2736) [Link] As a free software author writing in Java (http://www.arlut.utexas.edu/gash2/), I think you're way off base, here.
Programming in Java is an order of magnitude faster, simpler, and more reliable than programming in C++. There absolutely is a performance penalty to pay for that, and Sun has let idiotic bugs languish for years unfixed, in the quest to be platform-independent / platform-definining.
But! I would rather saw on my wrists with a butter knife and then apply lemon juice and salt than to try and write something like our software and then try to run it on Windows, Mac, and the various Unices.
So don't think you're doing anyone any favors by trying to claim that C++ is any sort of replacement for Java. It's not.
A need? Posted May 12, 2005 21:51 UTC (Thu) by jonabbey (subscriber, #2736) [Link] Er, than to try to write something like our software in C++, obviously.
A need? Posted May 13, 2005 5:46 UTC (Fri) by ncm (subscriber, #165) [Link] So, Jon, are you saying your software is an order of magnitude harder to make work than everybody else's? The Boost library provides all manner of encapsulation of the differences between various targets (file system, socket semantics, buggy-as-hell compilers), along with encapsulating facilities impossible to express in Java. I doubt you've looked at C++ since the mid 90s; things are much, much better now.For example, it's been, literally, years since I last coded a "delete" statement, or any semantic equivalent. Java's garbage collection would be not only useless to a modern C++ coder, but an active nuisance interfering with reliable encapsulation of resource management. (Not even world experts -- e.g. Hans Boehm, Herb Sutter -- can elucidate how finalizers might be written so as to be reliably safe to run.) To claim an order of magnitude difference of effort between coding Java and C++ (for those tasks Java can address at all) is ludicrous on its face. It's common to claim that coding small programs in Python, and where performance doesn't matter, is three to five times quicker than in C++. That's not implausible. However, (1) Java is no Python, and (2) it's in the nature of easy problems to be easy. For hard problems you need a powerful, expressive language to encapsulate abstractions, and Java entirely fails in that. For what is Java the right language? For easy problems Python (or practically anything nimble) is right. For hard problems, C++, or ML, or even Common Lisp is right. Is there supposed to be a hair-thin sliver in the middle where Java fits, too weak and slow for big problems, too clumsy for small ones? Take a look at Monotone for a substantial but not-incomprehensibly-large example of a cross-platform C++ program. See how much effort has really gone into porting it among Linux, Unixes, Win32, and Macosix. No, C++ is no replacement for Java. C++ was here first. It graduated from mere "object-orientation" -- where Java remains mired -- in the mid-'90s. Rather: Java would be an entirely inadequate replacement for C++. The world does need a simpler but at least equally powerful replacement for C++, and will get one someday (certainly C++0x will come out first) but Java was never even in the running. (Java might, finally -- if it doesn't fade away when Sun gives up and drops it -- supplant COBOL; the user populations and application domains are similar.)
A need? Posted May 13, 2005 13:57 UTC (Fri) by jonabbey (subscriber, #2736) [Link] Does Boost provide a portable GUI? An RMI-like distributed object protocol with distributed GC? Thread safe libraries for absolutely everything? Does programming with Boost (including to the GUI layer) guarantee that I'll never have to see a pointer that might be mistargeted, allowing my encapsulation to be violated?
Does it protect me from all worries about memory ordering? Do the Boost memory management tools encapsulate calls to arbitrary libraries sufficiently that I get Java-like guarantees of memory management everywhere? Does Boost prevent me from ever having to worry about differences between operating systems? Does Boost guarantee that I'll never get a segfault or other low-level error that is not caught and processed by my defined exception handling mechanisms? Does Boost have a Java-like finally clause that is actually reliable?
I don't deny that programming in C++ has gotten more civilized since Java came out, and I don't deny that people are doing large, reliable programs in C++.
I still maintain, however, that our software could not have been done in C++ in the timeframe that it was written with the limited man power with which it was done.
And I wonder what people are talking about who claim that C++ is wonderful so long as you don't touch all of these pieces, and follow these high level coding principles without fail. I could say the same about Assembly, couldn't I? Talk about powerful..
In any event, if you are offering to personally rewrite our software in C++ so that we can be finally rid of the plague that is Java, please email me.
Otherwise, I'll maintain my position that there is a purpose and a role for Java, and I'l continue to insist that we are better off for having it.
Lock-in Posted May 13, 2005 17:19 UTC (Fri) by ncm (subscriber, #165) [Link] I know of several portable GUI packages for C++. Take your pick. Likewise, communications support. Thread-safety is the norm in C++ libraries. One doesn't encounter pointers much, so "mistargeting" that "breaks encapsulation" (whatever that means) has never been a problem.
I don't find myself worrying about "memory ordering" either. Fortunately, C++ offers much better than mere "Java-like" guarantees of memory management -- you get guarantees of general resource management that are impossible for Java to provide, even (or perhaps especially) with finalizers. No language can guarantee against failures, and no mere language can eliminate differences between operating systems. It is most fortunate that C++ lacks Java's "finally" clause: to my knowledge that is Java's greatest single failure. (Finalizers might be worse.) The whole point of exceptions is to allow error-handling code to be concentrated at choke points, minimized, and easily exercised. "Finally" clauses, instead, multiply it and distribute it throughout the program.
I don't hear anybody saying C++ is wonderful. Powerful, yes. Fast, yes. Standard, yes. Assembly language or, equivalently, Java, cannot become powerful by following coding principles. I expect Ganymede could have been written in C++ in much less time than it took in Java; I'd guess half.
The "purpose and role" of Java is lock-in. By that standard it is very successful. Many people cannot imagine any path by which their organization might break out of the Java orbit.
Lock-in Posted May 13, 2005 17:37 UTC (Fri) by jonabbey (subscriber, #2736) [Link] I know of several portable GUI packages for C++. Take your pick. Likewise, communications support. Thread-safety is the norm in C++ libraries. One doesn't encounter pointers much, so "mistargeting" that "breaks encapsulation" (whatever that means) has never been a problem. Do these GUI packages for C++ work on Mac (OS 9 and OS X), Linux, Windows, OS/2, AIX, etc.? We've run the Ganymede client on all of these systems, and more, without so much as a recompile. By 'breaking encapsulation', I'm referring to the fact that, in Java, if I declare a variable private in a class, nothing outside of that class can ever touch it. It's impossible to craft a pointer to the private variable (on purpose or on accident), so it's impossible to read from it or write to it. There's no possibility of my encapsulation guarantees being violated. If that variable gets written, I know exactly where the code must be that did it. No chance of one portion of our large body of code accidentally scribbling on another portion, no matter how badly we try to screw things up in our human frailty. I don't find myself worrying about "memory ordering" either. Fortunately, C++ offers much better than mere "Java-like" guarantees of memory management -- you get guarantees of general resource management that are impossible for Java to provide, even (or perhaps especially) with finalizers. No language can guarantee against failures, and no mere language can eliminate differences between operating systems. It is most fortunate that C++ lacks Java's "finally" clause: to my knowledge that is Java's greatest single failure. (Finalizers might be worse.) The whole point of exceptions is to allow error-handling code to be concentrated at choke points, minimized, and easily exercised. "Finally" clauses, instead, multiply it and distribute it throughout the program. Yes, Java has poorly thought out finalizers. The rest of these statements are off-target. No, Java can't guarantee against the power plug being pulled, the CPU glitching, or memory being exhausted, but it can guarantee that everything else will result in catchable exceptions. And finally is enormously useful, especially in multithreaded code, in that it can provide guarantees that execution will not leave a block without releasing locks, and so forth. Finally is not about enabling sloppy exception management, and the fact that you believe that to be the case shows that you don't know Java as well as you appear to know C++. My code runs for months on end. If I have made a mistake and a thread runs into an exception condition, that thread unwinds, the exception is logged, and the Ganymede server just keeps going. No seg faults, ever. No buffer overruns. None of that. Not ever. I expect Ganymede could have been written in C++ in much less time than it took in Java; I'd guess half. Being the author of Ganymede and knowing its code rather well, I don't see how that could possibly be true. Definitely not ten years ago when it was first written. Today, perhaps, the design could be reworked in such a way that comparable functionality could be layered on top of a whole variety of independent libraries, frameworks, and external services, but to claim that we could get the portability as well as the reliability that we get with Java with a comparable effort in C++ seems wildly unlikely.
Lock-in Posted May 13, 2005 19:15 UTC (Fri) by ncm (subscriber, #165) [Link] "if I declare a variable private in a class, nothing outside of that class can ever touch it"... unless you call a library. "Yes, Java has poorly thought out finalizers." Worse. To this day nobody has figured out how to specify finalizers so they would not be poorly thought out. "No, Java can't guarantee against the power plug being pulled, [etc.]" More to the point, it can't guarantee that logic errors, infinite loops, rooted memory leaks, specification errors, or any of a host of other coding ills will result in a nice exception, any more so than in any other language. C and C++ code running for months on end is the norm. "... finally is enormously useful, especially in multithreaded code, in that it can provide guarantees that execution will not leave a block without releasing locks," "Finally" is a failure precisely because you have no choice but to write it out everywhere there's something to clean up. Each place you write it out is a breeding ground for bugs, because each has to be exercised separately. In C++, destructors clean up, so there no need for "finally". Java lacks destructors, so must make do with "finally". But we digress...
A need? Posted May 21, 2005 9:22 UTC (Sat) by renox (subscriber, #23785) [Link] > Does Boost prevent me from ever having to worry about differences between operating systems?
*Cough* Boost doesn't but Java doesn't either!!
As for the C++ vs Java, I hate C++ and I dislike Java (even Sun can't make fast Java apps: in Solaris9, the java tools used to managed the OS are 10 tomes slower than the tools that existed before), so..
A need? Posted May 13, 2005 15:41 UTC (Fri) by tjc (subscriber, #137) [Link] > For what is Java the right language?Internal applications in larger companies and organizations. These apps are often quite large, and the business requirements may change frequently. And they're often written by programmers with modest skills. Java works quite well for this sort of thing.
A need? Posted May 13, 2005 2:47 UTC (Fri) by kh (subscriber, #19413) [Link] To me, Java has always seemed like the answer to the question "What is a Perl programmer to do who does not wish to share his source code?". Free software does not have the same portability issues that proprietary software suffers from, or at least it should not. It seems to me that too much effort is made in free software projects in working with proprietary software. I guess it makes sense for the mono project in providing tools to help companies migrate to free software platforms, but I don't understand putting such an effort in implementing java components in openoffice.
|
|||||||||||||