As someone who has to support Java applications (with Swing based front ends) on Windows, Mac OS X, and various Unix flavours I can say with some confidence that OpenJDK is as good as an Oracle branded Java runtime, and better than an IBM branded one. We (meaning my employer) support our apps on IBM's Java runtime when OpenJSDK isn't an option, but our preference is now Oracle's releases or OpenJDK with no real preference for either. The significant thing is that only a year ago this wasn't the case - we considered Oracle's releases to be the preferred platform over OpenJDK. Since then, we have seen no bug reports that have turned out to be down to bugs in OpenJDK that didn't exist in Oracle's releases. Of course if you're fucking about and using unpublished API's from the com.sun packages, then that would explain your claim to not support OpenJDK, but then by definition of what is a "certified Java application", if you are using such API's then you have no reason to complain that your apps don't work as expected under OpenJDK.
just to back up your points, the neo-cons that would go on to be the major figures in Dubya's government were advocating war against Iraq from the mid-1990's onwards (no doubt before that, but the earliest publications written by figures like Rumsfeld that I'm aware of date from about 1995). The 11/9 attack was just a useful justification, that with a little spin - "lookee Bubba, them I-raqis are A-rabs, they must be to blame" - could be used to get Congress to broadly approve just about any hostile action.
And just how long do you think those missile batteries would survive in an aerial campaign against any Western forces?
Given how long the US would need to get enough firepower within range of those batteries, the Iranians would have long enough to destroy several major oil ports and enough shipping currently plying the straits to disrupt the world economy. And quite frankly, given how the US is building up to invade Iran with as little justification as the invasion of Iraq (in other words, none) I can't say I'd blame the Iranians.
And in other news, this Linux and BSD using nerd is eagerly awaiting his free phone upgrade in January in order to get an Android device, since he's fed up using his wife's Windows PC to update the music on his fucking iPhone.
This would be the CTO of a company renowned (in the UK at least) for its involvement in a huge number of abortive public sector IT projects. I very much doubt that Breton has much input into those projects though, as Atos is a huge company. He probably does what most executives of his calibre do, and attend pointless senior managment meetings, generally in nice locations with dinner and drink laid on. That's when he isn't schmoozing for more work, a task that generally involves more dinner and drink, all paid for out of the company kitty.
That cover of the White Dragon paperback brings back memories. It's the only one of Anne McCaffrey's novels that I've read cover to cover, but I thoroughly enjoyed it - and I say that as someone who absolutely despises almost all fantasy and science fiction stuff.
Except it only gets tested on one specific ARM board, as that's the only one the Mono developers at Xamarin have access to. On a large number of other ARM boards it is either buggy, or outright doesn't work.
Oh for fucks sake. I've just switched the wife's laptop from Ubuntu 11.10 to the beta of Fedora 16, since unlike that Unity bollocks at least the GNOME shell has the "fallback" mode that turns it back into something usable.
Based on my experience managing a large network, SSDs have been less reliable than spinning platters.
Yup, just had another SSD fail two days ago. This one was six months old, and hasn't had that much use. The worst thing is that when SSDs fail, they tend to fail hard rather than slowly degrading as spinning disks generally do.
It can be really important if you're storing thousands of files (text, or anything that compresses well) and still need fast direct access to them.
Just tar them, compress the tar file, then use something like file roller to browse the compressed archive. This is exactly the way the Unix philosophy is supposed to be applied - using discrete tools to do specific tasks rather than complicating things like the general purpose file system code.
One of Reagan's sons (Ron I think) has confirmed that his father had Communist sympathies at one time. There was an excellent series on British TV earlier this year that gave "warts and all" accounts of a number of prominent US presidents, and the Reagan one included a lot of stuff on his early left-leaning views, followed by his swerve rightwards and collusion with the McCarthy crap. The biggest eye opener was episode covering Lincoln - far from the saint he's made out to be today.
So your rationale is that the API is horrible because they added in some bespoke classes?
I looked at the implementations of the alternative to many of the Collections classes in particular, and they had nothing in them that suggested they were "better suited to mobile devices". And I'm not going to dig through the API docs, but they were certainly no improvement on the equivalent Java classes, and I recall them often being less intuitive.
Er, if you don't want to use XML files to do your UI, you don't have to.
I know you can construct your UI directly in code, but virtually all the documentation I have seen assumes you'd never want to do that and omits coverage of it. Hence why I said the XML format was presented as "the preferred way".
This is not even true. The activity does not "restart"
The process is exactly the same as when the app is explicitly shutdown by the user or the app developers code, so it is true. That's why you have to store the current state of the application, as you allude to in your comment.
Nothing you've said supports this conclusion [that the development platform feels like a proof of concept]
Well, if you feel it's more than just adequate then I dread to think what your own code looks like. While I dislike the walled garden approach of Apple, from a purely technical point of view I love the iOS as a platform to develop for. I had high hopes that the Android SDK would be as pleasant to develop for, since it is a much more open platform, but I'm left hoping instead that someone comes up with an alternative.
Have they fixed the appalling development platform for programming Android apps? I've some experience of programming for the iPhone, and as I can already program in Java I thought I'd give Android programming a try late last year. The API is horrible - standard Java classes replaced by poorly designed alternatives for no apparent reason, those horrible XML files as the preferred way of designing a UI, and unavoidable casts all over the place. When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter. It feels a proof of concept rather than a polished development platform, as though Google bought a work in progress and couldn't be arsed to finish it because they needed to get it out quick in order to compete with iOS. Compared to the best practices with regular Java programming, it's as though the Android SDK ignores all the lessons of the last twenty or more years of object oriented programming...
I'm not familiar with Delphi, but can assure you as someone very familiar with C, Objective C, C++, Java and Smalltalk that C# and the.Net framework are little more than clones of the Java language and class library with little more than a difference in the case used for naming. Some syntactic sugar has since been added, but the direct lineage back to Smalltalk via Java is still obvious.
I was talking about the difference between BCPL and C - not the difference between B and C. It's a long time since I looked at B, but from what recall it was a considerable departure from BCPL in many areas, but kept the notion of supporting only one data type - the bit pattern. Havng taken a quick read back through the introduction of Richards and Whitby-Strevens book on BCPL, they actually name check Ritchie, crediting the first edition of K&R for th structure of some of the material in their own book. (Although BCPL obviously predated C, the definitive book on it wasn't published until 1979).
C was not written by a team of computer scientists, it was written by two telecoms software engineers. It was based on Thompson's earlier language B, which was inspired by BCPL. Having read the book on BCPL, I can assure you that C resembles it as much as Java resembles Smalltalk. As for C#, it's a clone of Java. Java was inspired by Goslng's experience with Objective C and NeXT's framework, which were in turn inspired by Smalltalk (Gosling encountered Objective C when Sun Microsystems were toying with idea of adopting OpenStep as their desktop).
As for academics, the ones I've worked with use Perl, C, Java, Fortran and in one instance Pascal. I've never in almost twenty years of professional coding encountered even one person using Haskell, Erlang or a Lisp dialect. The nearest I've seen is one abortive attempt by a colleague to use DSSSL (based on Scheme) for a project in the late 1990's.
I love the fact that you're posting this on Slashdot.
If you take a look at the mess of spaghetti that is Slashcode, then you'll realise it's appropriate rather than ironic. Slashdot took years to actually have pages that approached anything like well formed or compliant to a DTD, and the current site glitches badly on mobile devices.
My elderly neighbour got scammed by this lot. They actually knew some information that could have only have come from a previous support call to her ISP -an ISP that has a call centre in the same Indian city. I've since learnt that a number of Indian call centre firms are selling data to scammers, and that the Indian authorities don't give a damn since it's bringing in foreign revenue.
Have you tried using Mono on Mac OS X? I have, and it's alpha quality. Also, Windows Forms has been superseded by WPF - which is far less painful to use than Forms - but isn't supported by Mono.
You probably signed up in 1998, as I did. Just like Seumas a few posts up, a colleague brought Slashdot to my attention. I can't remember my colleagues surname or username, but if Robin who worked at Blackwells in Oxford, UK during 1998 reads this then it'd be cool to get a reply from him.
No, but in practice Java never really lived up to that promise either, except for very trivial applications.
Bollocks. I've worked on at least three non-trivial systems that are written in Java and run on at least two platforms (Linux and Windows) without modification. The first is a warehouse management system for a multi-national publishing company, the second is the front end to a repo trading platform used by a dozen Wall St or City of London based banks and the last is a large suite of applications for a government organisation. The only way it can "fail to work in reality" is if you deliberately use classes you shouldn't (eg. those in the sun.com hierarchy) or ignore the few areas where you have to use the - well documented - portability features of the class library (an example is using File.separator when manually constructing filesystem paths).
I agree that something like C++ has better scalability from a pure language perspective but java far more scalable from an environmental perspective.
Threading and locking are far easier to implement in Java rather than C++, as they're built into the language and libraries. The concurrent add ons that came with Java 1.5 improved things as well.
The try-with-resources handles all this for you. declare both resources in the try (...). The auto-closing will be applied to all the resources you specify, and in the event of an exception being thrown in your try block, then any exception thrown by the closing of the resources will be ignored (although there is a means to access them if you so wish).
Slashdot Mirror
As someone who has to support Java applications (with Swing based front ends) on Windows, Mac OS X, and various Unix flavours I can say with some confidence that OpenJDK is as good as an Oracle branded Java runtime, and better than an IBM branded one. We (meaning my employer) support our apps on IBM's Java runtime when OpenJSDK isn't an option, but our preference is now Oracle's releases or OpenJDK with no real preference for either. The significant thing is that only a year ago this wasn't the case - we considered Oracle's releases to be the preferred platform over OpenJDK. Since then, we have seen no bug reports that have turned out to be down to bugs in OpenJDK that didn't exist in Oracle's releases. Of course if you're fucking about and using unpublished API's from the com.sun packages, then that would explain your claim to not support OpenJDK, but then by definition of what is a "certified Java application", if you are using such API's then you have no reason to complain that your apps don't work as expected under OpenJDK.
just to back up your points, the neo-cons that would go on to be the major figures in Dubya's government were advocating war against Iraq from the mid-1990's onwards (no doubt before that, but the earliest publications written by figures like Rumsfeld that I'm aware of date from about 1995). The 11/9 attack was just a useful justification, that with a little spin - "lookee Bubba, them I-raqis are A-rabs, they must be to blame" - could be used to get Congress to broadly approve just about any hostile action.
And just how long do you think those missile batteries would survive in an aerial campaign against any Western forces?
Given how long the US would need to get enough firepower within range of those batteries, the Iranians would have long enough to destroy several major oil ports and enough shipping currently plying the straits to disrupt the world economy. And quite frankly, given how the US is building up to invade Iran with as little justification as the invasion of Iraq (in other words, none) I can't say I'd blame the Iranians.
And in other news, this Linux and BSD using nerd is eagerly awaiting his free phone upgrade in January in order to get an Android device, since he's fed up using his wife's Windows PC to update the music on his fucking iPhone.
This would be the CTO of a company renowned (in the UK at least) for its involvement in a huge number of abortive public sector IT projects. I very much doubt that Breton has much input into those projects though, as Atos is a huge company. He probably does what most executives of his calibre do, and attend pointless senior managment meetings, generally in nice locations with dinner and drink laid on. That's when he isn't schmoozing for more work, a task that generally involves more dinner and drink, all paid for out of the company kitty.
Just make sure you avoid floats - they're noted for their inaccuracy.
That cover of the White Dragon paperback brings back memories. It's the only one of Anne McCaffrey's novels that I've read cover to cover, but I thoroughly enjoyed it - and I say that as someone who absolutely despises almost all fantasy and science fiction stuff.
Except it only gets tested on one specific ARM board, as that's the only one the Mono developers at Xamarin have access to. On a large number of other ARM boards it is either buggy, or outright doesn't work.
Oh for fucks sake. I've just switched the wife's laptop from Ubuntu 11.10 to the beta of Fedora 16, since unlike that Unity bollocks at least the GNOME shell has the "fallback" mode that turns it back into something usable.
Based on my experience managing a large network, SSDs have been less reliable than spinning platters.
Yup, just had another SSD fail two days ago. This one was six months old, and hasn't had that much use. The worst thing is that when SSDs fail, they tend to fail hard rather than slowly degrading as spinning disks generally do.
It can be really important if you're storing thousands of files (text, or anything that compresses well) and still need fast direct access to them.
Just tar them, compress the tar file, then use something like file roller to browse the compressed archive. This is exactly the way the Unix philosophy is supposed to be applied - using discrete tools to do specific tasks rather than complicating things like the general purpose file system code.
One of Reagan's sons (Ron I think) has confirmed that his father had Communist sympathies at one time. There was an excellent series on British TV earlier this year that gave "warts and all" accounts of a number of prominent US presidents, and the Reagan one included a lot of stuff on his early left-leaning views, followed by his swerve rightwards and collusion with the McCarthy crap. The biggest eye opener was episode covering Lincoln - far from the saint he's made out to be today.
So your rationale is that the API is horrible because they added in some bespoke classes?
I looked at the implementations of the alternative to many of the Collections classes in particular, and they had nothing in them that suggested they were "better suited to mobile devices". And I'm not going to dig through the API docs, but they were certainly no improvement on the equivalent Java classes, and I recall them often being less intuitive.
Er, if you don't want to use XML files to do your UI, you don't have to.
I know you can construct your UI directly in code, but virtually all the documentation I have seen assumes you'd never want to do that and omits coverage of it. Hence why I said the XML format was presented as "the preferred way".
This is not even true. The activity does not "restart"
The process is exactly the same as when the app is explicitly shutdown by the user or the app developers code, so it is true. That's why you have to store the current state of the application, as you allude to in your comment.
Nothing you've said supports this conclusion [that the development platform feels like a proof of concept]
Well, if you feel it's more than just adequate then I dread to think what your own code looks like. While I dislike the walled garden approach of Apple, from a purely technical point of view I love the iOS as a platform to develop for. I had high hopes that the Android SDK would be as pleasant to develop for, since it is a much more open platform, but I'm left hoping instead that someone comes up with an alternative.
Have they fixed the appalling development platform for programming Android apps? I've some experience of programming for the iPhone, and as I can already program in Java I thought I'd give Android programming a try late last year. The API is horrible - standard Java classes replaced by poorly designed alternatives for no apparent reason, those horrible XML files as the preferred way of designing a UI, and unavoidable casts all over the place. When I got to the bit in the tutorials about apps being forcibly restarted when the orientation changes I cried with laughter. It feels a proof of concept rather than a polished development platform, as though Google bought a work in progress and couldn't be arsed to finish it because they needed to get it out quick in order to compete with iOS. Compared to the best practices with regular Java programming, it's as though the Android SDK ignores all the lessons of the last twenty or more years of object oriented programming ...
My point is that they weren't computer scentists - Ritchie's background was physics from what I recall.
I'm not familiar with Delphi, but can assure you as someone very familiar with C, Objective C, C++, Java and Smalltalk that C# and the .Net framework are little more than clones of the Java language and class library with little more than a difference in the case used for naming. Some syntactic sugar has since been added, but the direct lineage back to Smalltalk via Java is still obvious.
I was talking about the difference between BCPL and C - not the difference between B and C. It's a long time since I looked at B, but from what recall it was a considerable departure from BCPL in many areas, but kept the notion of supporting only one data type - the bit pattern. Havng taken a quick read back through the introduction of Richards and Whitby-Strevens book on BCPL, they actually name check Ritchie, crediting the first edition of K&R for th structure of some of the material in their own book. (Although BCPL obviously predated C, the definitive book on it wasn't published until 1979).
C was not written by a team of computer scientists, it was written by two telecoms software engineers. It was based on Thompson's earlier language B, which was inspired by BCPL. Having read the book on BCPL, I can assure you that C resembles it as much as Java resembles Smalltalk. As for C#, it's a clone of Java. Java was inspired by Goslng's experience with Objective C and NeXT's framework, which were in turn inspired by Smalltalk (Gosling encountered Objective C when Sun Microsystems were toying with idea of adopting OpenStep as their desktop). As for academics, the ones I've worked with use Perl, C, Java, Fortran and in one instance Pascal. I've never in almost twenty years of professional coding encountered even one person using Haskell, Erlang or a Lisp dialect. The nearest I've seen is one abortive attempt by a colleague to use DSSSL (based on Scheme) for a project in the late 1990's.
I love the fact that you're posting this on Slashdot.
If you take a look at the mess of spaghetti that is Slashcode, then you'll realise it's appropriate rather than ironic. Slashdot took years to actually have pages that approached anything like well formed or compliant to a DTD, and the current site glitches badly on mobile devices.
My elderly neighbour got scammed by this lot. They actually knew some information that could have only have come from a previous support call to her ISP -an ISP that has a call centre in the same Indian city. I've since learnt that a number of Indian call centre firms are selling data to scammers, and that the Indian authorities don't give a damn since it's bringing in foreign revenue.
Have you tried using Mono on Mac OS X? I have, and it's alpha quality. Also, Windows Forms has been superseded by WPF - which is far less painful to use than Forms - but isn't supported by Mono.
You probably signed up in 1998, as I did. Just like Seumas a few posts up, a colleague brought Slashdot to my attention. I can't remember my colleagues surname or username, but if Robin who worked at Blackwells in Oxford, UK during 1998 reads this then it'd be cool to get a reply from him.
No, but in practice Java never really lived up to that promise either, except for very trivial applications.
Bollocks. I've worked on at least three non-trivial systems that are written in Java and run on at least two platforms (Linux and Windows) without modification. The first is a warehouse management system for a multi-national publishing company, the second is the front end to a repo trading platform used by a dozen Wall St or City of London based banks and the last is a large suite of applications for a government organisation. The only way it can "fail to work in reality" is if you deliberately use classes you shouldn't (eg. those in the sun.com hierarchy) or ignore the few areas where you have to use the - well documented - portability features of the class library (an example is using File.separator when manually constructing filesystem paths).
I agree that something like C++ has better scalability from a pure language perspective but java far more scalable from an environmental perspective.
Threading and locking are far easier to implement in Java rather than C++, as they're built into the language and libraries. The concurrent add ons that came with Java 1.5 improved things as well.
The try-with-resources handles all this for you. declare both resources in the try (...). The auto-closing will be applied to all the resources you specify, and in the event of an exception being thrown in your try block, then any exception thrown by the closing of the resources will be ignored (although there is a means to access them if you so wish).