- Microsoft iPod How Microsoft would create the original iPod packaging.
- From the final MacBook review a link to Java performace "We did see similarly dramatic results in a few of our tests. Rendering a 3-D scene using the Java-based program Art of Illusion, the Intel-based iMac was 3.2 times as fast as its G5 counterpart. (It was also faster than a dual-processor Power Mac G5, suggesting that these Intel Macs are much better than PowerPC-based models when it comes to Java performance.)"
- Switching ot a MacBook
- iTunes Music Store downloads graphed - iTunes - to infinity and even further.
Tuesday, February 28, 2006
TUAW Proxy
A low value post.
Thursday, February 23, 2006
MacBook Reviews
MacBook Pro: First day, first Lab tests "Our best test result right now: the Universal version of Cinema 4D XL, a processor-intensive rendering application, which was 3.3 times faster on the 2GHz MacBook Pro than on the 1.67GHz PowerBook G4. Unreal Tournament 2004 took advantage of both the Intel processor and the MacBook Pro’s seriously upgraded video subsystems to post a frame rate 2.5 times greater than that of the PowerBook G4."
"...I can report the result of our first battery test, in which we played a DVD on a 15-inch PowerBook G4 and a MacBook Pro until their respective batteries died, with Energy Saver preferences turned off. The end result: the MacBook Pro died after two hours and three minutes, and the PowerBook died four minutes later. So at least in our first test, the battery life of the MacBook Pro seems in line with the battery life on the last-generation PowerBook G4."
First Impressions: MacBook Pro "...I can tell you on a full charge I was only able to get close to 3.5 hours of battery life. I did have the brightness set to the highest setting and didn't have all the power saving modules setup to maximize battery life. So I would guess the maximum I would think would be 4 hours."
There are some reports of inconsistent backlighting and hissing.
Update: Ars Technica Review MacBook Pro (actually comparing it against a Dell 9100 running OSX).
"...I can report the result of our first battery test, in which we played a DVD on a 15-inch PowerBook G4 and a MacBook Pro until their respective batteries died, with Energy Saver preferences turned off. The end result: the MacBook Pro died after two hours and three minutes, and the PowerBook died four minutes later. So at least in our first test, the battery life of the MacBook Pro seems in line with the battery life on the last-generation PowerBook G4."
First Impressions: MacBook Pro "...I can tell you on a full charge I was only able to get close to 3.5 hours of battery life. I did have the brightness set to the highest setting and didn't have all the power saving modules setup to maximize battery life. So I would guess the maximum I would think would be 4 hours."
There are some reports of inconsistent backlighting and hissing.
Update: Ars Technica Review MacBook Pro (actually comparing it against a Dell 9100 running OSX).
What is FIT?
Using Fit: An Open-Source Testing Framework "Rick Mugridge is the lead author of the first book on storytests: "Fit for Developing Software". He has developed and is evolving FitLibrary to better support storytest driven development. He is a leading thinker and inventor in this area, and consults and coaches internationally in storytesting, executable specifications, and agile software development."
Retro OSX Games
- Tower Toppler (Nebulous remake).
- Grid Wars
- Oolite (Elite remake)
- Pac the Mac
- Chopper (Choplifter remake)
Wednesday, February 22, 2006
Boost
For a little while I've had this idea to create an open source library for utilities used for test driving. It seems that I'm not alone in this and recently the Boost library was made available. You can download the JAR (boost/boost) from the latest build.
For an even more eXtreme view, ContractualJ. Includes: all constructors are declared private and throw java.lang.UnsupportedOperationException, unless they are implicit constructors of anonymous classes and all contracts (interfaces) declare one (and only one) operation, unless they are composite interfaces, in which case, they make an effort to approach "Perfect Symbiosis of Contractual Operations" (to be defined). The only reference I found via Google was "How many bad ideas at once?" - an uninteresting post with some interesting discussion.
For an even more eXtreme view, ContractualJ. Includes: all constructors are declared private and throw java.lang.UnsupportedOperationException, unless they are implicit constructors of anonymous classes and all contracts (interfaces) declare one (and only one) operation, unless they are composite interfaces, in which case, they make an effort to approach "Perfect Symbiosis of Contractual Operations" (to be defined). The only reference I found via Google was "How many bad ideas at once?" - an uninteresting post with some interesting discussion.
Sunday, February 19, 2006
Debt
Design Debt "Design debt can be hard to spot. If you see these problems, your project is already in serious trouble:
* Your team describes the software as "kludgey" or "hacked-together."
* The team often encounters unexpected problems.
* Each change results in a cascade of new defects.
* Defects thought fixed frequently reappear.
To avoid the above level of debt, make debt elimination a priority:
* Reduce schedule pressure.
* Establish a culture of design quality.
* Utilize refactoring, continuous design, and other code-quality practices.
* Make debt reduction a continuous process, not a one-time activity."
When I was working on Kowari/TKS I remember Simon mentioning his idea of the three stages of software:
* Stage 1 - New easy to understand, easy to add new features, classes, components, and frameworks are largely self contained. It's easy to estimate the time it will take to make changes.
* Stage 2 - Difficult to understand, changes have a larger effect that you expect - breaking tests that you don't expect, classes are generally a little too coupled. Generally a reasonably good programmer can achieve meeting deadlines as long as they make "pragmatic decisions" not to fixup all the code.
* Stage 3 - The code is basically impossible to understand as single classes - the voodoo stage. You change something and it breaks something else that appears to be completely unrelated. Making predictable changes is no longer possible.
The obvious answer is to rewrite but this is just what several people have suggested not to do. For example, in one of the Joel on Software articles, "Things You Should Never Do, Part I" he mentions: "It's harder to read code than to write it...This is why code reuse is so hard...When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
A possible way to solve this is to prevent it from occurring. The focus on TDD is often on the testing part of it but it's the design part and the idea to explain intent and reduce the time reading code and increase the time writing it.
In, "Test-Driven Development Isn’t Testing": "Once you start looking at your test cases as a description of the software design, they start to look different. Pay attention to the names of your tests. Instead of writing tests named after a method on an object you're testing, try using the test name to capture the intended consequences...There's at least as much code in the test case as in the actual class being tested.
I guess this makes it sort of "design and test," but in the end we still haven't ensured our object is bug-free."
* Your team describes the software as "kludgey" or "hacked-together."
* The team often encounters unexpected problems.
* Each change results in a cascade of new defects.
* Defects thought fixed frequently reappear.
To avoid the above level of debt, make debt elimination a priority:
* Reduce schedule pressure.
* Establish a culture of design quality.
* Utilize refactoring, continuous design, and other code-quality practices.
* Make debt reduction a continuous process, not a one-time activity."
When I was working on Kowari/TKS I remember Simon mentioning his idea of the three stages of software:
* Stage 1 - New easy to understand, easy to add new features, classes, components, and frameworks are largely self contained. It's easy to estimate the time it will take to make changes.
* Stage 2 - Difficult to understand, changes have a larger effect that you expect - breaking tests that you don't expect, classes are generally a little too coupled. Generally a reasonably good programmer can achieve meeting deadlines as long as they make "pragmatic decisions" not to fixup all the code.
* Stage 3 - The code is basically impossible to understand as single classes - the voodoo stage. You change something and it breaks something else that appears to be completely unrelated. Making predictable changes is no longer possible.
The obvious answer is to rewrite but this is just what several people have suggested not to do. For example, in one of the Joel on Software articles, "Things You Should Never Do, Part I" he mentions: "It's harder to read code than to write it...This is why code reuse is so hard...When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work."
A possible way to solve this is to prevent it from occurring. The focus on TDD is often on the testing part of it but it's the design part and the idea to explain intent and reduce the time reading code and increase the time writing it.
In, "Test-Driven Development Isn’t Testing": "Once you start looking at your test cases as a description of the software design, they start to look different. Pay attention to the names of your tests. Instead of writing tests named after a method on an object you're testing, try using the test name to capture the intended consequences...There's at least as much code in the test case as in the actual class being tested.
I guess this makes it sort of "design and test," but in the end we still haven't ensured our object is bug-free."
Friday, February 17, 2006
Plotting a Course for Quality
QALab it "...collects and consolidate data from several QA tools, like pmd, checkstyle, FindBugs and Simian and keeps track of them overtime."
Just needs a plug in for code coverage (Clover) and stock prices. The checkstyle one probably needs to track the number of excluded files as well.
Just needs a plug in for code coverage (Clover) and stock prices. The checkstyle one probably needs to track the number of excluded files as well.
Thursday, February 16, 2006
Good Names
dialectic "The aim of the dialectical method, often known as dialectic or dialectics, is to try to resolve the disagreement through rational discussion. One way — the Socratic method — is to show that a given hypothesis (with other admissions) leads to a contradiction; thus, forcing the withdrawal of the hypothesis as a candidate for truth. Another way of trying to resolve a disagreement is by denying some presupposition of the contending thesis and antithesis; thereby moving to a third (syn)thesis."
This was my suggestion (roughly anyway) for TMex - Tucana's metadata extractor - the idea being of combining everything to reach new conclusions (it also included TKS). And how did Kowari get its name? Real kowaris are small, furry, endangered and ruthlessly efficient - there seemed to be a perfect fit. Real ones also live for up to six years (which seems overly ambitious now) and don't need to drink water (I don't think there's any parallel there).
This was my suggestion (roughly anyway) for TMex - Tucana's metadata extractor - the idea being of combining everything to reach new conclusions (it also included TKS). And how did Kowari get its name? Real kowaris are small, furry, endangered and ruthlessly efficient - there seemed to be a perfect fit. Real ones also live for up to six years (which seems overly ambitious now) and don't need to drink water (I don't think there's any parallel there).
Tuesday, February 14, 2006
Where do good developers come from?
The best developers are built not bought "In reading about agile development, I've been struck by the fact that both traditional software development techniques and agile methods rely upon highly skilled developers to ensure success. It's no wonder that there's a focus on the best developers given that it's generally accepted that the level of performance for developers with similar experience can differ by a factor of ten or more."
"In most organizations this enthusiasm is squashed in the name of conformity. A mentality of "We've always done it that way" squeezes out any attempt to try to do things better. As a result developers are often left confused between the statement that the organization wants a world class development team (every organization wants this) and the reality that they're unwilling to change to get there."
"In most organizations this enthusiasm is squashed in the name of conformity. A mentality of "We've always done it that way" squeezes out any attempt to try to do things better. As a result developers are often left confused between the statement that the organization wants a world class development team (every organization wants this) and the reality that they're unwilling to change to get there."
Yipee Yahoo
Yahoo User Interface "...a set of utilities and controls, written in JavaScript, for building richly interactive web applications using techniques such as DOM scripting, HTML and AJAX."
As well, Yahoo Design Patterns including a list of patterns for your AJAX or Web user interface such as: Autocomplete, Breadcrumbs, and Drag and Drop.
Looking forward to the faceted navigation and others.
As well, Yahoo Design Patterns including a list of patterns for your AJAX or Web user interface such as: Autocomplete, Breadcrumbs, and Drag and Drop.
Looking forward to the faceted navigation and others.
Controlling EasyMock Complexity
Easier EasyMock Testing "One strategy you might employ to try and combat this a little bit is by breaking up your single test method into several different ones. Using the above example, this might break down into something like testSomeMethod_Normal(), testSomeMethod_InfoNull(), testSomeMethod_InfoException(). This is a reasonable strategy in my opinion. It does now, however, relieve you from having so many replay(), and verify() method calls (reset() method calls wouldn't be needed since the setUp() takes care of it for you)."
Monday, February 13, 2006
Will Bears Save the World?
Starving polar bears shame Bush to act "Starving polar bears are presenting an unprecedented challenge to George Bush's refusal to take action over global warming - and may succeed where environmentalists and other governments have failed in getting him to curb pollution."
"If the bear is listed under the US Endangered Species Act, regulatory agencies would be bound by law to take into account how their decisions would affect it. This could lead to tougher measures to control the spread of pollution that causes global warming, and stricter fuel-economy standards for vehicles."
"If the bear is listed under the US Endangered Species Act, regulatory agencies would be bound by law to take into account how their decisions would affect it. This could lead to tougher measures to control the spread of pollution that causes global warming, and stricter fuel-economy standards for vehicles."
Now for my Tax Return
Sudoku in OWL "The OWL Ontology to represent the grid and rules of the puzzle is modeled as follows:
(a). Create OWL Individuals Vg_ij (1 <= g <= n, 1 <= i , j <= sqroot(n), here n = 4, g = sub-grid index, i = row index, j = column index) to represent specific values in various cells of the grid. For example, create individuals (V1_11, V1_12, V1_21, V1_22) to represent values in the cells of the first sub-grid.
(b). Create OWL Individuals 1, 2, 3, 4 to represent possible values for cells in the grid. Make all four individuals mutually distinct using owl:AllDifferent.
(c). Make all the individuals in a particular row (/column) of the entire grid mutually distinct using owl:AllDifferent, e.g., make the set of individuals corresponding to the values in the first row -- (V1_11, V1_12, V2_11, V2_12) mutually distinct.
(d). Also, make all the individuals in a particular sub-grid mutually distinct using owl:AllDifferent, e.g., make the set of individuals corresponding to the values in the first sub-grid (V1_11, V1_12, V1_21, V1_22) mutually distinct.
(e). Make the top concept, owl:Thing, a rdfs:subclassOf the OWL Enumeration {1,2,3,4} using owl:oneOf. This implies that each individual Vg_ij in the ontology is forced to be owl:sameAs one of the individuals (1,2,3,4)."
How simple and sensible?
Also, Open IRIS - Semantic Desktop PIM Released!. It does come with Calendar, Mail, Browser, Chat, Text Analyzer etc but at 130MB plus it makes the Semantic Web look like the ultimate form of bloat.
(a). Create OWL Individuals Vg_ij (1 <= g <= n, 1 <= i , j <= sqroot(n), here n = 4, g = sub-grid index, i = row index, j = column index) to represent specific values in various cells of the grid. For example, create individuals (V1_11, V1_12, V1_21, V1_22) to represent values in the cells of the first sub-grid.
(b). Create OWL Individuals 1, 2, 3, 4 to represent possible values for cells in the grid. Make all four individuals mutually distinct using owl:AllDifferent.
(c). Make all the individuals in a particular row (/column) of the entire grid mutually distinct using owl:AllDifferent, e.g., make the set of individuals corresponding to the values in the first row -- (V1_11, V1_12, V2_11, V2_12) mutually distinct.
(d). Also, make all the individuals in a particular sub-grid mutually distinct using owl:AllDifferent, e.g., make the set of individuals corresponding to the values in the first sub-grid (V1_11, V1_12, V1_21, V1_22) mutually distinct.
(e). Make the top concept, owl:Thing, a rdfs:subclassOf the OWL Enumeration {1,2,3,4} using owl:oneOf. This implies that each individual Vg_ij in the ontology is forced to be owl:sameAs one of the individuals (1,2,3,4)."
How simple and sensible?
Also, Open IRIS - Semantic Desktop PIM Released!. It does come with Calendar, Mail, Browser, Chat, Text Analyzer etc but at 130MB plus it makes the Semantic Web look like the ultimate form of bloat.
Friday, February 10, 2006
Test Driven Spring, Games and Setter Based Injection
ConstructorInitialization "Constructor Initialization is my first choice. There are cases when it's difficult to set things up this way and I do occasionally prefer setter initialization, but most of the time constructor initialization is the best bet...A large list of construction parameters, like any large parameter list, is a CodeSmell. Usually when I see these I find that many of the parameters are DataClumps and should be replaced by their own object. Having said that it's not unusual for constructor methods to have more parameters than other methods - but they are a good place to spot data clumps."
This is a summary of a previous article "Inversion of Control Containers and the Dependency Injection pattern" especially Constructor versus Setter Injection. Constructor based injection plus autowiring seems to work well with preventing errors in configuring dependencies (also mentions using JFig and Commons Configuration to implement auto-reloading of Spring configuration, although it's unclear exactly how to do this).
Unit Testing Hibernate Mapping Configurations Unit Testing Hibernate Mapping Configurations "...developers don't always remember that the mapping files that drive Hibernate's behavior are as much a part of the program as the Java code. These files can contain defects, behave unexpectedly, and break when you change other parts of your system. In this article, I will show how you can use unit testing to assess the correctness of your Hibernate configuration. The article is a step-by-step approach that also explains some of the more common difficulties you may encounter while using Hibernate."
This is a reminder that Spring configuration can be a source of errors/bugs as much as any other part of a program. In the same way you would test drive another part of the system you should test drive Spring configuration. The helps ensure rapid feedback - instead of waiting for deployment to see if you missed any dependencies. This seems like the approach taken in another IoC framework, Yan (also, Nuts vs Anemic Domain Model).
And for people who think that pair programming isn't a game check out, The Pair Programming TDD Game. Mentions the virtuous cycle: red for a broken test, green for the code passing and grey for refactor (should be blue). And of course, you can make development a game and work at a game company - the fun squared.
This is a summary of a previous article "Inversion of Control Containers and the Dependency Injection pattern" especially Constructor versus Setter Injection. Constructor based injection plus autowiring seems to work well with preventing errors in configuring dependencies (also mentions using JFig and Commons Configuration to implement auto-reloading of Spring configuration, although it's unclear exactly how to do this).
Unit Testing Hibernate Mapping Configurations Unit Testing Hibernate Mapping Configurations "...developers don't always remember that the mapping files that drive Hibernate's behavior are as much a part of the program as the Java code. These files can contain defects, behave unexpectedly, and break when you change other parts of your system. In this article, I will show how you can use unit testing to assess the correctness of your Hibernate configuration. The article is a step-by-step approach that also explains some of the more common difficulties you may encounter while using Hibernate."
This is a reminder that Spring configuration can be a source of errors/bugs as much as any other part of a program. In the same way you would test drive another part of the system you should test drive Spring configuration. The helps ensure rapid feedback - instead of waiting for deployment to see if you missed any dependencies. This seems like the approach taken in another IoC framework, Yan (also, Nuts vs Anemic Domain Model).
And for people who think that pair programming isn't a game check out, The Pair Programming TDD Game. Mentions the virtuous cycle: red for a broken test, green for the code passing and grey for refactor (should be blue). And of course, you can make development a game and work at a game company - the fun squared.
Monday, February 06, 2006
New URLs
- Selenium IDE 0.7 Released "It is 100% functional by itself, or it can be used in combination with Selenium and any of the language (Java, Ruby, etc) drivers, provided you are willing to write the output template."
- JSONC, JSONI, JSONP: Creating tailored JSON from SPARQL query results "What's missing (if we want to avoid custom, server-side code or heavy pre-processing on the client) is a way to tell the SPARQL endpoint to arrange and index the tabular results before they are serialised as JSON: JSONI. The jsoni parameter works similar to the jsonc one, but it allows nesting of result vars to specify index structures" - JSON (JavaScript Object Notation)
- Grady Booch links to "Why I Hate Frameworks": "According to our research, what people really needed wasn't a Universal Hammer after all. It's always better to have the right kind of hammer for the job. So, we started selling hammer factories, capable of producing whatever kind of hammers you might be interested in using."
- On Rigid Rules "The getters and setters on their own aren't a problem. It's how and why they are called that can cause problems. If other objects are calling getters and setters then doing work on the result, it's likely that many objects need to do the same work. This results in duplicated code. Duplicated code causes rigidity. Any design change that affects this code will affect all
copies requiring changes to be made across the system. It's better to have one copy of the code performing this operation and the natural place to put that code is in the original object." - USB could sap Core Duo's power "Tom’s Hardware Guide, has discovered a glitch in one Core Duo/Napa system that suggests machines based on the platform might see unexpectedly short battery life, when operated on battery power with USB 2.0 devices are attached to them."
- Special Topics B Proposal "...SET is designed specifically for commerce [allowing it to] have a 1024-bit cipher block [Vis96b]. Combining this with the backing of major Internet and credit card companies, SET is destined to become the standard means of transmitting electronic, commercial data in the next year or so." And for what really happened.
- SWEO Suggestion #2 : Semantic Web in a Box Lists the key properties of a turn-key Semantic Web application. I would add some maybe metadata extraction and P2P ability but that's probably too much bloat.
Saturday, February 04, 2006
Flash Google
Two Flash version of Google's fine work:
All part of AFLAX.
- Google Earth - FlashEarth.
- Google Talk, GMail and Flickr - Gtalkr.
- Google News - Newsmap
All part of AFLAX.
Thursday, February 02, 2006
Dueling Seminal Papers
So, *ahem* in "No Silver Bullet: Essence and Accidents of Software Engineering" Fred Brooks writes: "I think the most important single effort we can mount is to develop ways to grow great designers...Great designers and great managers are both very rare...each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded."
This basically looks like creating a corporate hierarchy of designers similar to corporate executives.
Contrast this with, "Necessary Preconditions for the Bazaar Style" part of "The Cathedral and the Bazaar" where Eric Raymond writes, "I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others...Linus, while not (as previously discussed) a spectacularly original designer, has displayed a powerful knack for recognizing good design and integrating it into the Linux kernel."
From my experience new ideas aren't successfully applied from the top down but rather from the bottom up. By relying on a few to understand new ideas or to implement them in fully formed designs actually encourages stagnation. It is frequently too risky and expensive to try a new design, applied in a top down manner across an entire project or framework. The better solution seems to be to grow design and better design processes, not designers.
This basically looks like creating a corporate hierarchy of designers similar to corporate executives.
Contrast this with, "Necessary Preconditions for the Bazaar Style" part of "The Cathedral and the Bazaar" where Eric Raymond writes, "I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others...Linus, while not (as previously discussed) a spectacularly original designer, has displayed a powerful knack for recognizing good design and integrating it into the Linux kernel."
From my experience new ideas aren't successfully applied from the top down but rather from the bottom up. By relying on a few to understand new ideas or to implement them in fully formed designs actually encourages stagnation. It is frequently too risky and expensive to try a new design, applied in a top down manner across an entire project or framework. The better solution seems to be to grow design and better design processes, not designers.
Hypercode - Beyond AJAX
There's nothing like combining two technologies together to produce something that sounds cool, Redfoot, "...can be best described as a webized Operating System. An operating system built around the notion of hypercode and where the persistence is built around the notion of an RDF Graph rather than a File Tree (see the namesys Graph vs. Tree). It provides standard web mechanisms to transport information across different machines and programmatically specifies the tasks for bundling and installing new software features across networked machines. The functions of Redfoot are analogous to that of an operating system kernel that manages resources across the web. To allow humans and other HTTP service agents to utilize Redfoot, it uses RDFLib and third party libraries such as Twisted and Kid to convert between RDF-based information and HTML or other popular formats. Therefore, each Redfoot server, is designed to interacting with a human, other redfeet, or any other HTTP-aware computing service. The design and implementation principles of Redfoot is to recursively utilize existing standards and libraries whenever and whereever it can, resulting in a highly compact, yet functionally rich execution kernel."
Hypercode "...is mainly designed as a portable database that helps both programmers and machines to exchange either executable or structured data...specifically utilizes RDF to capture both the structure and meaning of raw data in the XML-based global naming context, therefore, it has the potential to better utilize information in the code's execution context when necessary. In other words, Hypercode dosen't only treat Python or other scripting language as textual data, the defacto interpreter, Redfoot server, could adaptively leverage the supporting resources and execution policies defined in the associated RDF content to control the rights and behavior of script execution."
I was looking at O'Reilly's Twisted book this morning.
I don't know where I read this but it seems cool enough to download and try - like the Bookmark aspect.
Hypercode "...is mainly designed as a portable database that helps both programmers and machines to exchange either executable or structured data...specifically utilizes RDF to capture both the structure and meaning of raw data in the XML-based global naming context, therefore, it has the potential to better utilize information in the code's execution context when necessary. In other words, Hypercode dosen't only treat Python or other scripting language as textual data, the defacto interpreter, Redfoot server, could adaptively leverage the supporting resources and execution policies defined in the associated RDF content to control the rights and behavior of script execution."
I was looking at O'Reilly's Twisted book this morning.
I don't know where I read this but it seems cool enough to download and try - like the Bookmark aspect.
Wednesday, February 01, 2006
Get Functional
Hadn't used Commons Collections until recently, as Tom recently blogged about Closure Time for Java.
It includes Predicates for equals, and and others.
Related: Functional programming in the Java language and Commons Primitives package (another implementation of primitive collections).
It includes Predicates for equals, and and others.
Related: Functional programming in the Java language and Commons Primitives package (another implementation of primitive collections).
Subscribe to:
Posts (Atom)