The preliminary spec for generic types in Java is here. The Sun prototype compiler can be downloaded here. And a forum for discussion of Java generics is also available.
You might also want to check out CodeGuide. This is AFAIK the only IDE which already supports Java generics as described in the spec (and is an awesome IDE for traditional Java as well).
Nowhere in the article did he even imply anything like the last part of this quote (it's an all-new instruction set that the Transmeta Crusoe processors can't emulate). If you wanted to make a point you should have put this statement outside of the quote.
>>> It's about the fact that you can't develop for both the Linux kernel and a source code control system (e.g., CVS) at the same time without paying for BitKeeper
This is just not true. As mentioned before there is absolutely no need to use BitKeeper for kernel development. Many core kernel developers (e.g. Alan Cox) do not use BitKeeper at all and just send regular patches against development releases to Linus.
I wholeheartedly agree. I think that the FSM should be really thankful to be able to use a great tool such as BK for free. If there were a free SCM which could do what BK can then I am sure that the kernel hackers would use it. But there is no such tool.
>>> As other posters have pointed out, BitKeeper's licence is the same paid or free. You may not use BitKeeper to assist in developing a competitive product.
This is just not true. There is the commercial license (the BKCL) and there is the free license (the BKL). Both differ in many points and there is no clause about development of competing products in the BKCL. Check your sources.
I think that LM overrates the benefits that BitKeeper has to his competitors.
1) His main argument why open source developers can not reproduce something like BitKeeper is that it takes a god-awful amount of work to develop a complex SCM like BK and make it work for all corner cases as well. And this does not change at all even if they have access to BitKeeper for free.
2) For his commercial competitors (e.g. Rational) it is no big deal to buy a few BitKeeper license and have some developers thoroughly test and disect it. The licensing costs are by no means prohibitive to do that. So this point is moot as well.
So all in all having the competitors use the product does not seem to be a big deal. He should have refrained from introducing this clause because of all the bad hype it generates. But he seems to suffer from an overly inflated ego like many developers in the open-source community so he fails to understand that he has much more to loose than to gain by including this clause.
Well it seems that Tom Lord (author of arch) did not succeed raising the cash that he needed to continue development. His website (www.regexps.com) has been down for weeks now.
Not that I think that arch would have grown up to something useful in the future anyway. Producing a good SCM such as BitKeeper is an unholy amount of work and he was under the perception that the so-called "community" would donate enough money to allow him to accomplish that. Poor guy. Welcome to reality.
If the submitter had followed the thread on LKML more closely he would have realized that it is only forbidden to use the *free* (i.e. openlogging) version of BK to develop a competing product. They can still *purchase* a commercial license and develop whatever they want with it.
Since a long name such as GNU/X11/Apache/Linux/TeX/Perl/Python/FreeCiv becomes absurd, at some point, you will have to set a threshold and omit the names of the many other secondary contributions. There is no one obvious right place to set the threshold, so wherever you set it, we won't argue against it.
You are correct. But I think the original poster was just trying to make a statement about the instruction cache.The P4 has 12k micro-op trace cache (roughly equivalent to a 20KB L1 instruction cache) but the Athlon has a 64KB L1 instruction cache which provides space for much larger code fragments/algorithms. It is very well possible that the larger instruction cache combined with better branch prediction accounts for a good amount of the performance advantage of the Athlon on many working sets.
It takes 8 perfect shuffles. To continue the series you outlined (2^n mod 51, n=0,...): 1,2,4,8,16,32,13,26,1.
-- kryps
Re:Does the distribution still include Netscape?
on
Red Hat Linux 7.3 Released
·
· Score: 2, Informative
Like Bero said, the above would appear to state that because RedHat ships gcj they cannot ship JDK.
I am quite sure that the paragraph in question is not aimed at other packages such gcj or kaffe but rather disallows that a vendor adds classes intended to replace core classes of Sun's Java implementation thus creating an incompatible version of Java.
May be so, I'm not a SuSE user, but in that case I'm guessing SuSE doesnt ship gcj, Jikes nor Kaffe...
Section 3 allows you distribute redistributables: 3. License to Distribute Redistributables. Subject to the terms and conditions of this Agreement, including but not limited to Section 4 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file), (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software, (vi) include the following statement as part of product documentation (whether hard copy or electronic), as a part of a copyright page or proprietary rights notice page, in an "About" box or in any other form reasonably designed to make the statement visible to users of the Software: "This product includes code licensed from RSA Security, Inc.", and (vii) include the statement, "Some portions licensed from IBM are available at http://oss.software.ibm.com/icu4j/".
Regarding the other objections: I am sure that Sun will allow you to bundle it if you ask them to.
With all due respect for opensource Java implementations such as kaffe and gcj: They are nowhere near offering production quality. Thus having a recent JDK included in Redhat Linux would be really great.
BTW: I am not sure but if I recall correctly SuSE Linux ships with a Sun JDK.
How nice it may sound, some things in this comment are just not true:
JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.
Objects that are used only in the function in which they are created can be allocated on the stack if no references to this object are returned/passed as arguments. In fact recent VMs (Sun 1.3.1, IBM 1.3) do exactly that.
If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.
Well that is what the StringBuffer class in Java is for. StringBuffers are very fast for this kind of thing. While I have to admit that Java immutable Strings make it easier for the developer too generate code which performs poorly it is well possible to produce (text processing) code which performs really well.
Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)
Your numbers are just wrong at least for recent Java implementations. Object allocation is very fast in languages using a generational garbage collector because allocating an object just consists of increasing a pointer by the size of the newly generated object. On the other hand the time needed for object deallocation has to be considered. The cost for deallocation is highly dependant on the number of live objects and the way objects are created. If the way objects are created is "compatible" with the generational GC (i.e. most newly created objects are short-lived) deallocation is very fast as well. Example: Object creation takes about 60 CPU cycles (JDK 1.3.1) on my Athlon 1200 if the objects are discarded directly after creating.
I don't know where you got the "1000 bytes per dynamically allocated object" number from. In JDK 1.3.1 each object has an overhead of 16 bytes.
Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't
Actually I can't believe that everybody is happy about Netscape's demise.
As I understand almost all of the work done for Mozilla is done by Netscape (AOL) engineers. If nobody uses Netscape and everybody switches to Mozilla AOL is not making any money from those engineers efforts. Thus they could drop support for Mozilla all together at some point.
The only hope is that AOL wants to ship Netscape to their customers instead of IE. I still have serious doubts that they will do this since most AOlers are used to IE and IE still works a lot better than every other browser on Windows.
Slashdot Mirror
For the impatient:
The preliminary spec for generic types in Java is here.
The Sun prototype compiler can be downloaded here.
And a forum for discussion of Java generics is also available.
You might also want to check out CodeGuide. This is AFAIK the only IDE which already supports Java generics as described in the spec (and is an awesome IDE for traditional Java as well).
Enjoy!
-- kryps
He never said that.
Nowhere in the article did he even imply anything like the last part of this quote (it's an all-new instruction set that the Transmeta Crusoe processors can't emulate). If you wanted to make a point you should have put this statement outside of the quote.
I can't understand why the parent was modded up.
-- kryps
>>> It's about the fact that you can't develop for both the Linux kernel and a source code control system (e.g., CVS) at the same time without paying for BitKeeper
This is just not true. As mentioned before there is absolutely no need to use BitKeeper for kernel development. Many core kernel developers (e.g. Alan Cox) do not use BitKeeper at all and just send regular patches against development releases to Linus.
-- kryps
I wholeheartedly agree. I think that the FSM should be really thankful to be able to use a great tool such as BK for free. If there were a free SCM which could do what BK can then I am sure that the kernel hackers would use it. But there is no such tool.
-- kryps
>>> As other posters have pointed out, BitKeeper's licence is the same paid or free. You may not use BitKeeper to assist in developing a competitive product.
This is just not true. There is the commercial license (the BKCL) and there is the free license (the BKL). Both differ in many points and there is no clause about development of competing products in the BKCL. Check your sources.
-- kryps
I think that LM overrates the benefits that BitKeeper has to his competitors.
1) His main argument why open source developers can not reproduce something like BitKeeper is that it takes a god-awful amount of work to develop a complex SCM like BK and make it work for all corner cases as well. And this does not change at all even if they have access to BitKeeper for free.
2) For his commercial competitors (e.g. Rational) it is no big deal to buy a few BitKeeper license and have some developers thoroughly test and disect it. The licensing costs are by no means prohibitive to do that. So this point is moot as well.
So all in all having the competitors use the product does not seem to be a big deal. He should have refrained from introducing this clause because of all the bad hype it generates. But he seems to suffer from an overly inflated ego like many developers in the open-source community so he fails to understand that he has much more to loose than to gain by including this clause.
-- kryps
Good to hear. Is there a website where I can track the progress of arch development?
-- kryps
Hi!
Well it seems that Tom Lord (author of arch) did not succeed raising the cash that he needed to continue development. His website (www.regexps.com) has been down for weeks now.
Not that I think that arch would have grown up to something useful in the future anyway. Producing a good SCM such as BitKeeper is an unholy amount of work and he was under the perception that the so-called "community" would donate enough money to allow him to accomplish that. Poor guy. Welcome to reality.
-- kryps
Hi!
Well this is quoted from the free license. The commercial license does not include this section.
-- kryps
Hi!
. html
You can find a probably biased comparison here:
http://www.bitkeeper.com/Products.Comparisons.CVS
-- kryps
Hi!
If the submitter had followed the thread on LKML more closely he would have realized that it is only forbidden to use the *free* (i.e. openlogging) version of BK to develop a competing product. They can still *purchase* a commercial license and develop whatever they want with it.
-- kryps
So what about just "Linux"
-- kryps
You are correct. But I think the original poster was just trying to make a statement about the instruction cache.The P4 has 12k micro-op trace cache (roughly equivalent to a 20KB L1 instruction cache) but the Athlon has a 64KB L1 instruction cache which provides space for much larger code fragments/algorithms. It is very well possible that the larger instruction cache combined with better branch prediction accounts for a good amount of the performance advantage of the Athlon on many working sets.
-- kryps
Give this guy a break.
It takes 8 perfect shuffles. To continue the series you outlined (2^n mod 51, n=0,...): 1,2,4,8,16,32,13,26,1.
-- kryps
Like Bero said, the above would appear to state that because RedHat ships gcj they cannot ship JDK.
;-)
c kages_professional/index_all.html.
I am quite sure that the paragraph in question is not aimed at other packages such gcj or kaffe but rather disallows that a vendor adds classes intended to replace core classes of Sun's Java implementation thus creating an incompatible version of Java.
May be so, I'm not a SuSE user, but in that case I'm guessing SuSE doesnt ship gcj, Jikes nor Kaffe...
Enough guessing
SuSE 8.0 ships with Sun J2SE 1.3.1, IBM JDK 1.3.0, jikes and GCJ according to their package list at: http://www.suse.de/de/products/suse_linux/i386/pa
-- kryps
Section 3 allows you distribute redistributables:
3. License to Distribute Redistributables. Subject to the terms and conditions of this Agreement, including but not limited to Section 4 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute those files specifically identified as redistributable in the Software "README" file ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified (unless otherwise specified in the applicable README file), and only bundled as part of Programs, (ii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README file), (iii) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (iv) you only distribute the Redistributables pursuant to a license agreement that protects Sun's interests consistent with the terms contained in the Agreement, (v) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software, (vi) include the following statement as part of product documentation (whether hard copy or electronic), as a part of a copyright page or proprietary rights notice page, in an "About" box or in any other form reasonably designed to make the statement visible to users of the Software: "This product includes code licensed from RSA Security, Inc.", and (vii) include the statement, "Some portions licensed from IBM are available at http://oss.software.ibm.com/icu4j/".
Regarding the other objections: I am sure that Sun will allow you to bundle it if you ask them to.
With all due respect for opensource Java implementations such as kaffe and gcj: They are nowhere near offering production quality. Thus having a recent JDK included in Redhat Linux would be really great.
BTW: I am not sure but if I recall correctly SuSE Linux ships with a Sun JDK.
-- kryps
Hi!
What do you mean by not legally redistributable?
The license for the Sun J2SDK 1.4.0 seems to suggest that it is perfectly fine to include it in a Linux distribution such as Redhat Linux.
Please enlighten me!
-- kryps
JIT compiled Java is kind of strange because it is competeitive with C++ at both low-level (bit banging primitives) and high-level (dynamically allocated objects). However, in middle ground (nontrivial objects that can be allocated solely on the stack), C++ blows Java away. This is mainly because all Java data that is not a local primitive variable must be dynamically allocated.
Objects that are used only in the function in which they are created can be allocated on the stack if no references to this object are returned/passed as arguments. In fact recent VMs (Sun 1.3.1, IBM 1.3) do exactly that.
If you use C++ at a nice comfortably high level of abstraction (i.e., with some implementations of STL's std::string), it can be significantly slower than Java because of construction and destruction of every function parameter. OTOH, if you write your C++ program in a painstaking and dangerous C-like fashion (using one stack-based buffer for a string across many levels of function call), it can be an 1 or 2 orders of magnitude faster. If you bang on strings alot, a language like Perl can be a good choice because its mutable strings are more efficient than Java and safer or easier than C/C++.
Well that is what the StringBuffer class in Java is for. StringBuffers are very fast for this kind of thing. While I have to admit that Java immutable Strings make it easier for the developer too generate code which performs poorly it is well possible to produce (text processing) code which performs really well.
Aside: In my experience, a rule-of-thumb is that most dynamic memory allocations in any language seem to take on the order of 1000 CPU clocks, and most dynamic "objects" end up consuming about 1000 bytes.)
Your numbers are just wrong at least for recent Java implementations. Object allocation is very fast in languages using a generational garbage collector because allocating an object just consists of increasing a pointer by the size of the newly generated object. On the other hand the time needed for object deallocation has to be considered. The cost for deallocation is highly dependant on the number of live objects and the way objects are created. If the way objects are created is "compatible" with the generational GC (i.e. most newly created objects are short-lived) deallocation is very fast as well. Example: Object creation takes about 60 CPU cycles (JDK 1.3.1) on my Athlon 1200 if the objects are discarded directly after creating.
I don't know where you got the "1000 bytes per dynamically allocated object" number from. In JDK 1.3.1 each object has an overhead of 16 bytes.
Of course, at the end of the day, all the issues that I just raised pale in comparison to the importance of the basic structure of your algorithms. If you feed in 50X times your expected load into your application, it will often slow down and/or eat memory in a spectacular fashion. By recoding to eliminating that problem, you can often make a "slow" language outperform "fast" one. This is often done by identifying the portions of your algorithm that depend on input size and perform worse than N*log(N) in space or time, then recoding them so they don't
With this I have to agree.
-- kryps
As I understand almost all of the work done for Mozilla is done by Netscape (AOL) engineers. If nobody uses Netscape and everybody switches to Mozilla AOL is not making any money from those engineers efforts. Thus they could drop support for Mozilla all together at some point.
The only hope is that AOL wants to ship Netscape to their customers instead of IE. I still have serious doubts that they will do this since most AOlers are used to IE and IE still works a lot better than every other browser on Windows.
The slashdot effect will teach them what network degradation really means. ;-)
kryps