Draft Review of Java 7 "Measures and Units" 220
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."
Re:getting tired of Java ... (Score:5, Insightful)
Re:More Java growth? (Score:3, Insightful)
Re:Ugh... (Score:5, Insightful)
Perhaps you are a perfect programmer who never makes mistakes. Some of us, despite our best efforts, do make mistakes occasionally; perhaps we simply weren't thinking about how this code would interact with someone elses code at the time; perhaps we just made a typo; perhaps we hadn't quite had our coffee yet; who knows, but mistakes happen to everyone (except, apparently, yourself). In the case that mistakes creep in, it is nice to be able to catch and fix them as early as possible, rather than having a complex and expensive bug hunt somewhere down the line. Spending a moment to actually document requirements and intentions in a form that can be checked (be it statically, or automatically at runtime if you leave checks on) efficiently and regularly is a good thing. Most of us do that already in the form of static types which are checked at compile time. Adding some expressivity to that (via a more powerful type system, contract annotations on methods and objects, an automated unit testing system, or just extra static checks on units) isn't a bad thing, especially if it is optional (as it often is).
I can have some sympathy for the complaint that adding bits and pieces in this rather piecemeal (and in the case of this particular implementation, somewhat clumsy and verbose) fashion is poor. Ideally adding means to decently document and express requirements and intentions should be something added to the language as a whole, with an overriding vision of how it should work. For that see Eiffel, Spec#, Fortress, or languages with more expressive type systems like the ML family and Haskell. Still, with something as simple and encapsulable as dimension and unit checking, why not just throw it in as a convenient optional extra? If you don't like it, don't import the library that implements it.
Re:More Java growth? (Score:3, Insightful)
Re:Java 8 (Score:1, Insightful)
LOL when I want advice on an applet....I'll ask one of you. When I want advice on my chances of being hired....I think I'll go with HR. After all one of you even said:
So let's be fair accross the board and use that as an example.
When I want advice on job marketability I'm going straight to someone with Java experience, preferably and underpaid person, those folds know their stuff.ROFL
Re:Ugh... (Score:4, Insightful)
Relying on the things you list alone will result in abject failure, not only in the system itself but the philosophy of the developers -- "I did xyz, I'm safe, there will be no errors." There's only so much you can do within the base language itself before you start catering to the stupid and putting the system in a nice, safe, less-useful box.
Re:More Java growth? (Score:5, Insightful)
Now with
MS' presence on codeplex is also helping the community side a bit, especially with Patterns & Practices (which a lot of things done by that team, altered by the community, eventually makes it in the real things, like Project Acropolis).
Thats mostly speculation mind you, but it should be interesting...
Re:Philosophy of numbers (Score:5, Insightful)
I was agreeing with you completely until you said that. There can be no reference point for "one dollar". A currency system lifts the burden of a barter system from its users. Without the dollar, you'd have to bake bread and swap it for internet connectivity, or something. How much bandwidth can you get for a loaf of bread? The same question applies to the dollar. Currency is a tangible way to represent the virtual concept of value. There is no unitary value of value so there can be no fixed unitary value for a currency. A free-floating currency values itself according to what its users think it's worth, which is, IMHO, the only sane way to value a virtual concept.
Ian
Re:Philosophy of numbers (Score:3, Insightful)
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.
I'll do you one further, as we get further and further from solidity with numbers we will get progressively worse at handling it. As we deal with less and less cash, the money we have simply has less weight. We've all seen this phenomenon, anyone who does everything with cash will typically be better at handling their money, b/c they're "handling" their money. Some "get out debt" programs actually suggest the use of cash, even over debit (which is ubiquitous here in Canada). It seems that physical cash has a psychological effect on us.
Pretty much all of our banking is now done in vaporous "numbers on a ledger", which does not lend itself to providing us with "Mass" about what the numbers mean. We have to convert this to time just to get an idea. I mean, what's $10,000? Nothing unless you think of it as two months of your time (or maybe a full year's worth of "disposable" income).
I would dare say that the lack of a "gold standard" runs just as deep (or maybe deeper still). Personally, I would love it if we froze the money supply and only added money based on birth rates. So if each Canadian had X dollars associated with them and the population increased by Y, then each year we could print XY dollars and basically kill inflation. Of course, the guys with the money (gov and banks) would not appreciate that b/c they benefit from the public buying into the illusion that today's 50k is worth more than 1980's 20k (it's not). Again with just numbers and no mass associated they can distract people.
Re:getting tired of Java ... (Score:2, Insightful)
I didn't mean to sound hostile to Struts; I use it also. I find that some projects are made more complex, unnecessarily complex, as a consequence of the complexity of tools that are used. I regard java frameworks as just another class of tool It occurs to me that great swaths of the common framework capabilities go unused in a given project. I strive for simplicity, introducing a library or a protocol or a container-provided service as needed.
I find the need for anything beyond implementations of JPA, JMS, JSF, a limited number of implementations from various well-known Jakarta projects, are rather rarely needed and no big deal to introduce when they are.
I also find that when you start out with a big framework (JBoss SEAM comes to mind at the moment), right from the beginning you risk running into a situation where you are provided with an implementation of some fundamental service, are painted into the corner of that specific implementation and version, and *because* of the fact that it's part of the framework, you can't easily swap in another implementation of that service.
I can understand a different point of view on this -- disdain for what is a moving target on the fringe of an emerging technology. If you want to go THERE, I would open by suggesting that it may be too soon to start using Java in a real project
I will now resist making a car analogy and get back to work.
Re:More Java growth? (Score:3, Insightful)
I have used both C# and Java in my work, also. My experience is a little different. The two languages are very similar, both the languages and the class libraries. Java is best for portable applications, C# is best if you are on Windows only, and need to access underlying parts of the O/S, such as getting the icons for a specific file type.
If I needed a C# programmer, and came across a first rate Java programmer, I would not hesitate to hire him/her for the C# job (and vice versa).
Re:So, tell us (Score:2, Insightful)
It has more applications, more libraries, more documentation - all from years of industry backing, making Java a behemoth when it comes to implementing anything. And Java has Eclipse, C# has Visual Studio. Eclipse is amazing. Visual Studio is, well, it's good but it does not compare to Eclipse in terms of features and extensibility and stability.
Recently I had to mine information from a Paradox 7 database. I had an existing C# middleware server to adapt to do this. Skip forward a month and it's all done using ODBC to make the connection. (We'll gloss over how the default MS driver only does Paradox 4/5 and not 7, forcing the usage of DataDirect's expensive ODBC driver.) So, go to the client to install it, and it doesn't work - turns out the DB is on a network share which appears local. Ok, so, inexperience on my part for not getting the full topology correct and replicating it in the development environment - not a C# problem itself. Turns out no ODBC driver will connect to a Paradox DB on a share, but a JDBC driver from hxxt will.
So, C#, can use anything in it right? After days trying to plug a JDBC driver into C# middleware I ditch it and rewrite the part the client needs purely in Java.
I've done in a few days what took a month using C#. The JDBC driver is lightening quick whereas ODBC was slow as hell and problematic at best. Eclipse is a dream to use compared to VS2005. SharpDevelop is miles off.
I can rely on Java and the Java world. I just can't say the same for C# and it's world.
Re:getting tired of Java ... (Score:3, Insightful)
What!? Java 6 I'll give you was not as big a change as Java 5, but Java 6 was mainly a stability, manageability and performance [sun.com] oriented release, but even that came with some pretty big changes - support for scripting languages with the Rhino JavaScript engine included for instance. Also, the Consumer JRE [java.net] changes will be backported to it, with the Kernel JVM, the Quickstarter and Direct3D/DirectX pipeline improvements in Windows to catch up with the OpenGL pipeline.
Java 7 might be one of the biggest changes to the Java language and platform ever, take a look at this list [puredanger.com] for instance. Note that not all of these might be included in Java 7, or indeed ever. Danny Coward who I believe is in charge of the Java 7 release together with Mark Reinhold talks a bit about [sun.com] the difficult balance between giving people the new features they want and keeping it simple.