"Which means that about the only thing that they could get from liberalization is to be able to skip testing." So it doesn't seem to be such a big issue after all.
That's a huge issue, for several reasons.
First, it effectively gives Sun a veto over any implementation they don't like, because they administer the tests. There is no defined process by which you can appeal their decision.
Second, Sun can change their mind at any time: they own specifications, they own the code everybody uses to implement it, and they can change how they license that. One scenario under which that would happen is if Sun goes out of business or gets acquired--the new owner may want to take Java in a different direction.
Third, being able to make incompatible changes is exactly what open source is about. Large parts of the Java platform just suck and are begging to be removed and replaced with something better.
Isn't the availablity of the source most important? Or perhaps I'm misunderstanding something...
Availabilty of source by itself is actually dangerous in the case of Java: not only are you restricted in what you can do with it, if you look at it, you can't even work on competing implementations.
Open source is only useful if you can modify it freely and redistribute your modifications.
Sun's Java licenses not only prevent you from freely modifying and redistributing Sun's code, they even prevent you from writing your own, modified version of Java independently and redistributing that.
JessLeah is totally wrong on this point: the reason that the GNU Java projects are not "Java proper" is not that Sun didn't make them, but that they are immature and don't completely implement that Java spec.
So, you agree: the only complete implementations of Java are from Sun, which makes those implementations about as proprietary as Microsoft Windows.
Now, it is Sun who keeps claiming that Java is somehow open. Well, the burden of proof to support those claims is on Sun. If, after nearly a decade, there are no independent Java implementations around, we have to assume that such implementations simply aren't feasible. Whether the specifications permit independent implementations in theory is academic: if such independent implementations don't exist, Java just isn't interesting for either open source users or commercial users that don't want to be tied to the (mis-)fortunes of a single company.
In different words, if Sun goes out of business (and there is a good chance they will), you will likely end up with an orphaned, unsupported platform whose maintenance nobody can take over. That is exactly what OSS and open standards were meant to avoid, but Java isn't delivering.
OK, here's the deal with the Java source code: You can get it. You can modify it. You can redistribute it. [...] It has to pass Sun's compatibility tests.
What the Java licenses come down to is that Sun retains control over Java: they can kill anybody who doesn't fit into their business plans, and they can kill any modifications to Java that they don't like. Furthermore, once you look at their source code, they own you.
And, as a purely practical matter, there are no open source Java implementations, there are only incomplete and incompatible bits and pieces. And that's not because open source developers can't handle a project like that, it's because Sun has set things up that way.
Open source should give up on Java: Sun has proven to be a dangerous and unreliable partner, and it would be best to move on to something independent of that company.
That question itself points out a core problem with Java: it isn't a standard, it is just an implementation: Sun's implementation (and its derivatives: IBM, Blackdown, Apple). None of the implementations (gc, kaffe, waba) that don't derive from Sun's are even close to being compatible.
Before we can talk about Sun open sourcing their Java implementation, we have to talk about making Java an open standard. Right now, it is further away from that goal than even Microsoft Windows is.
In any case, it doesn't matter anymore. I doubt that it makes much of a difference at this point what Sun does with the Java license. I think the world is going to move away from Java over the next few years--Sun screwed up.
Sun has had almost a decade to follow through on their initial promise of submitting Java to a recognized, existing standards body and they haven't done it. Instead, they have set up a process in which their customers and users do enormous amounts of work for them and Sun reaps the benefits and have the final say.
Most disturbingly, Sun still has complete ownership of JCPs (read the license agreement, say, for JCP 32).
Sun has had their chance. Java has been a positive influence on the industry, but it is time to move on to something else, both for legal reasons and for technical reasons.
Perhaps even more impressive than the improved bit rates is that the source code actually looks competently written and is small. It also seems to use C++ in a reasonable way: to achieve just around the right amount of abstraction, without building a useless, general framework.
Video codecs typically have ``sweet-spots'' for resolution and bitrate.
Well, if your video compressor has notions of "8x8 blocks" and "16x16 blocks" hardwired into it, that is not exactly surprising. That's the kind of technology that current codecs use.
If they use wavelets and motion compensation correctly, there is no reason why it shouldn't scale well across a large range of resolutions.
C++ is just as efficient and easy to use in the vast majority of memory management cases as Java or C#.
But it isn't about ease of use. It's about safety. C++ isn't safe and it cannot be made safe without garbage collection.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs
Safety is not a property of programs, it's a property of languages and runtimes. A safe language ensures that no piece of memory can be accessed or modified in a way that violates the type system, and it catches all such attempts. Any memory management error anywhere in a C++ program may result in the unexpected alteration of data in any module anywhere else in the C++ program.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs. One reason for this is that the C++ compiler is capable of forcing usage patterns in the manner described above.
You may claim that proper use of C++ abstractions lets you avoid many bugs. That may or may not be the case, but most C++ programs contain large amounts of code over which you have no control. I don't want my bank statement to be off by $1000 because someone didn't abstract properly in the printer driver.
And, in fact, most C++ abstractions are merely advisory and no guarantees. Just because you tie methods to an object that you intend to be stack allocated doesn't mean that I won't allocate it on the heap and fail to release the lock because of that.
So you would rather that they are trying to market and sell Windows 95? I remember back trying to use that crap (along with Windows 3.1, 98, etc) and that was the reason I switched over to Linux (only temporarily, though).
No, I would rather I wasn't subject to the output of Gates's personal quest of discovery through the world of computer science and software engineering. People knew how to design better systems than Windows XP when Microsoft was founded and when Gates was still getting the bugs out of MS Basic.
I know Windows isn't perfect, but it is alot more stable and reliable than the old incarnations.
After two decades, and billions of dollars of development, it would be nearly impossible for it not to be. And with all that effort, Windows finally manages to be almost as good as UNIX, which, frankly, isn't exactly exciting in and of itself. By all rights, we should really have HAL by today, instead we get Clippy and pop-up ads.
Some people might not like the constant updates (not referring to patches), but alot of the time MS is putting in an update at the request of certain customers, and you can't fault them for putting in features that their customers require.
I don't know what you mean by "fault". It is bad engineering and it is anti-free market. But Microsoft can't help it--they can hardly break themselves up for the good of everybody else as long as the money keeps coming in; at fault is ultimately the anti-trust division, which lets the current state of affairs continue.
There is always enthusiasm in our business for new concepts. So-called 'free software' is the latest new thing.
It's only been around since the 1960's.
In the event of needed enhancements or fixes, the Linux development community, no matter how well intentioned, simply cannot advance Linux the way we can - and must - innovate in Windows.
Microsoft's constant "advancements" are actually on reason I don't like Windows that much. UNIX did a pretty good job 30 years ago, and it still does.
It is true that even though I've programmed in RT environments, I've never used a RT GC, I'm just relaying the comment that both the C and C++ committee have delayed adoption of a GC standard for those two languages and that a serious issue is real-time performance. The C/C++ standards committees are not a bunch of idiots so I take the view that there must be something true in there.
And the pope used to say that the earth was a the center of the universe. Well-known people have their hangups, just like everybody else, and particular religions gather in their own churches.
You are correct that for some hard real-time problems even using malloc is a no-go area.
Using "malloc" is a "no-go area" in each and every hard real-time problems: "malloc" makes no guarantees whatsoever about latency. The only way you can call "malloc" in a hard real-time system is if you know its implementation and know that it actually makes hard real-time guarantees. But the
If you need a GC for your language to be safe then you need some other automated mechanism to close down open resources for you as well. GCs are not the be-all and end-all of language safety.
Oh, but it is. Leaking a file descriptor is not a question of runtime safety, it's just a bug. However, deallocating memory that is still in use has unpredictable and undefined consequences, and that is a violation of runtime safety.
Why do people get so upset about "the government" doing this?
It's worth worrying about things "the government" does if nobody else can do them. But any private company or individual can do this, and it's gotten cheap enough that many probably will, for various reasons.
You just have to assume that when you drive around in your car, anybody can track your license plate. Whether that's "anybody" or "anybody but the government, who can then buy it from private companies anyway" makes very little difference.
IBM wrote a JVM. They also wrote WebSphere. What part of the Java platform have they not independently implemented?
Most of the libraries, foremost Swing.
(Incidentally, IBM probably can't open source most of the libraries they have written because of their contractual obligations to Sun.)
all the anecdotal evidence I have heard (mostly here on Slashdot) is that in practice they do follow all the recommendations of the JCP. (Of course, they are part of it, so they could just veto things from within.)
But it's not the recommendations I am concerned about, it's the ability to do complete and independent implementations. That ability has never been tested.
Furthermore, Sun doesn't have to assert their rights if they don't want to, and they have had no reason. Gcj and Kaffe may well violated lots of Sun intellectual property, but they are not a useful substitute for Sun Java, so Sun hasn't had to do anything about it. That may well change if gcj+SWT+Eclipse becomes the new standard.
So everybody "changing the JCP specifications" already knows the implementation. Anybody can join the JCP for free to become part of the everybody. So anybody can learn the implementation. If the information about the implementation is that available, then more formal specifications may not be needed.
Trouble is that if you know the implementation, you can't do a clean-room implementation anymore.
I expect to be programming Java later this year. The project will start in Java because I can produce the prototype using Java much faster than any other language. Some versions of the production release may be written in C once performance is the priority, but that will never happen without a proof-of-concept.
And, strange as that may seem, I develop in Java myself still. But I am quite aware that doing so is really little different from developing in Microsoft Windows or.NET: they are both highly proprietary platforms.
On the other hand, I scrupulously avoid looking at Sun source code or getting entangled in the JCP or other processes: the legal implications of doing that are disturbing.
Don't blame Sun just because, like many other projects, OSS constantly has to play catchup
I don't blame Sun for the degree to which open source is able to clone Java, I blame them for making it a contractual requirement that any clone keeps up with them, and I blame them for not issuing a fixed standard and sticking with it. Besides, it is not just OSS that hasn't been able to catch up--all commercial efforts at making an independent Java implementation have died. People can't catch up with Sun for the same reason they can't catch up with Microsoft: both companies define a system and keep changing it rapidly.
That's one of the attitudes that really ticks me off about the OSS community, or anyone that copies rather than creates. They don't give enough credit to the people they are copying or acknowledge all the resources being given to them.
Sun hasn't created squat with Java, nor have they given much credit. Java is a jumble of decades old technologies, cloned and copied from all over the place.
As for the resources, if Sun doesn't like the way they are being treated, they can just stop giving, as far as I'm concerned; Sun's current behavior vis-a-vis OSS is a bad deal for OSS.
If it isn't clear to everyone yet that the OSS community has it in for Sun because Linux want's to take over the market share that sun has, all these open letters, articles, etc. should be proof of that.
Of course, OSS wants to take over Sun's market, and nobody has made a secret of that for the last several decades. If that comes as a surprise to anybody, at Sun or elsewhere, they really haven't been paying attention.
Call me silly, but if some company had donated so much money and code to my community and I dissagreed with what they were doing I would bring it up with them directly instead of in a public way to try and discredit them.
First of all, Sun did what they did for their own reasons; nobody has any obligation to be grateful for them. Donating software doesn't buy you any latitude to screw OSS in other ways.
Second, people have brought this up with Sun over and over again--not just OSS folks, but also companies, both big and small. Sun doesn't give a damn and they tell people to go get lost. Just look at Sun's response to IBM for a recent example.
Third, Sun is discrediting themselves: they are making promises and not following through, they are misrepresenting products as "open" that aren't, and they are skirting GPL requirements on conspicuous displays of licenses.
OS, the new FUD machine.
I fail to see the "fear, uncertainty, and doubt" in that. When I say that "Sun sucks", I think that a pretty clear, certain, and definitive statement.
They probably detect whether the ad's content was accessed by the user, either by tracking things on the web server or with JavaScript. If that becomes commonplace, ad-blockers will just download the content and then discard it.
Now, what would be a really nifty trick is if they manage to detect that lynx blocks pop-up ads and put a translucent ad on top of the lynx text.
Sun did not submit Java to an existing standards-approving organization, but they did set up the JCP. Java (excl. J2ME, which has its own list) is controlled by Apache, Apple, BEA Systems, Borland, Fujitsu, HP, IBM, IONA, Macromedia, Nokia, Oracle, SAP, SCO, Sun Microsystems, and 2 private citizens. Thay have approved all of Sun's recent releases and direct the roadmap for new enhancements. Why is this not good enough?
If the JCP were legally equivalent to one of the existing standards bodies, then Sun could have just submitted to them.
JavaTM API for XML Parsing Specification ("Specifica-tion") Version: 1.0 Status: FCS Release: March 2, 2000 Copyright 1999-2000 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303, U.S.A. All rights reserved.
NOTICE The Specification is protected by copyright and the information described therein may be protected by one or more U.S. patents, foreign patents, or pending applications. Except as provided under the following license, no part of the Specification may be reproduced in any form by any means without the prior written authorization of Sun Microsystems, Inc. ("Sun") and its licensors, if any. Any use of the Specification and the information described therein will be governed by the terms and conditions of this license and the Export Control and General Terms as set forth in Sun's website Legal Terms. By viewing, downloading or otherwise copying the Specification, you agree that you have read, understood, and will comply with all of the terms and conditions set forth herein. Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification solely for the purpose of creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification, as defined by Sun, without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by Sun in the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages (or other packages defined by Sun); (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification.
Apart from the fact that the document is covered by copyrights, patents, and that you can do almost nothing with it, note that it is Sun, not the JCP members or some other organization, that owns all the rights.
It also tells you who has the final word over compliance: Sun.
And it spells out conditions that are almost impossi
Python (pre 2.0) used to do only refcount, and did it much better than Java (using GC) in all respects except thread friendliness. Modern python (2.0 and beyond) does both -- but it's extremely rare for the gc to be needed at all.
That's a myth. Python reference counting doesn't even get close to the performance of a reasonable garbage collector. Even the Python implementation as it is can be speeded up by replacing its reference counting scheme with the Boehm garbage collector (if you do it correctly).
It was mentionned earlier that reference counting was pretty good, but had a few drawbacks when it came to cycles and multi-threading.
Reference counting is not a "pretty good" technique: it is very hard to implement well, and the implementations everybody uses are inefficient and don't even handle the general case.
In the description they give, they mention that reference counting GC can represent managed objects by directed graphs. I know there exists algorithm to find cycles in such graphs. So I suppose these could be applied to this problem. Other proposal are to use a tracing GC to detect them.
The two solutions amount to roughly the same thing.
Reference counting OTOH seems to allow the cleanup to continually add a little bit of overhead to the system but nothing which will bring the whole thing to a grinding halt before allowing it to go on. What have I missed?
Normal reference counting does not at all release things "continually": when you lose the last reference to a huge, complex data structure, you may end up doing millions of deallocations at once. To cope with that, you need to do a lot more work. And when you are done, you end up with an implementation that's complicated and still doesn't solve the general case (cycles), so you need a garbage collector anyway.
The simplest available algorithms to do gradual cleanup of memory are, in fact, certain kinds of garbage collection algorithms.
It might be useful if some languages had an optional method of hinting that an object should be garbage collected soon
Good garbage collected languages let the programmer give extensive hints to the garbage collector about locality, expected lifetime, desired latencies, mutability, and other relevant properties. That kind of functionality goes back to at least the early 1980's. Over the last two decades, however, some garbage collectors have gotten so good that they don't need a lot of those hints anymore.
Whether giving hints to the GC would help Sun's Java implementation is hard to tell. It might or it might not.
Stack-based languges like the C family (including Java) don't need GC to operate correctly
Correct memory management in the presence of heap-allocated mutable objects require garbage collection, even in C.
There simply is no way around it: you can allocate an arbitrary graph of objects, and what can be freed depends on what is reachable from the roots.
And if garbage collection isn't built into the language, then the language has to be unsafe, like C is.
So, if you want a safe language with heap allocation of mutable objects, you need garbage collection. Lexical closures have nothing to do with it.
Which means that locally-declared variables have to keep existing after the creating function returns, even if the coder can't get to them anymore. And the only way to do that is to have the runtime system manage its own heap, which means a garbage collector.
There is no such requirement: you can deallocate closures manually just like any other data structure. But once people get to that point, they generally realize that it's a bad idea.
this article sweeps under the rug most of the reasons why languages dependent on garbage collection have always failed to find much deployment in industrial settings.
For the same reason people in industry have kept programming in Cobol and Fortran, and for the same reason they keep producing software with all sorts of problems, bugs, and limitations.
A previous poster noted that most GC algorithms are distinctly unfriendly to virtual memory systems. They usually have similar problems with cache locality, which can result in an enormous slowdown, regardless of the time actually spent in the GC itself
Not true at all. Generational collectors generally achieve far better locality than malloc-style allocators.
A more fundamental problem is that memory is only one of many resources a typical industrial program must manage. GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C.
Fundamentally, the point behind GC is not to make your life easier, it is to make it possible for the language to be safe. Without GC, a language with heap allocated mutable data structures just cannot be safe. GC generally cannot reliably manage any other resources besides memory and it is not meant to.
Given a resource management regime that can handle all these other important resources, as is commonly practiced in C++, memory becomes just another resource.
But memory isn't just any resource, memory is a resource that can contain machine pointers to other memory (as well as references to other resources).
The problem of resource management for memory is that of arbitrary directed graph reachability. And that is exactly the problem that a garbage collector solves, as efficiently as possible.
A language that lacks the tools necessary to implement such a regime needs GC, so the presence of GC may actually (as in the case of Java) indicate a fundamental weakness in the language.
C++ solves a common but limited subset of the resource management problem and then just declares victory. And even that false victory is not very satisfying because in order to achieve it, C++ has sacrified runtime safety. (In fact, with that choice, it has also sacrificed efficiency, but you aren't going to believe that no matter what I say.)
There's a way to avoid many mallocs/frees all at the same time, which is to use a memory pool and have some object look after it. Allocations usually come from an already allocated pool of memory, deallocations are simply the setting of a flag.
Yes, and the same technique works in garbage collected systems and has been used for pretty much as long as garbage collectors have been around. Good garbage collectors actually give you extensive APIs to manage areas and pools in a way that the GC knows about and can help you with, but you can do it "by hand" in even the simplest of them.
This technique is used by KDE. It's all done behind the scenes, so as a developer, you don't need to worry about it too much.
It's unclear that it's a good idea for something like KDE to do this because many malloc implementations already do it for you. Building this sort of functionality in user code generally does a worse job than when it's integrated into the memory allocator.
Slashdot Mirror
"Which means that about the only thing that they could get from liberalization is to be able to skip testing." So it doesn't seem to be such a big issue after all.
...
That's a huge issue, for several reasons.
First, it effectively gives Sun a veto over any implementation they don't like, because they administer the tests. There is no defined process by which you can appeal their decision.
Second, Sun can change their mind at any time: they own specifications, they own the code everybody uses to implement it, and they can change how they license that. One scenario under which that would happen is if Sun goes out of business or gets acquired--the new owner may want to take Java in a different direction.
Third, being able to make incompatible changes is exactly what open source is about. Large parts of the Java platform just suck and are begging to be removed and replaced with something better.
Isn't the availablity of the source most important? Or perhaps I'm misunderstanding something
Availabilty of source by itself is actually dangerous in the case of Java: not only are you restricted in what you can do with it, if you look at it, you can't even work on competing implementations.
Open source is only useful if you can modify it freely and redistribute your modifications.
Sun's Java licenses not only prevent you from freely modifying and redistributing Sun's code, they even prevent you from writing your own, modified version of Java independently and redistributing that.
JessLeah is totally wrong on this point: the reason that the GNU Java projects are not "Java proper" is not that Sun didn't make them, but that they are immature and don't completely implement that Java spec.
So, you agree: the only complete implementations of Java are from Sun, which makes those implementations about as proprietary as Microsoft Windows.
Now, it is Sun who keeps claiming that Java is somehow open. Well, the burden of proof to support those claims is on Sun. If, after nearly a decade, there are no independent Java implementations around, we have to assume that such implementations simply aren't feasible. Whether the specifications permit independent implementations in theory is academic: if such independent implementations don't exist, Java just isn't interesting for either open source users or commercial users that don't want to be tied to the (mis-)fortunes of a single company.
In different words, if Sun goes out of business (and there is a good chance they will), you will likely end up with an orphaned, unsupported platform whose maintenance nobody can take over. That is exactly what OSS and open standards were meant to avoid, but Java isn't delivering.
OK, here's the deal with the Java source code: You can get it. You can modify it. You can redistribute it. [...] It has to pass Sun's compatibility tests.
What the Java licenses come down to is that Sun retains control over Java: they can kill anybody who doesn't fit into their business plans, and they can kill any modifications to Java that they don't like. Furthermore, once you look at their source code, they own you.
And, as a purely practical matter, there are no open source Java implementations, there are only incomplete and incompatible bits and pieces. And that's not because open source developers can't handle a project like that, it's because Sun has set things up that way.
Open source should give up on Java: Sun has proven to be a dangerous and unreliable partner, and it would be best to move on to something independent of that company.
Please enlighten me? Why GPL Java?
That question itself points out a core problem with Java: it isn't a standard, it is just an implementation: Sun's implementation (and its derivatives: IBM, Blackdown, Apple). None of the implementations (gc, kaffe, waba) that don't derive from Sun's are even close to being compatible.
Before we can talk about Sun open sourcing their Java implementation, we have to talk about making Java an open standard. Right now, it is further away from that goal than even Microsoft Windows is.
In any case, it doesn't matter anymore. I doubt that it makes much of a difference at this point what Sun does with the Java license. I think the world is going to move away from Java over the next few years--Sun screwed up.
Sun has had almost a decade to follow through on their initial promise of submitting Java to a recognized, existing standards body and they haven't done it. Instead, they have set up a process in which their customers and users do enormous amounts of work for them and Sun reaps the benefits and have the final say.
Most disturbingly, Sun still has complete ownership of JCPs (read the license agreement, say, for JCP 32).
Sun has had their chance. Java has been a positive influence on the industry, but it is time to move on to something else, both for legal reasons and for technical reasons.
The framework is changing as we profile and analyze the code.
Should I worry or will it stay simple?
Perhaps even more impressive than the improved bit rates is that the source code actually looks competently written and is small. It also seems to use C++ in a reasonable way: to achieve just around the right amount of abstraction, without building a useless, general framework.
Seems like a very unnessecary step to accomplish that, unless they have some sort of conflict with the legalaties of other codecs out there...
They probably have a technical problem with current video codecs. Calling the MPEG (1, 2, 4) standards mediocre and obsolete would be charitable.
Video codecs typically have ``sweet-spots'' for resolution and bitrate.
Well, if your video compressor has notions of "8x8 blocks" and "16x16 blocks" hardwired into it, that is not exactly surprising. That's the kind of technology that current codecs use.
If they use wavelets and motion compensation correctly, there is no reason why it shouldn't scale well across a large range of resolutions.
C++ is just as efficient and easy to use in the vast majority of memory management cases as Java or C#.
But it isn't about ease of use. It's about safety. C++ isn't safe and it cannot be made safe without garbage collection.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs
Safety is not a property of programs, it's a property of languages and runtimes. A safe language ensures that no piece of memory can be accessed or modified in a way that violates the type system, and it catches all such attempts. Any memory management error anywhere in a C++ program may result in the unexpected alteration of data in any module anywhere else in the C++ program.
Which brings me to my next point: properly written C++ programs are much safer than Java/C# programs. One reason for this is that the C++ compiler is capable of forcing usage patterns in the manner described above.
You may claim that proper use of C++ abstractions lets you avoid many bugs. That may or may not be the case, but most C++ programs contain large amounts of code over which you have no control. I don't want my bank statement to be off by $1000 because someone didn't abstract properly in the printer driver.
And, in fact, most C++ abstractions are merely advisory and no guarantees. Just because you tie methods to an object that you intend to be stack allocated doesn't mean that I won't allocate it on the heap and fail to release the lock because of that.
So you would rather that they are trying to market and sell Windows 95? I remember back trying to use that crap (along with Windows 3.1, 98, etc) and that was the reason I switched over to Linux (only temporarily, though).
No, I would rather I wasn't subject to the output of Gates's personal quest of discovery through the world of computer science and software engineering. People knew how to design better systems than Windows XP when Microsoft was founded and when Gates was still getting the bugs out of MS Basic.
I know Windows isn't perfect, but it is alot more stable and reliable than the old incarnations.
After two decades, and billions of dollars of development, it would be nearly impossible for it not to be. And with all that effort, Windows finally manages to be almost as good as UNIX, which, frankly, isn't exactly exciting in and of itself. By all rights, we should really have HAL by today, instead we get Clippy and pop-up ads.
Some people might not like the constant updates (not referring to patches), but alot of the time MS is putting in an update at the request of certain customers, and you can't fault them for putting in features that their customers require.
I don't know what you mean by "fault". It is bad engineering and it is anti-free market. But Microsoft can't help it--they can hardly break themselves up for the good of everybody else as long as the money keeps coming in; at fault is ultimately the anti-trust division, which lets the current state of affairs continue.
There is always enthusiasm in our business for new concepts. So-called 'free software' is the latest new thing.
It's only been around since the 1960's.
In the event of needed enhancements or fixes, the Linux development community, no matter how well intentioned, simply cannot advance Linux the way we can - and must - innovate in Windows.
Microsoft's constant "advancements" are actually on reason I don't like Windows that much. UNIX did a pretty good job 30 years ago, and it still does.
It is true that even though I've programmed in RT environments, I've never used a RT GC, I'm just relaying the comment that both the C and C++ committee have delayed adoption of a GC standard for those two languages and that a serious issue is real-time performance. The C/C++ standards committees are not a bunch of idiots so I take the view that there must be something true in there.
And the pope used to say that the earth was a the center of the universe. Well-known people have their hangups, just like everybody else, and particular religions gather in their own churches.
You are correct that for some hard real-time problems even using malloc is a no-go area.
Using "malloc" is a "no-go area" in each and every hard real-time problems: "malloc" makes no guarantees whatsoever about latency. The only way you can call "malloc" in a hard real-time system is if you know its implementation and know that it actually makes hard real-time guarantees. But the
If you need a GC for your language to be safe then you need some other automated mechanism to close down open resources for you as well. GCs are not the be-all and end-all of language safety.
Oh, but it is. Leaking a file descriptor is not a question of runtime safety, it's just a bug. However, deallocating memory that is still in use has unpredictable and undefined consequences, and that is a violation of runtime safety.
Why do people get so upset about "the government" doing this?
It's worth worrying about things "the government" does if nobody else can do them. But any private company or individual can do this, and it's gotten cheap enough that many probably will, for various reasons.
You just have to assume that when you drive around in your car, anybody can track your license plate. Whether that's "anybody" or "anybody but the government, who can then buy it from private companies anyway" makes very little difference.
IBM wrote a JVM. They also wrote WebSphere. What part of the Java platform have they not independently implemented?
.NET: they are both highly proprietary platforms.
Most of the libraries, foremost Swing.
(Incidentally, IBM probably can't open source most of the libraries they have written because of their contractual obligations to Sun.)
all the anecdotal evidence I have heard (mostly here on Slashdot) is that in practice they do follow all the recommendations of the JCP. (Of course, they are part of it, so they could just veto things from within.)
But it's not the recommendations I am concerned about, it's the ability to do complete and independent implementations. That ability has never been tested.
Furthermore, Sun doesn't have to assert their rights if they don't want to, and they have had no reason. Gcj and Kaffe may well violated lots of Sun intellectual property, but they are not a useful substitute for Sun Java, so Sun hasn't had to do anything about it. That may well change if gcj+SWT+Eclipse becomes the new standard.
So everybody "changing the JCP specifications" already knows the implementation. Anybody can join the JCP for free to become part of the everybody. So anybody can learn the implementation. If the information about the implementation is that available, then more formal specifications may not be needed.
Trouble is that if you know the implementation, you can't do a clean-room implementation anymore.
I expect to be programming Java later this year. The project will start in Java because I can produce the prototype using Java much faster than any other language. Some versions of the production release may be written in C once performance is the priority, but that will never happen without a proof-of-concept.
And, strange as that may seem, I develop in Java myself still. But I am quite aware that doing so is really little different from developing in Microsoft Windows or
On the other hand, I scrupulously avoid looking at Sun source code or getting entangled in the JCP or other processes: the legal implications of doing that are disturbing.
Don't blame Sun just because, like many other projects, OSS constantly has to play catchup
I don't blame Sun for the degree to which open source is able to clone Java, I blame them for making it a contractual requirement that any clone keeps up with them, and I blame them for not issuing a fixed standard and sticking with it. Besides, it is not just OSS that hasn't been able to catch up--all commercial efforts at making an independent Java implementation have died. People can't catch up with Sun for the same reason they can't catch up with Microsoft: both companies define a system and keep changing it rapidly.
That's one of the attitudes that really ticks me off about the OSS community, or anyone that copies rather than creates. They don't give enough credit to the people they are copying or acknowledge all the resources being given to them.
Sun hasn't created squat with Java, nor have they given much credit. Java is a jumble of decades old technologies, cloned and copied from all over the place.
As for the resources, if Sun doesn't like the way they are being treated, they can just stop giving, as far as I'm concerned; Sun's current behavior vis-a-vis OSS is a bad deal for OSS.
If it isn't clear to everyone yet that the OSS community has it in for Sun because Linux want's to take over the market share that sun has, all these open letters, articles, etc. should be proof of that.
Of course, OSS wants to take over Sun's market, and nobody has made a secret of that for the last several decades. If that comes as a surprise to anybody, at Sun or elsewhere, they really haven't been paying attention.
Call me silly, but if some company had donated so much money and code to my community and I dissagreed with what they were doing I would bring it up with them directly instead of in a public way to try and discredit them.
First of all, Sun did what they did for their own reasons; nobody has any obligation to be grateful for them. Donating software doesn't buy you any latitude to screw OSS in other ways.
Second, people have brought this up with Sun over and over again--not just OSS folks, but also companies, both big and small. Sun doesn't give a damn and they tell people to go get lost. Just look at Sun's response to IBM for a recent example.
Third, Sun is discrediting themselves: they are making promises and not following through, they are misrepresenting products as "open" that aren't, and they are skirting GPL requirements on conspicuous displays of licenses.
OS, the new FUD machine.
I fail to see the "fear, uncertainty, and doubt" in that. When I say that "Sun sucks", I think that a pretty clear, certain, and definitive statement.
They probably detect whether the ad's content was accessed by the user, either by tracking things on the web server or with JavaScript. If that becomes commonplace, ad-blockers will just download the content and then discard it.
Now, what would be a really nifty trick is if they manage to detect that lynx blocks pop-up ads and put a translucent ad on top of the lynx text.
If the JCP were legally equivalent to one of the existing standards bodies, then Sun could have just submitted to them.
How does the JCP differ from an open standard? This is what one of the JCP specifications starts out with:
Apart from the fact that the document is covered by copyrights, patents, and that you can do almost nothing with it, note that it is Sun, not the JCP members or some other organization, that owns all the rights.
It also tells you who has the final word over compliance: Sun.
And it spells out conditions that are almost impossi
Python (pre 2.0) used to do only refcount, and did it much better than Java (using GC) in all respects except thread friendliness. Modern python (2.0 and beyond) does both -- but it's extremely rare for the gc to be needed at all.
That's a myth. Python reference counting doesn't even get close to the performance of a reasonable garbage collector. Even the Python implementation as it is can be speeded up by replacing its reference counting scheme with the Boehm garbage collector (if you do it correctly).
It was mentionned earlier that reference counting was pretty good, but had a few drawbacks when it came to cycles and multi-threading.
Reference counting is not a "pretty good" technique: it is very hard to implement well, and the implementations everybody uses are inefficient and don't even handle the general case.
In the description they give, they mention that reference counting GC can represent managed objects by directed graphs.
I know there exists algorithm to find cycles in such graphs. So I suppose these could be applied to this problem. Other proposal are to use a tracing GC to detect them.
The two solutions amount to roughly the same thing.
Reference counting OTOH seems to allow the cleanup to continually add a little bit of overhead to the system but nothing which will bring the whole thing to a grinding halt before allowing it to go on. What have I missed?
Normal reference counting does not at all release things "continually": when you lose the last reference to a huge, complex data structure, you may end up doing millions of deallocations at once. To cope with that, you need to do a lot more work. And when you are done, you end up with an implementation that's complicated and still doesn't solve the general case (cycles), so you need a garbage collector anyway.
The simplest available algorithms to do gradual cleanup of memory are, in fact, certain kinds of garbage collection algorithms.
It might be useful if some languages had an optional method of hinting that an object should be garbage collected soon
Good garbage collected languages let the programmer give extensive hints to the garbage collector about locality, expected lifetime, desired latencies, mutability, and other relevant properties. That kind of functionality goes back to at least the early 1980's. Over the last two decades, however, some garbage collectors have gotten so good that they don't need a lot of those hints anymore.
Whether giving hints to the GC would help Sun's Java implementation is hard to tell. It might or it might not.
Stack-based languges like the C family (including Java) don't need GC to operate correctly
Correct memory management in the presence of heap-allocated mutable objects require garbage collection, even in C.
There simply is no way around it: you can allocate an arbitrary graph of objects, and what can be freed depends on what is reachable from the roots.
And if garbage collection isn't built into the language, then the language has to be unsafe, like C is.
So, if you want a safe language with heap allocation of mutable objects, you need garbage collection. Lexical closures have nothing to do with it.
Which means that locally-declared variables have to keep existing after the creating function returns, even if the coder can't get to them anymore. And the only way to do that is to have the runtime system manage its own heap, which means a garbage collector.
There is no such requirement: you can deallocate closures manually just like any other data structure. But once people get to that point, they generally realize that it's a bad idea.
this article sweeps under the rug most of the reasons why languages dependent on garbage collection have always failed to find much deployment in industrial settings.
For the same reason people in industry have kept programming in Cobol and Fortran, and for the same reason they keep producing software with all sorts of problems, bugs, and limitations.
A previous poster noted that most GC algorithms are distinctly unfriendly to virtual memory systems. They usually have similar problems with cache locality, which can result in an enormous slowdown, regardless of the time actually spent in the GC itself
Not true at all. Generational collectors generally achieve far better locality than malloc-style allocators.
A more fundamental problem is that memory is only one of many resources a typical industrial program must manage. GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C.
Fundamentally, the point behind GC is not to make your life easier, it is to make it possible for the language to be safe. Without GC, a language with heap allocated mutable data structures just cannot be safe. GC generally cannot reliably manage any other resources besides memory and it is not meant to.
Given a resource management regime that can handle all these other important resources, as is commonly practiced in C++, memory becomes just another resource.
But memory isn't just any resource, memory is a resource that can contain machine pointers to other memory (as well as references to other resources).
The problem of resource management for memory is that of arbitrary directed graph reachability. And that is exactly the problem that a garbage collector solves, as efficiently as possible.
A language that lacks the tools necessary to implement such a regime needs GC, so the presence of GC may actually (as in the case of Java) indicate a fundamental weakness in the language.
C++ solves a common but limited subset of the resource management problem and then just declares victory. And even that false victory is not very satisfying because in order to achieve it, C++ has sacrified runtime safety. (In fact, with that choice, it has also sacrificed efficiency, but you aren't going to believe that no matter what I say.)
There's a way to avoid many mallocs/frees all at the same time, which is to use a memory pool and have some object look after it. Allocations usually come from an already allocated pool of memory, deallocations are simply the setting of a flag.
Yes, and the same technique works in garbage collected systems and has been used for pretty much as long as garbage collectors have been around. Good garbage collectors actually give you extensive APIs to manage areas and pools in a way that the GC knows about and can help you with, but you can do it "by hand" in even the simplest of them.
This technique is used by KDE. It's all done behind the scenes, so as a developer, you don't need to worry about it too much.
It's unclear that it's a good idea for something like KDE to do this because many malloc implementations already do it for you. Building this sort of functionality in user code generally does a worse job than when it's integrated into the memory allocator.
And "GC program" is shorthand for "program written in a language with garbage collection".