Slashdot Mirror
Draft Review of Java 7 "Measures and Units"
Jean-Marie Dautelle writes to inform us that the public review period ends on July 8 for JSR-275, "Measures and Units" Early Draft. The JSR-275 will be a major enhancement for Java 7 by providing "strong" typing (through class parameterization) and easy internationalization of Java programs, preventing conversion errors. The latest version 0.8 is available as a PDF. The reference implementation is provided by the JScience project under a BSD license."
This looks rather similar to the units and dimensions handling and checking available in Fortress, Sun's effort to build a new numerical/scientific computing language. In general it seems like a sensible idea -- having the option of adding extra annotation that allows for more exacting static checking and greater assurance is generally always a good thing. The only downside is that, at least in the java implementation, it is a little cumbersome and clumsy (though maybe that's just par for the course for new java versions). Now if only java could get statically checkable optional contracts as in Spec# we might actually be getting somewhere. At the very least it would be nice if they had runtime checkable contracts, properties and tests as in Fortress. Or perhaps I should just wait for Fortress to finally mature; it seems that will happen faster than java getting the features I'm after.
Craft Beer Programming T-shirts
I've spent most of the last 10 years building desktop and web applications with Java: AWT, Swing, JSP, Struts, J2EE, EJBs, and on and on.
Through all those years I've had to fight perceptions of Java being hard to distribute, slow, difficult, insecure, and over-engineered. I've done pretty well in the battle, and produced some pretty nice products.
Maybe I'm having a bit of a mid-life crisis, and I'm wondering where to go from here. I'm looking at alternatives for development: AJAX, Ruby, PHP, and Adobe AIR. But nothing out there (outside of the Microsoft world) does everything that Java does as well -- but Java just doesn't do GUI too well. Although GWT is pretty cool. And I've always thought Applets were underrated and under-utilized.
The point of this rant? Java 7 doesn't excite me in the least. Me and everyone I know are firmly planted in Java 5 (or is it 1.5? I always forget) and we don't appear to be moving to Java 6 (1.6?) -- so why should we care about Java 7 (1.7?).
Anyway, that's my rant. Any suggestions are greatly appreciated!
your java-results probably also contain "Javascript" (think of jobs for web 2.0, ajax, etc.).
Not to mention the tremendous amount of jobs for java-coffee-machine-engineers!
A little detail: "Java" is both a platform and a language. C# is just a language, one of several that runs on the .NET platform. (Microsoft doesn't like the word "platform", but it's the only one that fits.) So when you're analyzing market share, you need to compare Java with .NET, not with C#.
.NET doing pretty good, though still lagging way behind Java. One little improvement in the Java language is not going to spell the "death nell" for the .NET platform. That would be true even if .NET didn't have the backing of the biggest software company on the planet.
.NET is the fact that Sun seems to be capturing a lot of developer mind share with its Java Community Process, which is where this proposal comes from, along with a lot of other good stuff, including JSR 166, which originated outside Sun, and has successfully added a major improvement in concurrency to the Java platform.
.NET either, not as long as they have MS's backing — and are essential tools on Windows. But it will certainly help Java hold onto its lead.
The figures you quote show
What is bad news for
The JCP won't spell the "death knell" to C# or
The idea is based on the philosophy that numbers do not exist in isolation. It is possible to speak of, e.g., the number 5 as an abstract entity unto its own, but that should be rare. Most of the time, "5" refers to the ratio "5:1", where the "1" refers to something tangible. In science, the "1" is denoted with units. The problem is, starting with tabulating machines, then onto electronic calculators, and even multi-gigabyte computers, numbers are almost universally represented (erroneously) as the former -- purely abstract numbers. The units are stripped off.
As any struggling physics or chemistry student knows, one can fake one's way through a test by doing "dimensional analysis" on test questions. If the units cancel out properly and agree, you've probably got the right answer.
Compilers should be doing dimensional analysis at compile-time. I had originally hoped to create C++ templates -- which are evaluated at compile-time -- to do this, but I couldn't quite see how to get them to handle all the possible permutations of unit combinations and conversions -- at least not easily. It really needs to be built into the language.
With a compiler enforcing dimensional analysis, it would force programmers to think through every formula and calculation. Novel unit combinations would arise as a result of creating database reports. E.g. a payroll report might have $/2-week pay period. A conversion somewhere to $/year would be another unit, and the conversion between $/2-week pay period and $/year would be clearly definied in one place rather than sprinkled throughout the code.
Putting conversions in one place is the first thing I did when I cleaned up some pre-existing source code that I took over. I explicitly created three coordinate systems (device, world, and screen) and created two two-way conversions to go between the levels. Before that, there were conversions all over the place, each a little different, each with different handling of roundoffs and some even with hidden fudge factors. ("Conversions in one place" can be done without developing a units system, as it has its own benefits.)
I blame a lack of education on the philosophy of numbers for programming languages relying upon naked numbers for so many decades. Rote algorithms for addition, subtraction, multiplication, and division taught in elementary school are the foundation of this vacuous philosophy.
It could even be responsible for the public's acceptance of no gold standard for the dollar. They're not demanding to know what the reference point of "one dollar" is.
And of course it's the Federal Reserve that can print endless money for the war in Iraq, thank to the lack of a gold standard.
So there you have it -- lack of units in programming languages and the war in Iraq have a common cause: the lack of correct philosophy on numbers taught in schools.
In other words, Microsoft screwed up all its early planning for .NET. That's only just, since Sun did exactly the same thing with Java: lousy compilers and virtual machines; too much emphasis on web applications and "network computer" technology. Most of the negative things people think they know about Java comes from that era.
Although still in it's infancy, JavaFX kinda sounds interesting. I've played around with it a little bit, and it's definitely fun. There are several examples out there showing you how it's done and they get the point across pretty well. It's supposed to be an alternative to Flash and Silverlight and although showing promise, it definitely falls short in it's multimedia capabilities(sound and video). Multimedia would perhaps be the killer feature to add to Java 7. Anyway, they're supposedly optimizing Java 7 to handle JavaFX and JavaFX Script and this is perhaps one of the features that "might" encourage people to upgrade.
https://openjfx.dev.java.net/
Btw, JavaFX was previously known as F3 (Form Follows Function?) for those that may be looking up more details and examples of it.
We have been using the JScience package to record a variety of internal data about a (we hope!) large scale statistics intensive website we've been building. It is actually a breath of fresh air not to have to worry about accidentally confusing impressions per minute with unique visitors per hour, but rather letting the compiler do the worrying for you. This will be a great addition to Java, but you don't need to wait, JScience's implementation is robust and we've been using it in production for months.