But how smart is drilling into the core of the earth? Aren't they asking for one huge volcano?
No, as magma is coming up to the surface all the time all over the world in holes much, much larger than the borehole.
If someone who was hell bent on one HUGE suicide bomb, what is to stop a country from picking 4 or 5 places around the world, dig deep, and pack a nuke. Blow up the nuke, and the earth is rearranged.
Nothing much would happen. The energy already being released by normal volcanoes and earthquakes is far more than we could produce with nuclear weapons. For example, the Mount St. Helens volcano released energy in just one day (18 May 1980) equivalent to 400 million tons of TNT - about 20,000 Hiroshima bombs. That is a significant fraction of the entire world's current nuclear arsenal - from just one volcano! A few nukes exploded around the world is not going to do anything.
The part of irreducible complexity that gets me is where life formed out of non life. A cell must have so many parts working in order to still function. Take away one of those parts and it cease to be alive.
There is no distinction between life and non-life. You can get a single, relatively simple RNA molecule that self-replicates AND catalyses that replication. Add a couple more RNA molecules that could catalyse simple reactions to provide energy (it has recently been shown that RNA can act as a complex catalyst, just like proteins), and you have a self-replicating system that can provide itself with energy. Put this within a lipid membrane (which can form spontaneously) and you have a simple primitive cell.
It is true that modern cells require lots of parts to work, but they are modern! The evolution of simple cells took billions of years.
There is no such thing. We assume things are irreducible because we don't yet understand how they evolved. The logical flaw is to assume that this means they could not have evolved. There are many good examples of mistaken assumptions of irreducibility.
I'll be waiting to see video of the repeatability of your experiments. I'm sure they aren't solely based on observations. Of things supposedly 14 billion years in the past. Because I'm sure someone had a camcorder rolling.
Effectively, we did! Because the speed of light is not infinite, the further we look out in space, the further back in time we can see. We can see a very long way out, and so a very long way back. The COBE satellite picked up microwave radiation that originated over 13 billion years ago.
The evidence for this age is very easy for anyone to understand. There are things called 'standard candles': stars which behave in a certain way, and are a certain size, and have the same brightness. We can detect their faintness and shifts in their spectrum, and easily calculate how far away they are, and so how old they are.
Also, theories are proved by the repeatability of observations, not the repeatability of processes. We can't re-run billions of years of evolution, but we can have testable theories about what we should find as fossils. We can then go out and test these theories by digging up bones...
No. Not having it sucks. Just because I can abuse a feature doesn't mean I will. If it's so bad, why is Sun using it on its string class? The answer to "why" is obvious, because it made the class easier to use. But, I am prevented from making that decision.
I think it is like this: Java (for better or worse) is based on years of experience of how projects go wrong because of poor developer and coding techniques. Just because you and I have no problems with understanding what is happening with operators, that does not mean that everyone does, especially those who are trying to support others' code. The problems that features like operator overloading and multiple inheritance introduce for code maintainability aren't just matters of opinion - they are well established. So, we use a less-than-perfect language knowing that there are likely to be long-term advantages.
The use of + in String was because that has been well-established for decades in languages like Pascal.
Well, that's what I think the Java designers were thinking!
However, it shares the same weakness as JRuby or Jython. It's too alien,
I really don't see this at all, as those languages are virtually identical to the C-based counterparts. Groovy is about as different from Ruby as Ruby is to Python - there is nothing fundamentally alien about it because it is hosted on JVM.
and there are many people out there who, having spent years mastering Java, feel extremely threatened when someone suggests their hard-earned knowledge may not always be applicable.
Personally, I don't care! Providing I can mix and match classes from different languages cleanly, I welcome the chance to use new languages in this way. I guess I have always believed that IT knowledge always goes out of date, and the only thing that counts is general experience and a willingness to learn.
Easy things easy. Hard things possible. Java's got one. RoR nails them both. Bloggers seem to be buzzing about it right now, but in time it's going to be absolutely huge.
Not in it's current form it won't. RoR has some serious design flaws for major projects. One is that the object model is derived directly from the database, so if the database changes even slightly, this can seriously break code. Serious ORMs have mapping configurations that allow the object model to be isolated from such changes. This hard link to the database also prevents easy portability between different database types - a schema change required by porting can again break code.
Serious ORM systems (such as Hibernate and JDO) have the ability to fine-tune the loading of fields to prevent serious memory and performance problems. Imagine trying to use RoR for large datasets where the tables included large BLOB or VARCHAR fields - this would be a performance nightmare.
The RoR people don't seem to understand that the configuration files present in large Java ORM applications are there for a good reason - to abstract and fine-tune database access.
Finally, RoR requires use of vendor-specific SQL. JDO and Hibernate abstract this. Moving a JDO or Hibernate project between, say MySQL and PostgreSQL can be very fast. It could be a major problem with RoR.
RoR takes a very old-fashioned database-centred vendor-SQL-specific approach.
I think operator overloading got a bum rap. Many developers, myself included, saw people abusing it and said that the horror outweighed the benefit. Now, without it, the landscape is pretty bleak.
I think this is exaggerating - it is a minor matter, perhaps?
Also, Sun saw fit to use it, but we cannot. This says something about Sun's attitude, I think.
Java was always designed to be simple, and avoid the on-going horrors of languages like C++. This simplicity means that compilers are simple and implementations can be simple. It also allows huge amounts of automatic optimisation by technologies such as Hotspot. Java was not designed to be concise or elegant, it was designed to be small and very clear for readers and compilers to understand.
Interestingly, there is a new Java technology that will allow operator overloading, closures etc. It is called Groovy, and is now a JCP JSR. This is a dynamic scripting language that can seamlessly use existing Java classes and can in turn be compiled to classes for use by pure Java. Groovy classes can freely mixed with Java classes in any application. This will allow the flexibility that many of us would like, but in a clearly defined and delimited area.
The only reason anyone would do this is to open source it. There is no reasion for a company to do it, unless they have VERY long term plans for Java.
I disagree a bit. There does seem to be this lazy attitude these days to criticise libraries that are reasonably easy to write yourself. A decade or so ago, developers would not have complained about putting together a few hundred or thousand lines for such a library. Now, they have to be 'spoon-fed' everything. Maybe I am getting old and cynical!
Further, they'd need to be willing to hack the runtime some. What if they want to add a new class with String-like functionality? In order to get operator overloading, which Sun seems to think they needed to make the Java Standard Library, you'd have to do that.
I'm not sure. There are plenty of classes which have behaviour which syntactically would look better with operators, but most developers seem to manager without : java.math.* etc.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I really disagree that there is a single developer culture with Java - there is a very, very wide range of developer types who use it, from the embedded application producer, the game developer, the tool developer and the various types of website/server application developer, and there are frequent clashes between different cultures.
As for the library, there is nothing to stop developers writing their own!
Java's syntax and capabilities are both its flaw and its success. There are far more revolutionary languages that should have been successful (like Smalltalk), but Java needed to be usable by mainstream developers without any major transition to new ways of working, hence the C syntax. I don't like this, but I can see the point.
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability.
I would say that it really does help significantly. I don't know of any other major language that is as easy to deploy, and I have had decades of experience. It sure isn't perfect, but compared to library and versioning issues, even within a supposedly single OS like Windows, Java has been a dream for my work.
A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
I would agree, but Java gets it better that almost any other system, I would argue. It gets you 90% there, and should be praised for that.
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I think is is far, far less of a problem that it used to be. Things have improved hugely since Java 1.3.x, and now with 1.5.x, I am finding Swing apps extremely responsive most of the time.
I know Java isn't perfect if you want to write apps that tie in to each platform in detail, but for cross platform apps, I think it is outstanding.
No need for external files describing the query. No need to worry about which dialect of SQL you are using (the full range of relational capabilities is available in JDO query language). No need to worry about optimising your SQL (a good JDO product will do this for you anyway).
There are dozens of vendors who provide JDO, including open source products, and you aren't limited to data stores that can understand SQL.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue
That is odd. As I sit here typing there are two major Java GUI apps open on my desktop, which have good interfaces and work without change on Windows and Linux. I have developed my own Java GUI apps and have had no porting problems for years. How is this untrue?
But right now, Hibernate is the most recommended solution.
Recommended by who?
There is a full-featured new Java Community Process standard for the persistence of plain Java objects that has the same features as Hibernate. This is called JDO version 2.0. JDO does not limit you to one supplier and works on more than just databases.
Hibernate 3.0 + Annotations is an implementation of EJB 3.0.
No it isn't. It is an implementation of one particular aspect of EJB 3.0 - the plain Java object persistence. EJB 3.0 is a very large specification, with features such as Session Beans and Message Beans. Hibernate does not implement these.
EJB 3.0 rejected JDO 2.0.
Wrong. There are many JDO experts and vendors in the EJB 3.0 expert group.
JDO has been abandoned by Sun and by the app server vendors.
Nonsense. You could not be more wrong. Sun not only actively support JDO, it is the mechanism they use to provide persistence in their App server. Hardly 'abandoning' JDO, is it?
Looking at a list of new stuff in JDO 2 compared to JDO 1, it is obvious that all that happened between version 1 and 2 is to copy features from Hibernate.
And what is wrong with that? It gives you Hibernate features, but standardised and available from more than one supplier.
Of course, there are many features well in advance of Hibernate - object states and the ability to persist to stores other than relational databases.
To say it is only Hibernate copying is not true at all - there are many new features, such as being able to set up customised named fetch groups to help with performance and scalability, that Hibernate lacks.
My experience with JDO (Solarmetric) left me using many of the vendor specific features, and not because I wanted to. Felt more like vendor lock-in to me.
True, but you get that lock-in with Hibernate anyway - none of it is standardised. At least with JDO 1.0.1 you had a substantial core of the API which was portable. Take a look at JDO 2.0 (just approved, implementations will be out soon, including open source versions). Most if not all vendor-specific features (such as Object/Relational Mappings) have now been standardised, so you won't be locked in.
Oh come on! Have You ever seen Object Databse in real enterprise working as a high volume transactional system
Absolutely. Some stock exchanges use Object Databases, some airlines, and CERN uses it because a customised object database has extremely high performance.
(or CSV files or XML Files as a mass storage)? Most modern RDBMSes allows You working with XML and with 'structured files' (for example extrenal tables in Oracle). Point me out the Object DB which has more than 1% market share?
Who cares? JDO is a proven successful way to access relational systems AND it gives the choice to handle non-relational systems as well. You can use the same API if the user of your application simply needs to persist a few objects to a flat file or XML store. Java is about flexibility and scalability for a wide range of uses. JDO meets that requirement as well. Hibernate doesn't. With the features of JDO 2.0 there is no disadvantage, either in code quality or performance, to using JDO rather than Hibernate. There are big advantages - being able to get it from more than one supplier, and being able to use it for more than just relational stores if you need to. What is the problem?
This is the problem - hibernate guys stated from the very begining - 'do one thing, and do it well'. JDO tries to do all things and, actually, does it poor.
This is plain nonsense. JDO's main use is for relational systems, and it works very effectively, even for high-demand enterprise systems.
The Hibernate guys would say this because relational systems are their focus, and they don't want competition there.
In spite of what you might read, JDO IS widely used, which was why the JDO 2.0 specification was recently approved against a lot of political pressure.
JDO does not limit you to relational stores. Hibernate does. JDO 2.0 is very close to Hibernate in terms of use and features, but can work with a very wide range of stored. You can get JDO implementations that work with CSV files, Object databases, XML stores etc. You can use exactly the same code and API to access these stores as you use to access relational stored.
Hibernate is a high-quality product, but JDO gives you choice.
There are nice free and open source implementations of JDO as well.
I also questioned your claim that Kaffe is incompatible by showing that you do not have any knowledge about compatibility.
This is logical nonsense. Questioning Sun's JVM compatibility, (for whatever political reasons you have) does not make Kaffe any less incompatible!
Also, on a side note, since you pride yourself on using a 'Java' branded release of Sun's non-free software and assume that means something, I'd like to kindly point out that what you're using has never been certified as passing the TCK on any Debian release. So what you're running is not 'Java'-compatible in any meaningful, verified way.
Then there is not much use having it installed along with stuff labelled 'Java' is there? I wonder who suggested it might be a valid replacement?
You're apparently blindly trusting a logo to shield you away from libc & kernel issues and you sound as if you like it that way.
Neat the way you condescendingly assume that I am blindly doing things!
For years Java HAS shielded me from libc and kernel issues. It works; it works day in and day out for thousands of developers. I transfer projects consisting of hundreds of thousands of lines of Java code from one OS to another and one Linux distro to another with no problems at all.
You know that being condescending isn't helping your case! I admire the effort being put into Kaffe, but ranting zealotry and being so patronising to anyone who disagrees with you is perhaps not the best way to encourage its use.
I'll take a look at Kaffe in a year or so, to see if it has matured. I am prepared to take interest in a product despite the attitude of its supporters.
Generally claiming that Kaffe is slower than Sun is wrong, as those results show.
Not at all. On most tasks Kaffe is slower. That is a good basis for generalisation!
When Kaffe's gcj-bindings are updated to gcj4, and jit4 is merged in, it will be quite interesting to see the performance of that combined runtime solution.
It will, and I'll take another look then. I would be particularly interested in a Java implementation that was generally optimised for math.
I disagree strongly with you about many things, but I have to say you have made me inclined to keep an eye on Kaffe. I wish the project well.
But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.
Only one. The Open Source nature of the SCSL. On other matters I remain resolutely unconvinced. I see little evidence that Kaffe is either fast or compatible enough for general use. I am a Debian user, and if I try and install almost anything Java-based I seem to end up with Kaffe installed as the default JVM on the path. I can usually tell this because of the strange exceptions that appear when I try and use most of my Java applications! (And no, they are not all Java 1.5 compiled)
Yeah, right:) Try compiling a HalloWorld app on 1.5 and running it on 1.4. Both have the cute logo. But the same program compiled on one, won't necessarily run on the other, unless you somehow manage to convince the compiler to generate code with the other VM's class file format version information and to avoid stuffing in references to the 1.5-specific classes into the class file.
This is a very poor argument. Compatibility does not have to be backwards. I would not expect one program compiled with a later version of libc to run with an earlier one. I would not expect an application that ran on Linux 2.6.x to run on 2.0.x. If someone says I need a Java 1.5.x JRE, that is fine by me. I'll get any 'Java'-labelled JRE of the same number from any vendor on any platform and my application will almost certainly work with few problems. Sure, things are never perfect, but compared to the C++ coding days...
And guess what? Most of Sun's users just kept swallowing the breakage and loved it, because they never noticed it happen.
Exactly. We never noticed it. We took large applications like Tomcat and JBoss and put them on Sun's VM on Windows and they ran fine, then we put them on IBM's VM on Linux and they ran fine. We never noticed it.
They are locked in into non-free software, so why bother getting disillusioned:)
If you choose a particular language you are locked into it after a while, free or not. I have had decades of dealing with incompatibilities in implementations of supposedly the same language - C, C++, Smalltalk - Java is one of the best things to have happened in software development for a very long time.
Don't trust claims blindly, check them for yourself. Be an informed customer.
This is rather condescending. Why are you assuming I am not checking them for myself? I am not naive enough to expect perfection, and if I move to another vendor's VM, I am going to be a little cautious. I know full well that there are going to be some niggling problems. However, something without the 'Java' label, indicating a TCK pass, is not going anywhere near my commercial servers.
Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.
No. It is to do with the practical ability to move code between VMs and JREs. The 'Java' brand indicates that you can do this. I don't know how to prove that Sun's VM passes the test, but I know that it does. Why? Because thousands of developers rely on the compatibility, and it works. You can label it 'marketing' if you like, but that does not remove its practical effectiveness. If it did not work, this would be a major news story and Java's reputation would crumble.
Anyone who wants to test any part of Java can join the JCP (it is free) and download the test tools.
It was not just me who said that Kaffe was incompatible - just take a look at that benchmark page:
"Kaffe does not work correctly with the applet version of SPEC JVM98". That is just one example.
However, I have just seen a screenshot of Kaffe running Eclipse - that is impressive! But, as a commercial developer, I need that Java brand. I need to be able to guarantee (or at least foolishly believe that Sun guarantees) that the Java implementation will run my apps with no code changes and no problems. I can't risk putting major enterprise apps on Kaffe and just hope; no matter the quality of the coding.
Like RMS said, let's build up implementations that help make software written in the Java programming language accessible to more people without getting them entangled in bogus non-free licensing agreements.
I support this project, but I'm afraid I just don't care about these so-called 'bogus' licenses. Java is Sun's product. They can do what they like with it. I'm grateful they provide it for no charge and allow me to re-distribute JREs with my apps. That is all I (and thousands of other developers) need. I think calling arrangements like this 'bogus' is rather petty and mean-spirited. Few companies have provided products like Java free of charge to the developer community.
Sun is now, belatedly, trying hard to emulate GNU Classpath and Kaffe and build up communities around their code base. Looking at Sun's history of 'proprietary-to-open' transitions in OOo and NetBeans, I doubt they will succeed before Kaffe passes the TCK, in particular as long as they stick to their cooperation-unfriendly licensing regime.:)
I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.
I am (as you know) no expert on licensing, but they do now have OSI-approved licenses, like the one for Solaris 10. It is possible to label many OS licenses as 'cooperation-unfriendly', even the GPL! The licenses have different purposes.
As for the TCK, I wish Kaffe luck and hope it does get to be a compatible implementation. The Kaffe you have described seems a huge improvement on what I remember of it years ago!
Slashdot Mirror
But how smart is drilling into the core of the earth? Aren't they asking for one huge volcano?
No, as magma is coming up to the surface all the time all over the world in holes much, much larger than the borehole.
If someone who was hell bent on one HUGE suicide bomb, what is to stop a country from picking 4 or 5 places around the world, dig deep, and pack a nuke. Blow up the nuke, and the earth is rearranged.
Nothing much would happen. The energy already being released by normal volcanoes and earthquakes is far more than we could produce with nuclear weapons. For example, the Mount St. Helens volcano released energy in just one day (18 May 1980) equivalent to 400 million tons of TNT - about 20,000 Hiroshima bombs. That is a significant fraction of the entire world's current nuclear arsenal - from just one volcano! A few nukes exploded around the world is not going to do anything.
The part of irreducible complexity that gets me is where life formed out of non life. A cell must have so many parts working in order to still function. Take away one of those parts and it cease to be alive.
There is no distinction between life and non-life. You can get a single, relatively simple RNA molecule that self-replicates AND catalyses that replication. Add a couple more RNA molecules that could catalyse simple reactions to provide energy (it has recently been shown that RNA can act as a complex catalyst, just like proteins), and you have a self-replicating system that can provide itself with energy. Put this within a lipid membrane (which can form spontaneously) and you have a simple primitive cell.
It is true that modern cells require lots of parts to work, but they are modern! The evolution of simple cells took billions of years.
Irreducible complexity is one that still gets me
There is no such thing. We assume things are irreducible because we don't yet understand how they evolved. The logical flaw is to assume that this means they could not have evolved. There are many good examples of mistaken assumptions of irreducibility.
I'll be waiting to see video of the repeatability of your experiments. I'm sure they aren't solely based on observations. Of things supposedly 14 billion years in the past. Because I'm sure someone had a camcorder rolling.
Effectively, we did! Because the speed of light is not infinite, the further we look out in space, the further back in time we can see. We can see a very long way out, and so a very long way back. The COBE satellite picked up microwave radiation that originated over 13 billion years ago.
The evidence for this age is very easy for anyone to understand. There are things called 'standard candles': stars which behave in a certain way, and are a certain size, and have the same brightness. We can detect their faintness and shifts in their spectrum, and easily calculate how far away they are, and so how old they are.
Also, theories are proved by the repeatability of observations, not the repeatability of processes. We can't re-run billions of years of evolution, but we can have testable theories about what we should find as fossils. We can then go out and test these theories by digging up bones...
No. Not having it sucks. Just because I can abuse a feature doesn't mean I will. If it's so bad, why is Sun using it on its string class? The answer to "why" is obvious, because it made the class easier to use. But, I am prevented from making that decision.
I think it is like this: Java (for better or worse) is based on years of experience of how projects go wrong because of poor developer and coding techniques. Just because you and I have no problems with understanding what is happening with operators, that does not mean that everyone does, especially those who are trying to support others' code. The problems that features like operator overloading and multiple inheritance introduce for code maintainability aren't just matters of opinion - they are well established. So, we use a less-than-perfect language knowing that there are likely to be long-term advantages.
The use of + in String was because that has been well-established for decades in languages like Pascal.
Well, that's what I think the Java designers were thinking!
However, it shares the same weakness as JRuby or Jython. It's too alien,
I really don't see this at all, as those languages are virtually identical to the C-based counterparts. Groovy is about as different from Ruby as Ruby is to Python - there is nothing fundamentally alien about it because it is hosted on JVM.
and there are many people out there who, having spent years mastering Java, feel extremely threatened when someone suggests their hard-earned knowledge may not always be applicable.
Personally, I don't care! Providing I can mix and match classes from different languages cleanly, I welcome the chance to use new languages in this way. I guess I have always believed that IT knowledge always goes out of date, and the only thing that counts is general experience and a willingness to learn.
Easy things easy. Hard things possible. Java's got one. RoR nails them both. Bloggers seem to be buzzing about it right now, but in time it's going to be absolutely huge.
Not in it's current form it won't. RoR has some serious design flaws for major projects. One is that the object model is derived directly from the database, so if the database changes even slightly, this can seriously break code. Serious ORMs have mapping configurations that allow the object model to be isolated from such changes. This hard link to the database also prevents easy portability between different database types - a schema change required by porting can again break code.
Serious ORM systems (such as Hibernate and JDO) have the ability to fine-tune the loading of fields to prevent serious memory and performance problems. Imagine trying to use RoR for large datasets where the tables included large BLOB or VARCHAR fields - this would be a performance nightmare.
The RoR people don't seem to understand that the configuration files present in large Java ORM applications are there for a good reason - to abstract and fine-tune database access.
Finally, RoR requires use of vendor-specific SQL. JDO and Hibernate abstract this. Moving a JDO or Hibernate project between, say MySQL and PostgreSQL can be very fast. It could be a major problem with RoR.
RoR takes a very old-fashioned database-centred vendor-SQL-specific approach.
I think operator overloading got a bum rap. Many developers, myself included, saw people abusing it and said that the horror outweighed the benefit. Now, without it, the landscape is pretty bleak.
I think this is exaggerating - it is a minor matter, perhaps?
Also, Sun saw fit to use it, but we cannot. This says something about Sun's attitude, I think.
Java was always designed to be simple, and avoid the on-going horrors of languages like C++. This simplicity means that compilers are simple and implementations can be simple. It also allows huge amounts of automatic optimisation by technologies such as Hotspot. Java was not designed to be concise or elegant, it was designed to be small and very clear for readers and compilers to understand.
Interestingly, there is a new Java technology that will allow operator overloading, closures etc. It is called Groovy, and is now a JCP JSR. This is a dynamic scripting language that can seamlessly use existing Java classes and can in turn be compiled to classes for use by pure Java. Groovy classes can freely mixed with Java classes in any application. This will allow the flexibility that many of us would like, but in a clearly defined and delimited area.
The only reason anyone would do this is to open source it. There is no reasion for a company to do it, unless they have VERY long term plans for Java.
I disagree a bit. There does seem to be this lazy attitude these days to criticise libraries that are reasonably easy to write yourself. A decade or so ago, developers would not have complained about putting together a few hundred or thousand lines for such a library. Now, they have to be 'spoon-fed' everything. Maybe I am getting old and cynical!
Further, they'd need to be willing to hack the runtime some. What if they want to add a new class with String-like functionality? In order to get operator overloading, which Sun seems to think they needed to make the Java Standard Library, you'd have to do that.
I'm not sure. There are plenty of classes which have behaviour which syntactically would look better with operators, but most developers seem to manager without : java.math.* etc.
But I will reiterate that most people who dislike Java dislike it for the design of its library and its linguistic features and its developer culture, not because of any flaws in its implementation.
I really disagree that there is a single developer culture with Java - there is a very, very wide range of developer types who use it, from the embedded application producer, the game developer, the tool developer and the various types of website/server application developer, and there are frequent clashes between different cultures.
As for the library, there is nothing to stop developers writing their own!
Java's syntax and capabilities are both its flaw and its success. There are far more revolutionary languages that should have been successful (like Smalltalk), but Java needed to be usable by mainstream developers without any major transition to new ways of working, hence the C syntax. I don't like this, but I can see the point.
While it's true, strictly, it's not really what people expect. Java means your code can execute on multiple platforms without a recompile. This is great, but it doesn't help you with deployment, OS integration, and usability.
I would say that it really does help significantly. I don't know of any other major language that is as easy to deploy, and I have had decades of experience. It sure isn't perfect, but compared to library and versioning issues, even within a supposedly single OS like Windows, Java has been a dream for my work.
A good GUI application must address all those things, and getting it right across all platforms is very difficult (and sometimes impossible, each platform has different rules about usability).
I would agree, but Java gets it better that almost any other system, I would argue. It gets you 90% there, and should be praised for that.
There is also the performance issues. If you choose Swing, then you do incur a penalty, and this penalty varies depending on what Swing theme you select and what platform you choose. Often, these choices are the 'least of many evils'.
I think is is far, far less of a problem that it used to be. Things have improved hugely since Java 1.3.x, and now with 1.5.x, I am finding Swing apps extremely responsive most of the time.
I know Java isn't perfect if you want to write apps that tie in to each platform in detail, but for cross platform apps, I think it is outstanding.
Here's an example on how to execute a query called "myquery"
e r);
MyObject myobject = (MyObject)sqlMap.queryForObject("myquery",myinteg
And here is the query declaration:
Here it is for JDO:
Query q = persistenceManager.newQuery(MyObject.class,"id == myint");
q.declareParameters("Integer myint");
q.setUnique(true);
MyObject result = (MyObject) q.execute(myinteger);
No need for external files describing the query. No need to worry about which dialect of SQL you are using (the full range of relational capabilities is available in JDO query language).
No need to worry about optimising your SQL (a good JDO product will do this for you anyway).
There are dozens of vendors who provide JDO, including open source products, and you aren't limited to data stores that can understand SQL.
Then, people starting coding GUI apps in Java, with a misguided notion that it would be truly portable GUI apps. This is not only untrue
That is odd. As I sit here typing there are two major Java GUI apps open on my desktop, which have good interfaces and work without change on Windows and Linux. I have developed my own Java GUI apps and have had no porting problems for years. How is this untrue?
But right now, Hibernate is the most recommended solution.
Recommended by who?
There is a full-featured new Java Community Process standard for the persistence of plain Java objects that has the same features as Hibernate. This is called JDO version 2.0. JDO does not limit you to one supplier and works on more than just databases.
if (java.performace >= c.performace) I.eat_hat();
e ck_section("SciMark 2.0");
open_url("http://www.shudo.net/jit/perf/");
ch
eat_hat();
Hibernate 3.0 + Annotations is an implementation of EJB 3.0.
No it isn't. It is an implementation of one particular aspect of EJB 3.0 - the plain Java object persistence. EJB 3.0 is a very large specification, with features such as Session Beans and Message Beans. Hibernate does not implement these.
EJB 3.0 rejected JDO 2.0.
Wrong. There are many JDO experts and vendors in the EJB 3.0 expert group.
JDO has been abandoned by Sun and by the app server vendors.
Nonsense. You could not be more wrong. Sun not only actively support JDO, it is the mechanism they use to provide persistence in their App server. Hardly 'abandoning' JDO, is it?
Looking at a list of new stuff in JDO 2 compared to JDO 1, it is obvious that all that happened between version 1 and 2 is to copy features from Hibernate.
And what is wrong with that? It gives you Hibernate features, but standardised and available from more than one supplier.
Of course, there are many features well in advance of Hibernate - object states and the ability to persist to stores other than relational databases.
To say it is only Hibernate copying is not true at all - there are many new features, such as being able to set up customised named fetch groups to help with performance and scalability, that Hibernate lacks.
My experience with JDO (Solarmetric) left me using many of the vendor specific features, and not because I wanted to. Felt more like vendor lock-in to me.
True, but you get that lock-in with Hibernate anyway - none of it is standardised. At least with JDO 1.0.1 you had a substantial core of the API which was portable. Take a look at JDO 2.0 (just approved, implementations will be out soon, including open source versions). Most if not all vendor-specific features (such as Object/Relational Mappings) have now been standardised, so you won't be locked in.
Oh come on! Have You ever seen Object Databse in real enterprise working as a high volume transactional system
Absolutely. Some stock exchanges use Object Databases, some airlines, and CERN uses it because a customised object database has extremely high performance.
(or CSV files or XML Files as a mass storage)? Most modern RDBMSes allows You working with XML and with 'structured files' (for example extrenal tables in Oracle). Point me out the Object DB which has more than 1% market share?
Who cares? JDO is a proven successful way to access relational systems AND it gives the choice to handle non-relational systems as well. You can use the same API if the user of your application simply needs to persist a few objects
to a flat file or XML store. Java is about flexibility and scalability for a wide range of uses. JDO meets that requirement as well. Hibernate doesn't. With the features of JDO 2.0 there is no disadvantage, either in code quality or performance, to using JDO rather than Hibernate. There are big advantages - being able to get it from more than one supplier, and being able to use it for more than just relational stores if you need to. What is the problem?
This is the problem - hibernate guys stated from the very begining - 'do one thing, and do it well'. JDO tries to do all things and, actually, does it poor.
This is plain nonsense. JDO's main use is for relational systems, and it works very effectively, even for high-demand enterprise systems.
The Hibernate guys would say this because relational systems are their focus, and they don't want competition there.
JDO is about choice.
Hibernate is the most recommended solution.
Depends what for.
In spite of what you might read, JDO IS widely used, which was why the JDO 2.0 specification was recently approved against a lot of political pressure.
JDO does not limit you to relational stores. Hibernate does. JDO 2.0 is very close to Hibernate in terms of use and features, but can work with a very wide range of stored. You can get JDO implementations that work with CSV files, Object databases, XML stores etc. You can use exactly the same code and API to access these stores as you use to access relational stored.
Hibernate is a high-quality product, but JDO gives you choice.
There are nice free and open source implementations of JDO as well.
I also questioned your claim that Kaffe is incompatible by showing that you do not have any knowledge about compatibility.
This is logical nonsense. Questioning Sun's JVM compatibility, (for whatever political reasons you have) does not make Kaffe any less incompatible!
Also, on a side note, since you pride yourself on using a 'Java' branded release of Sun's non-free software and assume that means something, I'd like to kindly point out that what you're using has never been certified as passing the TCK on any Debian release. So what you're running is not 'Java'-compatible in any meaningful, verified way.
Then there is not much use having it installed along with stuff labelled 'Java' is there? I wonder who suggested it might be a valid replacement?
You're apparently blindly trusting a logo to shield you away from libc & kernel issues and you sound as if you like it that way.
Neat the way you condescendingly assume that I am blindly doing things!
For years Java HAS shielded me from libc and kernel issues. It works; it works day in and day out for thousands of developers. I transfer projects consisting of hundreds of thousands of lines of Java code from one OS to another and one Linux distro to another with no problems at all.
You know that being condescending isn't helping your case! I admire the effort being put into Kaffe, but ranting zealotry and being so patronising to anyone who disagrees with you is perhaps not the best way to encourage its use.
I'll take a look at Kaffe in a year or so, to see if it has matured. I am prepared to take interest in a product despite the attitude of its supporters.
Generally claiming that Kaffe is slower than Sun is wrong, as those results show.
Not at all. On most tasks Kaffe is slower. That is a good basis for generalisation!
When Kaffe's gcj-bindings are updated to gcj4, and jit4 is merged in, it will be quite interesting to see the performance of that combined runtime solution.
It will, and I'll take another look then. I would be particularly interested in a Java implementation that was generally optimised for math.
I disagree strongly with you about many things, but I have to say you have made me inclined to keep an eye on Kaffe. I wish the project well.
But as you may have noticed during the course of our discussion, I have made several assertions that you believed to be untrue, that have in fact turned out to be somewhat contrary to your initial beliefs.
Only one. The Open Source nature of the SCSL. On other matters I remain resolutely unconvinced. I see little evidence that Kaffe is either fast or compatible enough for general use. I am a Debian user, and if I try and install almost anything Java-based I seem to end up with Kaffe installed as the default JVM on the path. I can usually tell this because of the strange exceptions that appear when I try and use most of my Java applications! (And no, they are not all Java 1.5 compiled)
Yeah, right :) Try compiling a HalloWorld app on 1.5 and running it on 1.4. Both have the cute logo. But the same program compiled on one, won't necessarily run on the other, unless you somehow manage to convince the compiler to generate code with the other VM's class file format version information and to avoid stuffing in references to the 1.5-specific classes into the class file.
:)
This is a very poor argument. Compatibility does not have to be backwards. I would not expect one program compiled with a later version of libc to run with an earlier one. I would not expect an application that ran on Linux 2.6.x to run on 2.0.x. If someone says I need a Java 1.5.x JRE, that is fine by me. I'll get any 'Java'-labelled JRE of the same number from any vendor on any platform and my application will almost certainly work with few problems. Sure, things are never perfect, but compared to the C++ coding days...
And guess what? Most of Sun's users just kept swallowing the breakage and loved it, because they never noticed it happen.
Exactly. We never noticed it. We took large applications like Tomcat and JBoss and put them on Sun's VM on Windows and they ran fine, then we put them on IBM's VM on Linux and they ran fine. We never noticed it.
They are locked in into non-free software, so why bother getting disillusioned
If you choose a particular language you are locked into it after a while, free or not. I have had decades of dealing with incompatibilities in implementations of supposedly the same language - C, C++, Smalltalk - Java is one of the best things to have happened in software development for a very long time.
Don't trust claims blindly, check them for yourself. Be an informed customer.
This is rather condescending. Why are you assuming I am not checking them for myself? I am not naive enough to expect perfection, and if I move to another vendor's VM, I am going to be a little cautious. I know full well that there are going to be some niggling problems. However, something without the 'Java' label, indicating a TCK pass, is not going anywhere near my commercial servers.
Because it's pointless to argue about compatibility without knowing what it is, and having means to verify it. You made the assertion that Kaffe is incompatible, but you can't even prove that Sun is compatible. So what's your point about invoking that marketing nosense? The branding program is just a way for Sun and their business partners to market themselves together, as far as I can see. It has nothing to do with real, verifiable compatibility.
No. It is to do with the practical ability to move code between VMs and JREs. The 'Java' brand indicates that you can do this. I don't know how to prove that Sun's VM passes the test, but I know that it does. Why? Because thousands of developers rely on the compatibility, and it works. You can label it 'marketing' if you like, but that does not remove its practical effectiveness. If it did not work, this would be a major news story and Java's reputation would crumble.
Anyone who wants to test any part of Java can join the JCP (it is free) and download the test tools.
It was not just me who said that Kaffe was incompatible - just take a look at that benchmark page:
http://www.shudo.net/jit/perf/
"Kaffe does not work correctly with the applet version of SPEC JVM98". That is just one example.
However, I have just seen a screenshot of Kaffe running Eclipse - that is impressive! But, as a commercial developer, I need that Java brand. I need to be able to guarantee (or at least foolishly believe that Sun guarantees) that the Java implementation will run my apps with no code changes and no problems. I can't risk putting major enterprise apps on Kaffe and just hope; no matter the quality of the coding.
Like RMS said, let's build up implementations that help make software written in the Java programming language accessible to more people without getting them entangled in bogus non-free licensing agreements.
I support this project, but I'm afraid I just don't care about these so-called 'bogus' licenses. Java is Sun's product. They can do what they like with it. I'm grateful they provide it for no charge and allow me to re-distribute JREs with my apps. That is all I (and thousands of other developers) need. I think calling arrangements like this 'bogus' is rather petty and mean-spirited. Few companies have provided products like Java free of charge to the developer community.
Sun is now, belatedly, trying hard to emulate GNU Classpath and Kaffe and build up communities around their code base. Looking at Sun's history of 'proprietary-to-open' transitions in OOo and NetBeans, I doubt they will succeed before Kaffe passes the TCK, in particular as long as they stick to their cooperation-unfriendly licensing regime.:)
I really don't get this attitude to Sun. Stuff that they have released like OOo have been vital for the acceptance of Linux on the desktop. They have done so much good for the IT industry over the years.
I am (as you know) no expert on licensing, but they do now have OSI-approved licenses, like the one for Solaris 10. It is possible to label many OS licenses as 'cooperation-unfriendly', even the GPL! The licenses have different purposes.
As for the TCK, I wish Kaffe luck and hope it does get to be a compatible implementation. The Kaffe you have described seems a huge improvement on what I remember of it years ago!