Well, by that reasoning, almost every language scales. I mean, Yahoo! uses Python for lots of their transactions, and Flickr! uses PHP.
Sorry, but 'lots of their transactions' does not equal hundreds of millions of transactions a day. If Flickr times out, no-one cares. If a stock market transaction, which has to complete in a fraction of a second, times out then serious money is lost. This is, of course, why people use J2EE.
The latest Colt release was in 2004.
So what?
Can you get it into your thick head that we agree on this point? That's why I was saying: I would offer these people Java, because that's what they want and what fits into their organizations. That doesn't mean that Java is the most cost-efficient or technically best solution, it means that it can get the job done at the price these people are willing to pay.
What price? Java is free, and high-performance app servers (Glassfish, JBoss) are free. People use Java because it is the most cost efficient and technically best solution. If you can suggest another very high-peformance easily clusterable solution....
Furthermore, I think in the enterprise space, C# will stomp over Java once people have create the equivalent functionality to J2EE, and they will; of course, being unconstrained by Sun's meddling and incompetent hand, there will be multiple different efforts and approaches, which will be good.
The developers of Mono don't think so.
That's your problem: you don't think yourself, you make decisions based on who you believe and what people said half a dozen years ago.
Nice ad hominem answer:)
being unconstrained by Sun's meddling and incompetent hand, there will be multiple different efforts and approaches, which will be good.
For any given aspect of Java (even Aspects!) there are a number of different efforts and approaches already. From GUIs, Web frameworks, Persistence APIs and so on, there are many alternative approaches.
It's no wonder that the Java platform is getting worse with every release; most of the smart people have left for greener pastures.
You still have not explained why I should believe you as against E-Bay about J2EE performance; you as against IBM and CERN about math capability; You or the Mono developers about the capabilities of C# on Linux?
The CLDC HotSpot[tm] Implementation is a high performance, battery-preserving virtual machine that is compliant with the CLDC specification. It not only offers significantly improved performance over the KVM, but it also offers greater portability and faster time to market. The CLDC HotSpot Implementation is suitable for devices based on ARM microprocessors/controllers, and with 512KB to 1MB of total memory available for the Java technology stack. The latest release of the CLDC HotSpot Implementation is version 1.0.1."
Which is exactly why it'll never happen. The giant Java library ensures that, even with a 100% compatible JVM, most Java applications will only run on the Sun runtime. (Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that. But that's beside the point.)
Sorry, but this is plain wrong. Most Java applications will run on any certified JRE of the appropriate version. That is the point of certification of the JDK and JRE! Even some of the largest and most complex Java applications like Eclipse will run on any vendor's JDK. Even Sun's NetBeans will do this!
Anyway, most Java applications are Web applications, deployed on J2EE app servers like Tomcat and JBoss: these have no specific requirements for the Sun JRE.
By having a massive and hard to implement class library, Sun ensures that anyone else trying to create a compatible Java runtime will always be playing catch-up. They'll never be able to be 100% compatible with the "latest and greatest" Java runtime.
This is rather strange and conspiratorial thinking! Sun don't include a large library with Java to ensure that anyone else plays catch-up - the library has been extended over the years based on developer demand, with things like a more powerful Collections framework (Java 1.2) and concurrency utilities (Java 1.5).
And that's just the way Sun wants it - they're able to keep control of Java that way. Open sourcing the libraries would cause them to lose that control. And that's why it'll never happen.
There is no reason why open sourcing would involve any loss of control. Something can't be called 'Java' unless it passes the compatibility tests, open source or not.
There are already an open source projects which intents to provide a full, up-to-date implementation of Java - Apache Harmony.
one small feature here, another over there and suddenly, whoops! my language is crap! that's how it works...
Exactly. That is what happened with C++, with Visual Basic, and is what is likely to happen with.NET languages.
this is not what java culture says. i guess you're in denial. If it doesn't use several Struts Action beans, form beans, some ant xml and struts-config.xml, it isn't really serious programming...
You haven't a clue have you? If you think Java web programming is just Struts! There is Tapestry, Seam (no config files!), RIFE, Wicket etc. Pick the way you want to work, and choose your framework. No XML if you don't want it; no action or form beans. Tapestry is used for some of the largest sites - that is serious programming.
yeah, here's a lesson for you about automatic validation, like compiler validation:
Some validation is better than none, especially when you are dealing with thousands of lines.
Validation is not proof of correctness.
Who said it was? But to say that no validation is better is idiotic.
"Even the Mono developers have said that it is not suitable for scalable high-end work."
a link would be nice. otherwise, i just don't believe it.
"What is clear is that Mono (as opposed to.NET) is not currently designed for scalability or transactional distributed applications. De Icaza's comments suggest that this is unlikely to change..."
is that like having a camel getting transformed into a lizard? ok, ok, so there are a few intersection between the two formats. Again, they'd be represented by similar keys.:)
you are missing the point - intersections will break things.
ah! is Java Data Objects those huge in-memory database of objects? hope not.
Of course not (unless you want to use a in-memory database). JDO is extremely efficient - I have run batch processes where a single transaction can handle hundreds of thousands of records, with mimimal memory use.
Anyway, Rails developers do everything as classes, rarely needing to tweak the SQL the framework generates for the classes..
Which is potentially disastrous. Code up pages and logic based on what you think is in those generated classes, then all someone has to do is change the database a little, and your code goes 'bang'. It is a really dumb way to work - great to get things going - but very bad for maintenance. There are far better ways to work - especially in Ruby, such as Og. Designing your data model purely as database tables is extremely old-fashioned.
"an API that lets you write a GUI that can display on HTML, WML, Flash, SVG, Swing, even VT100!"
is it like a XUL xml document describing a GUI and then translated for several GUI engines? it's a task that just depends on sheer brute force from a huge taskforce. Java has a huge army of developers and they'll create all kinds of works for their platform. no big deal, just brute force...
No, it is nothing like an XUL XML document describing a GUI. It is a component-based system into which you can plug different renderkits for whatever display you want to use, and you can dynamically switch use as the application is running.
sorry for the EMPTY! thingie./. seems to be suffering from some annoyance rules almost as bad as java's unwritten ones...;)
It is ok - but if you want to continue, how about some actual debates about facts, and not about what you think Java is like (as against what it is like?). I can provide plenty of facts to back up my arguments.
No there isn't this is only for one small feature (Annotations) of the latest Java.
ok, let me clarify: CPU performance got one better, memory usage grew up like craze -- specially with the 1000+ libs needed even for small projects -- and programmer performance went down a lot, drowned in endless abstraction layers, some dozens of APIs and a few IDEs open.
OK - I'll take the bait. Exactly which 1000+ libs do you need for small projects? Which abstraction layers?
in an idealized world, object-relational mappings are perfect, generated queries are perfect and perform great and all that jazz. In the real world, serious work also means a few comprimises, including a few manual hacks so things work properly.
Of course you can do manual hacks in JDO, EJB, Hibernate or whatever. But having a 'hack' built in to the language is no way to go.
why do they need to be external? why so much loose coupling, so many layers of abstraction? It's portable, modularized, loosely coupled, just like University teachers and academics in general like to tell. But all that at an incredibly brain twisting complexity anda huge framework of many different separate projects...
No. They neither need to be external, or have to be external. You don't have to have layers of abstraction if you don't want to. Things can be as simple as you like.
You really do have some weird 'straw man' image of how Java developers work, don't you?
"Not only does it allow any configuration to be validated, it also easily allows existing formats to be cleanly extended and transformed in standard ways, and it has standard mechanisms for embedding binary information and also can handle internationalisation."
wow man! what a load of marketroid terminology and enterprise jargon! i'll take a week to completely undestand it...
OK - let me explain slowly.
"Configuration validated" - your IDE can see where you have made mistakes without you having to run the thing and get a program crash.
"Existing formats to be extended" - You decide you have missed out a setting in your config file, or you want to combine someone elses config file with yours. You can fix this without causing your program to crash when it reads the new file.
"transformed in standard ways" - Someone else has a config file format. You need to transfer your format to theirs. You don't need to do this by hand.
"embedding binary information" - obvious, surely.
"internationalisation." - a real tricky one. This means you can put international characters in your XML file so you can easily specify different settings in alternate languages.
Slow enough for you?
why is someone putting a tree data structure inside a configuration file for starters
Oh come on - there are loads of reasons! One example is if you want a different maps of values: You might, for example, have a set of parameters that should be set to one set of words if the language is 'en', and another set of words if the language is 'fr'.
Hey - that combines both structure and internationalisation - isn't XML cool?:)
yes, i know. I've worked with Eclipse and its many views, you know?
Yes, I find Eclipse immensely annoying - I use NetBeans
It's still annoying, regardless, and specially the Ant build.xml. Wow, they really were able to transform a simple Makefile into an incredibly dull and verbose pile of attribute=values inside tags!
Well, having had 25 years experience of tracking down obscure Makefile errors, give me build.xml and its validated format any day.
Tag soup for soup nazis!
Godwins law - you lose:)
Code completion will only get newbies nuts with so many different but similar options, while experient users will write the most used tags and attributes so fast code-complete won't even come to
Baroque syntax? It is the same as C++ - in fact a lot less baroque - none of the * or & nonsense.
And sorry, but I can't take anyone seriously who says anything poor about Java performance. That is an issue that was dealt with years ago.
yeah, even operator overloading eventually gets there. There already are several DSL features in the java world, like its many web "expression languages"...
But that is not the point - the point is to keep the base langauge clean.
you don't mention the amazing language builtin benefits, like perfect integration with the language. LINQ expressions are expressions like any other. Far better than handling persistence by means of several sequential calls for methods with long names like its been done until now...
I have already shown clearly how language builtins hinder things. Having query features in a language is an utter waste of time for serious work - what you need is an option for external queries in SQL (or some other query language) which can be optimised by people who know what they are doing. Java persistence mechanisms (JDO and EJB) allow this (of course).
Anyway, the majority of persistence in Java (and LINQ) is 'transparent' - objects are automatically retrieved as required and modified ones changed when transactions close. The amount of explicit querying should be minimal - which is why it is so dumb to have it as a language feature.
I can use JDO on the JVM in Python (Jython) right now. Unless I am very much mistaken, You won't be able to use LINQ in IronPython on.NET like that. Oh, and you will have to upgrade your.NET development anyway (more money for Microsoft).
(1) - upgrading to the latest language version is no more difficult than installing a new library in java (2) - it's actually just a syntatic extension handled by the parser. You can tweak current language parser to understand them and even get other language parsers to do the same.
Oh come on. This is just rubbish. Since when has upgrading an entire language been as simple as placing a library file on the path? You are really stretching a point here. You may want to mess about with language parsers, but I just want to open a library and use method calls. This will only take me a few seconds to do. How many seconds will it take you to 'tweak a language parser'!!
And, of course, you have completely neglected my point about being able to use things with old code. The new Java JDO can be used entirely transparently even with compiled old code from 10 years ago.
well, java programmers used to its extreme verborragy actually think of XML as a pretty lightweight solution, comparetively. They'll really never "get it"...
No - it is precisely the other way around - the objectors just don't "get" what XML is for or what it does: Not only does it allow any configuration to be validated, it also easily allows existing formats to be cleanly extended and transformed in standard ways, and it has standard mechanisms for embedding binary information and also can handle internationalisation.
The 'verbosity' argument is plain nonsense - any decent editor or IDE will not only auto-complete your XML for you, but will also understand the definitions and suggest tags for you.
i wish it was as simple and straightforward as old fashioned key=value pairs... how much easily handled by both human and tools can it get?
No - that is a messy way to handle things, and a totally inadequate way to handle substantial configuration. You may think having several hundred key-value pairs is a really neat way to handle setting things up - I think it is an unmanageable and unmaintainable mess.
I would love to see an example of someone trying to code up a tree structure in 'key-value pairs'!
that's "sometimes", not "every-friggin-time" like the java culture predicts
In Java, you can safely perform unsynchronized reads and writes to an int member variable without worrying that on some platform, somewhere, a thread might read garbage from that variable because of concurrency. (This statement dates to 2001; now I hear strange terms like "64-bit Java," so this might no longer be true.)
It is still true. Java guarantees the size of things like int no matter what the platform, and guarantees atomicity of accessing such variables. Of course, on 64-bit platforms you naturally get safe access to larger structures, but that is not guaranteed portable.
What has happened that has enabled java to be used on "embedded" devices such as phones and PDAs is that they have stopped being low memory devices.
Typical embedded design memory space was in the 512k to 4 meg range when companies first started trying to deploy java into the space in 1997. I was there working with Wind River and transvirtual in that space. Java designs could barely manage to squeeze into 30 meg boards with the bare minimum of functionality.
The main form of Java for these situations is J2ME, which can be very small indeed - take a look at the J2ME JSR(30) -
"This configuration provides standard platform for small, resource limited, connected devices characterized as follows:
* 128K to 512K total memory available with not a bare minumum of functionality (obviously Swing is not there).
Traditionally "embedded" referred to devices which were not explicitly computers. Java is only performing strongly in devices which are becoming quite explicitly computers, and which have bountiful RAM for their tasks.
Not true. There is a rapidly growing market for Java is low-memory situations. J2ME development is strong, and it is targetted specifically at low-memory devices. The thriving mobile phone app/game market is not targetted at devices with tens of megabytes of ROM and RAM available for Java and its applications.
Also, Java is sometimes chosen as the language for extremely low memory devices because it has a highly compact bytecode, which can take up less space than native code.
nope. the problem is when you have a poor enough language without support for high level constructs and has to do literally anything with libraries. it's just a lot more tiresome than builtin language support...
It isn't a poor language - it was carefully designed to take the best of C++ while cutting out things that demonstrably led to poor maintanability (such as operator overloading). New features like generics and annotations have been added, but they are added slowly to avoid the mess that other languages grew into.
But anyway, there is a very good reason for having things in libraries - it allows competing implementations to provide functionality. For example, you can have competing implementations of ORMs, remoting, etc.
An example of why this a good idea is to see what happens when it isn't done. An example of this is in the next version of C# and VB.NET, where object persistence is handled by language extensions (LINQ). The problems are that (1) everyone has to upgrade to the latest language version to use these features and (2) you only get the features in those languages.
The Java way is better. Very few of the libraries depend on precise versions (you can use the latest JDO 2.0 with Java from 5 years ago), and you can use all the libraries from languages other than Java: I even use JDO from Ruby (as JRuby), and you can use them from Groovy, BeanShell, or Python on the JVM.
yeah, shame it's not used more often in the java world rather than the XML craze...
I have never understood the objection to XML. Having a standard format for configuration that can be easily handled by tools and cleanly upgraded seems like an excellent idea.
Configuration by convention has its place, but sometimes having explicit statement of what is being done makes things clearer.
There is _no_ common denomonator to these languages. Some have virtual machines as sophisticated as the jvm. Some have simple hand-hacked runtimes. Some are compiled. Some have features and dynamicism Java cannot hope to touch. Some are terse. Some are verbose. Some are forgotten and old. Some are quite new. Java uses more memory than every single one, and that is a major weakness of java in practical terms at this time.
I know. This is a real weakness in Java. It would have been great if it was a far more memory efficient languages, because then it could have been used in a wide range of low-memory situations like embedded devices, PDAs or mobile phones....
I currently avoid Java like the plauge, my reasons are the same reasons that java isnt included in debian... http://www.debian.org/doc/manuals/debian-java-faq/ ch5.html#s-license-concerns if they address those license concers i would be much happier...
Debian is simply a platform for running software. It is just a part of your system. There is no reason why Java should not be another part. Is your BIOS from debian? How about the code embedded in your graphics card? Is your processor open source?
Wow! Amazing! It's no wonder people are starting to consider Java for numerical code. Great, usefull post.
There is a problem, though... OOP and numerics really don't go well together. To write high performance numerical Java you have to code a lot like pure C, or even worse - like Fortran.
Re:If they do, it will all depend upon the license
on
Will Sun Open Source Java?
·
· Score: 3, Interesting
I diagree. Java is far to bloated and complicated. I've been using it since it first came out and I balk at the vast array of libraries you need to use or choose between to get anything done. I feel really sorry for anyone coming to it for the first time.
I really don't understand this. Having a rich and versatile range of libraries is a problem?
Personally I use Ruby (on Rails) these days for web development: convention over configuration is, imo, a much more important advance in the art than object-orientation was.
And Java has had this for years. I use JDO to persist my Java objects (it is a far more powerful and versatile system than Rails - much faster, and can persist to non-relational stores as well). How much configuration do I need in principle to describe my schema? Nothing but a list of classes. By default, the schema is created and mappings are automatically set up based on the field names of my classes. By default, no configuration needed.
Then we run a simple benchmark on real data of the codes, and the C++ variant is 10x or faster than the Java variant.
This is simply bad coding. This kind of thing often happens when the Java is written in a more OOP way than the equivalent C or C++ applications. Even C++ can be made slow by such coding.
Java is not slow. There are some standard international benchmarks used to test language speed. One of them is Linpack:
Typical results (MFLOP values - the higher the better):
C/icc (-O3 -xN) 402 C/Visual C++ (/Ox/G7/arch:SSE2) 399 C/gcc (-O3 -funroll-loops) 393 Java/Sun JDK 1.5.0 Server VM 379 Java/Sun JDK 1.4.2 Server VM 379
Java is within a few percent of gcc speed, and pretty close to better C compilers.
I remember exactly the same arguments raised against C++ in the 80s - it was 'too slow' to use compared with C. It was all a matter of coding style.
Well, I'd like to understand how you think Java is "designed for scalability". In my experience, it scales up poorly: its garbage collector is limited, object allocation has a huge overhead compared to other systems, and its libraries (e.g., collection libraries) don't work well for big collections. It seems to me Java fails already in some pretty elementary areas of scalability.
Sorry, but this is obviously nonsense, because scalability is the primary reason why major corporations use Java. E-Bay is one of the highest traffic sites on the web, and they use J2EE.
So who am I to believe about this - you or E-Bay, or most major banks, or stock exchanges handling hundreds of millions of transactions each day on J2EE?
Come on, be concrete. What does "one of the primary languages" mean?
I don't know - why don't you ask them?
A lot of places are using Java for research in parallel computing (and Edinburgh may be one of them); it's convenient for research because Java fails to address many of icky details of numerical computing (eg. structs, multidimensional arrays, efficient genericity, machine floating point, efficient error handling, extra precision,...). But most major Java numerics efforts (including Java Grande, which Edinburgh's EPCC prominently refers to) died about three years ago when it became clear that Sun wasn't going to fix Java for numerical computing. If there is any life left in numerical Java, I'd like to hear about it. As far as I can tell, Sun never even bothered to implement their multidimensional array proposal.
You are right that Java is not well-designed for coding numerical work - it is syntactically awful for that (even so, that has not put me off), but this is not the point. This was an illustration of Java performance; that it is no longer the sluggish poor relation to C it used to be.
Java numeric work is still active - just because one project or site dies, does not mean things are over. There are now commercial numeric packages in Java such JSML, and open source packages like colt:
"There is a perception by many that the Java language is unsuited for such work. However, recent trends in its evolution suggest that it may soon be a major player in performance sensitive scientific and technical computing. For example, IBM Watson's Ninja project showed that Java can indeed perform BLAS matrix computations up to 90% as fast as optimized Fortran. "
"The latest stable Colt release breaks the 1.9 Gflop/s barrier on JDK ibm-1.4.1, RedHat 9.0, 2x IntelXeon@2.8 GHz."
So, who do we believe? IBM, CERN or you?
Well, for the kind of client you have in mind, so would I, because it's easy to sell to their management, because they have the money to pay a premium for Java and Oracle, and because they can easily pay for it. Hey, if they insist and they pay, we'll write in assembly language. But for my own company, I wouldn't dream of using Java and Oracle--it's way too expensive and development is way too slow.
Sorry, but I don't sell to management. I sell to the technical experts of the company who understand IT. You can ignore my point if you wish, but to have a platform you can trust matters - you can't (yet?) trust Mono for robust commercial server apps. Some of the companies may soon grow to the point where they will need clustered services. Mono simply doesn't provide that on Linux. J2EE does. This is not a management choice - it is a serious technical one.
The Mono developers agree about this - so who do I believe about this - you or them?
To say that development in Java and Oracle is expensive and slow is just utter rubbish. You can develop with Java and Oracle for free, and there is no reason why development in Java should be any slower than with your favourite language - C#.
Yes, isn't it great? I think the J2EE standard is really holding back Java. Oh, in the short term, a "standard" gives man
Sure it matters. A lot of people have issues with it because of the license. It would clearly expand the number of potential adopters to go open source. More adopters will mean better tools.
I really don't think that a lot of people do have issues with the license. Sure, a lot of OSS supporters do, and a reasonable number of Slashdot posters seem to, but that is, I am afraid, a small fraction of the total developer community, and hasn't stopped Java becoming dominant.
And as for better tools, well one of Java's strengths has always been the quality of tools. There are products like Hibernate, and IDEs like Eclipse or NetBeans. No-one can complain about the quality of tools.
But a lot of people would find it more desireable. You can trust that java won't go away in open source, whereas you can't really say the same as long as SUN is at the helm.
Java isn't going away with or without Sun at the helm. To state otherwise is to neglect the fact that other companies have invested hugely in Java, like IBM.
There are also obvious opportunities for performance enhancement that could be addressed in an open source process. I recently benchmarked ten of my applications in c++ and java, java is about 2x slower for most of the cases I tried, and never faster. To me, that's perfectly acceptable, but java could make more inroads into other areas of computing if it was more competitive in performance. More inroads means more developers, and that means better tools, which is what I yearn for.
It is wishful thinking to believe that a mass of open source developers could add much to the performance. Can you show me an example of any equivalent open source language that is respected for its high performance? OSS C/C++ and Fortran compilers are not known for being top of the range in this area, and OSS attempts to replicate Java lag well behind in terms of VM performance.
I regularly benchmark Java against C, as I do serious numeric work, and I find that recent VMs are very close to C, and nowhere near as slow as half the speed. This not just my experience - there are products out there that illustrate this speed - high-performance pure Java databases for example, and the Java app server Tomcat can come close to Apache speed in serving pure web pages. I don't think performance is an issue anymore.
Did you remember to do a "warm-up" phase for java to enable all JIT-compilation to take place before doing the real test? (See here for more tips on this).
This is almost always forgotten. I have seen reports that complain how slow Java is based on running benchmarks for less than a second. The JIT (or these days, Hotspot) doesn't stand a chance. I took the same benchmarks, and ran them for 5 or 10 times longer and Java easily matched C performance.
Let us not scoff at humble beginnings, assuming they even are such. As would seem particularly apt for Ruby: "A journey of a thousand miles must begin with but a single step."
I think for many purposes Ruby has a really great future. Personally, I love the language. What I scoff at is the unhumble nature of so much that surrounds Ruby like now, like the Rails supporters who claim that Ruby on Rails is already demolishing Java.
A Java has shown, a journey of a thousand miles takes a lot of slow single steps:)
Java may have finally replaced C++, and growth may continue as it replaces legacy languages, but I think my point still stands - people no longer see it as a panacea. The 'hype' cycle is over, followed by the trough of despondency, and now we are into the phase of real use. Which is generally when the cutting-edge move off elsewhere.
My analysis is different. There definitely was an initial hype cycle, and definitely a later slump (largely because early Java definitely did not deliver on its promises), but now there is a real renewal of interest - after all, the replacement of C as the #1 language has only just happened. Most of the cutting edge aren't moving elsewhere - there are exciting new technologies in Java that aren't available in any other language that improve productivity, such as JSF (write once, render anywhere - JSF allows the writing of an interface that will render on web pages, SVG, Flash, even VT100) and JDO 2.0 (persist your Java objects to databases, LDAP, SOAP, CSV, XML...). The JVM itself is becoming an interesting platform for other languages like Groovy and JRuby.
C# also defangs Java to a large degree. It offers your career MS developer much the same linguistics as Java, but integration with more familiar APIs.
I have to disagree. C# (unlike other.NET languages) has hardly impacted Java growth. My impression is that C# is largely being used (along with VB.NET) as a replacement for legacy VB6 and Visual C++ on client-side Windows platforms. C# is really not widely used - Visual Basic.NET and ASP.NET are more significant.
A large amount - by volume - of web development IS in PHP.
Can I also disagree here as well:) ?
A large number of web applications are written in PHP, but that does not by any means amount to a large volume of web development.
The majority of small hosting companies don't even offer JSP hosting.
Yes, but there are specific technical reasons for this. The JVM is very poorly designed for multi-user hosting. Also, JSP development is designed to make use of memory-resident session- and application-scope storage - something you need for serious commercial development, but something you really don't want for commercial mass hosting.
I should add that I'm not wholly convinced by all Tate's arguments either; the key thing he missed for me is that the real solution most people need for the web app problem is a better client rather than a more productive JSP. If JavaScript can come back, perhaps Applets can.
Amazing work is going on with Java web clients right now. The key technology is JSF (JavaServer faces). There is a large community building up writing rich components for this system, which include built-in javascript and AJAX functionality. JSF has also started to remove the need for JSP to produce HTML, through technologies such as facelets.
I'm well aware there's more to development that web pages and web apps, but I'm still sceptical about Java desktop apps. Look-and-feel is more than using native widgets.
Which is why there is so much effort going into the next Swing version. In Java 6, Swing will be pixel-by-pixel identical to native desktop widgets on most platforms, but also extremely well integrated to the desktop systems and with hardware acceleration where available.
As I said, I do apologise. I made flippant and easy jokes about your post.
[Or at least, so it seems to me, but I admittedly don't know much about IBM's efforts.]
IBM write superb JVMs - they are generally faster and leaner than Sun's offerings. I often wonder why everyone focuses on Sun as a source of open source Java - IBM is such a supposed supporter of open source - why can't they provide this?
Performance isn't a hot issue for me with the sort of small/medium projects I do, but you can extend these languages in C (just like using JNI) if you've got a severe code bottleneck.
I don't think the JNI situation is comparable. The Java implementation itself may fall back to JNI for certain things (such as to handle OS-specific calls for things like threading or file handling), but user code almost never has to, because Java is now a highly performant language. And this is a good thing, because in my experience extending languages by falling back to C leads to a maintenance nightmare. You lose all the agility and portability of the original language; you end up with OS-specific libraries that have to be recompiled to deal with things like different word lengths. Even having one such library can be a major support headache.
If you've never worked at Python before, you might enjoy a look at it, too; it's also a great OO language, although it's not fully object-oriented.
I know - I use python as my main language for system scripting - I find it invaluable.
Or combine it with what you already know in Jython (that's Python written in Java)!
Unfortunately, Jython is way behind python, and development seems to have stopped.
If you liked some of the ideas behind Smalltalk (like full object-orientation and the "do:" blocks) you might want to give Ruby a try.
Oh I have, and I have even in a very very minor way contributed to the development of JRuby. I love the idea of being able to script together Java classes on the JVM using JRuby.
However, in my view, there are two problems with Ruby in any form.
The first, and most serious is performance. I deal with code that may involve batch processing of millions of records, or the processing of and reporting on gigabytes of logfiles, or the manipulations of images that may be tens of megabytes in size. Java has the performance of C, so handles these situations with ease. Ruby doesn't stand a chance.
The second is the safety of the language. I write applications that may consist hundreds of thousands of lines of code. Static type checking provides an amazing amount of checking of this code in a way that unit and functional testing could never do. This is especially the case with Ruby, where if I write:
class String
def mymethod
end end
there is no guarantee that someone else won't also do that in their code and override my work. Clashing extensions to base classes has been a major problem with languages like Smalltalk - you can get major problems compiling in different packages. With Ruby, you don't even get that safety - added code can simply walk all over existing functionality. It may be possible to cope with this in smallish applications, but beyond that it is going to be a potential support and maintance nightmare, making applications extremely fragile.
I intend to use Ruby increasingly for future work, primarily on the JVM, but as a general development language it fails in the way that Smalltalk did before it - it has neither the safety or performance required for my work.
What's happening - and I think it's a postive thing - is that we're seeing the death of the idea that Java is going to replace all other programming languages, which seemed a major meme for a while. (Certainly University courses bought into it, teaching it as the main programming language in the 90s).
For better or worse, Java is definitely showing signs of replacing most other programming languages for the majority of development. Take a look at the widely-respected TIOBE index of internet language resources and experts, and Java has finally overtaken both C and C++ as number one language, and shows no signs of slowing growth.
Bruce Tate's 'Beyond Java' is an interesting read on the subject - his main theme is that Java has become too tied up with the needs of enterprise vendors and developers - hence it's heavy use in complex server side applications - while the actual majority (numerically) of developers needs something to simply get data onto web pages and persist it back. (The most common commercial web application is the small web-based store).
If that were true, the majority of all web-based development would have switched to PHP, which it evidently hasn't. I am very familiar with Tate's views; he is talking about one niche of development. Contrary to popular belief, development is about far more than just web pages!
Well, and what actually happened with the strategy Sun adopted? Sun lost control to "Microsoft bastardization"--.NET is essentially an incompatible Java, completely with Java backwards compatibility.
So what actually happened with the strategy Sun adopted? Java has become one of the most successful languages ever released.
Take a look at the TIOBE index - "The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors." This is widely used measure of the state of things in IT.
Where is C#? Right down the list, below Basic and Perl.
C#,7(8),4%
Any statement that Sun and Java have generally lost control of anything to.NET and C# is simply flying in the face of evidence.
Microsoft would do almost anything to get the server-side and mobile device market penetration of Java.
The open source community has created multiple C# implementations and gone to work innovating and improving the platform, as well as integrating it with the Linux desktop.As a result, some really nifty Linux desktop apps are being written in C#. And, as a bonus, there are also open source.NET implementations, giving developers easy cross-platform capabilities between Windows and Linux should they desire that.
Sorry, but nice though they are, nifty Linux desktop apps form a totally insignificant part of IT development. Also, there are not open source.NET implementations, and to claim this is seriously misleading. There are open source implementations of the CLR with attempts to make.NET-compatible libraries which are not supported by the developers of.NET and which, even the open source developers of these implementations freely admit, are not up to a standard for being able to write high-performance and scalable server side applications.
BTW, this is a repeat of the NeWS disaster; that, too, was a nice core idea, the design had some serious flaws, the implementation was mediocre at best, and ultimately the industry rejected it because Sun was waffling on whether to open it or not. Sun apparently doesn't learn from their mistakes.
The industry has, of course, shown no sign whatsoever of of rejecting Java, and all the evidence (such as I have given above) indicates that it is still growing in use.
If Java is a 'mistake', it is also a 'mistake' that is being invested in by all major software companies (with the exception, of course, of Microsoft).
And it is a 'mistake' used every day by millions of developers, and backed by Sun, IBM, HP, BEA, SAP, Oracle, Peoplesoft, and countless others.
So who do we believe about this? You, or IBM, Sun, HP, Oracle?
Sorry, but if you keep posting like this, no matter how sincere your view, you will get a reputation, no matter how undeserved, as a troller. No matter how much you personally dislike Java, that dislike does not translate into it being rejected by the industry. Some new technology is inevitably going to replace Java in significant areas of its use; but that certainly has not happened yet.
Slashdot Mirror
Ruby on Rails is included in the definition of Web 2.0
It it? Where?
Well, by that reasoning, almost every language scales. I mean, Yahoo! uses Python for lots of their transactions, and Flickr! uses PHP.
:)
Sorry, but 'lots of their transactions' does not equal hundreds of millions of transactions a day. If Flickr times out, no-one cares. If a stock market transaction, which has to complete in a fraction of a second, times out then serious money is lost. This is, of course, why people use J2EE.
The latest Colt release was in 2004.
So what?
Can you get it into your thick head that we agree on this point? That's why I was saying: I would offer these people Java, because that's what they want and what fits into their organizations. That doesn't mean that Java is the most cost-efficient or technically best solution, it means that it can get the job done at the price these people are willing to pay.
What price? Java is free, and high-performance app servers (Glassfish, JBoss) are free. People use Java because it is the most cost efficient and technically best solution. If you can suggest another very high-peformance easily clusterable solution....
Furthermore, I think in the enterprise space, C# will stomp over Java once people have create the equivalent functionality to J2EE, and they will; of course, being unconstrained by Sun's meddling and incompetent hand, there will be multiple different efforts and approaches, which will be good.
The developers of Mono don't think so.
That's your problem: you don't think yourself, you make decisions based on who you believe and what people said half a dozen years ago.
Nice ad hominem answer
being unconstrained by Sun's meddling and incompetent hand, there will be multiple different efforts and approaches, which will be good.
For any given aspect of Java (even Aspects!) there are a number of different efforts and approaches already. From GUIs, Web frameworks, Persistence APIs and so on, there are many alternative approaches.
It's no wonder that the Java platform is getting worse with every release; most of the smart people have left for greener pastures.
You still have not explained why I should believe you as against E-Bay about J2EE performance; you as against IBM and CERN about math capability; You or the Mono developers about the capabilities of C# on Linux?
"For example, there is an implementation of Hotspot for J2ME/CLDC that runs in 1MB."
Bullshit.
No, it is a fact:
http://java.sun.com/products/cldc/faqs.html
"13.What is the CLDC HotSpot Implementation?
The CLDC HotSpot[tm] Implementation is a high performance, battery-preserving virtual machine that is compliant with the CLDC specification. It not only offers significantly improved performance over the KVM, but it also offers greater portability and faster time to market. The CLDC HotSpot Implementation is suitable for devices based on ARM microprocessors/controllers, and with 512KB to 1MB of total memory available for the Java technology stack. The latest release of the CLDC HotSpot Implementation is version 1.0.1."
Which is exactly why it'll never happen. The giant Java library ensures that, even with a 100% compatible JVM, most Java applications will only run on the Sun runtime. (Especially applications that use "sun.*" or "com.sun.*" packages in open defiance of Sun themselves saying not to do that. But that's beside the point.)
Sorry, but this is plain wrong. Most Java applications will run on any certified JRE of the appropriate version. That is the point of certification of the JDK and JRE! Even some of the largest and most complex Java applications like Eclipse will run on any vendor's JDK. Even Sun's NetBeans will do this!
Anyway, most Java applications are Web applications, deployed on J2EE app servers like Tomcat and JBoss: these have no specific requirements for the Sun JRE.
By having a massive and hard to implement class library, Sun ensures that anyone else trying to create a compatible Java runtime will always be playing catch-up. They'll never be able to be 100% compatible with the "latest and greatest" Java runtime.
This is rather strange and conspiratorial thinking! Sun don't include a large library with Java to ensure that anyone else plays catch-up - the library has been extended over the years based on developer demand, with things like a more powerful Collections framework (Java 1.2) and concurrency utilities (Java 1.5).
And that's just the way Sun wants it - they're able to keep control of Java that way. Open sourcing the libraries would cause them to lose that control. And that's why it'll never happen.
There is no reason why open sourcing would involve any loss of control. Something can't be called 'Java' unless it passes the compatibility tests, open source or not.
There are already an open source projects which intents to provide a full, up-to-date implementation of Java - Apache Harmony.
If you have tons of memory, Sun's Hotspot VM is very fast.
And it is pretty good even if you don't. For example, there is an implementation of Hotspot for J2ME/CLDC that runs in 1MB.
Exactly. That is what happened with C++, with Visual Basic, and is what is likely to happen with
this is not what java culture says. i guess you're in denial. If it doesn't use several Struts Action beans, form beans, some ant xml and struts-config.xml, it isn't really serious programming...
You haven't a clue have you? If you think Java web programming is just Struts! There is Tapestry, Seam (no config files!), RIFE, Wicket etc. Pick the way you want to work, and choose your framework. No XML if you don't want it; no action or form beans. Tapestry is used for some of the largest sites - that is serious programming.
yeah, here's a lesson for you about automatic validation, like compiler validation:
Some validation is better than none, especially when you are dealing with thousands of lines.
Validation is not proof of correctness.
Who said it was? But to say that no validation is better is idiotic.
"Even the Mono developers have said that it is not suitable for scalable high-end work."
a link would be nice. otherwise, i just don't believe it.
OK.
http://www.itwriting.com/monointerview.php
"What is clear is that Mono (as opposed to
is that like having a camel getting transformed into a lizard? ok, ok, so there are a few intersection between the two formats. Again, they'd be represented by similar keys.
you are missing the point - intersections will break things.
ah! is Java Data Objects those huge in-memory database of objects? hope not.
Of course not (unless you want to use a in-memory database). JDO is extremely efficient - I have run batch processes where a single transaction can handle hundreds of thousands of records, with mimimal memory use.
Anyway, Rails developers do everything as classes, rarely needing to tweak the SQL the framework generates for the classes..
Which is potentially disastrous. Code up pages and logic based on what you think is in those generated classes, then all someone has to do is change the database a little, and your code goes 'bang'. It is a really dumb way to work - great to get things going - but very bad for maintenance. There are far better ways to work - especially in Ruby, such as Og. Designing your data model purely as database tables is extremely old-fashioned.
"an API that lets you write a GUI that can display on HTML, WML, Flash, SVG, Swing, even VT100!"
is it like a XUL xml document describing a GUI and then translated for several GUI engines? it's a task that just depends on sheer brute force from a huge taskforce. Java has a huge army of developers and they'll create all kinds of works for their platform. no big deal, just brute force...
No, it is nothing like an XUL XML document describing a GUI. It is a component-based system into which you can plug different renderkits for whatever display you want to use, and you can dynamically switch use as the application is running.
It is ok - but if you want to continue, how about some actual debates about facts, and not about what you think Java is like (as against what it is like?). I can provide plenty of facts to back up my arguments.
otoh, there's plenty of @ nonsense. :)
:)
:)
No there isn't this is only for one small feature (Annotations) of the latest Java.
ok, let me clarify: CPU performance got one better, memory usage grew up like craze -- specially with the 1000+ libs needed even for small projects -- and programmer performance went down a lot, drowned in endless abstraction layers, some dozens of APIs and a few IDEs open.
OK - I'll take the bait. Exactly which 1000+ libs do you need for small projects? Which abstraction layers?
in an idealized world, object-relational mappings are perfect, generated queries are perfect and perform great and all that jazz. In the real world, serious work also means a few comprimises, including a few manual hacks so things work properly.
Of course you can do manual hacks in JDO, EJB, Hibernate or whatever. But having a 'hack' built in to the language is no way to go.
why do they need to be external? why so much loose coupling, so many layers of abstraction? It's portable, modularized, loosely coupled, just like University teachers and academics in general like to tell. But all that at an incredibly brain twisting complexity anda huge framework of many different separate projects...
No. They neither need to be external, or have to be external. You don't have to have layers of abstraction if you don't want to. Things can be as simple as you like.
You really do have some weird 'straw man' image of how Java developers work, don't you?
"Not only does it allow any configuration to be validated, it also easily allows existing formats to be cleanly extended and transformed in standard ways, and it has standard mechanisms for embedding binary information and also can handle internationalisation."
wow man! what a load of marketroid terminology and enterprise jargon! i'll take a week to completely undestand it...
OK - let me explain slowly.
"Configuration validated" - your IDE can see where you have made mistakes without you having to run the thing and get a program crash.
"Existing formats to be extended" - You decide you have missed out a setting in your config file, or you want to combine someone elses config file with yours. You can fix this without causing your program to crash when it reads the new file.
"transformed in standard ways" - Someone else has a config file format. You need to transfer your format to theirs. You don't need to do this by hand.
"embedding binary information" - obvious, surely.
"internationalisation." - a real tricky one. This means you can put international characters in your XML file so you can easily specify different settings in alternate languages.
Slow enough for you?
why is someone putting a tree data structure inside a configuration file for starters
Oh come on - there are loads of reasons! One example is if you want a different maps of values: You might, for example, have a set of parameters that should be set to one set of words if the language is 'en', and another set of words if the language is 'fr'.
Hey - that combines both structure and internationalisation - isn't XML cool?
yes, i know. I've worked with Eclipse and its many views, you know?
Yes, I find Eclipse immensely annoying - I use NetBeans
It's still annoying, regardless, and specially the Ant build.xml. Wow, they really were able to transform a simple Makefile into an incredibly dull and verbose pile of attribute=values inside tags!
Well, having had 25 years experience of tracking down obscure Makefile errors, give me build.xml and its validated format any day.
Tag soup for soup nazis!
Godwins law - you lose
Code completion will only get newbies nuts with so many different but similar options, while experient users will write the most used tags and attributes so fast code-complete won't even come to
like the barroque syntax or the performance? ;)
.NET like that. Oh, and you will have to upgrade your .NET development anyway (more money for Microsoft).
Baroque syntax? It is the same as C++ - in fact a lot less baroque - none of the * or & nonsense.
And sorry, but I can't take anyone seriously who says anything poor about Java performance. That is an issue that was dealt with years ago.
yeah, even operator overloading eventually gets there. There already are several DSL features in the java world, like its many web "expression languages"...
But that is not the point - the point is to keep the base langauge clean.
you don't mention the amazing language builtin benefits, like perfect integration with the language. LINQ expressions are expressions like any other. Far better than handling persistence by means of several sequential calls for methods with long names like its been done until now...
I have already shown clearly how language builtins hinder things. Having query features in a language is an utter waste of time for serious work - what you need is an option for external queries in SQL (or some other query language) which can be optimised by people who know what they are doing. Java persistence mechanisms (JDO and EJB) allow this (of course).
Anyway, the majority of persistence in Java (and LINQ) is 'transparent' - objects are automatically retrieved as required and modified ones changed when transactions close. The amount of explicit querying should be minimal - which is why it is so dumb to have it as a language feature.
I can use JDO on the JVM in Python (Jython) right now. Unless I am very much mistaken, You won't be able to use LINQ in IronPython on
(1) - upgrading to the latest language version is no more difficult than installing a new library in java
(2) - it's actually just a syntatic extension handled by the parser. You can tweak current language parser to understand them and even get other language parsers to do the same.
Oh come on. This is just rubbish. Since when has upgrading an entire language been as simple as placing a library file on the path? You are really stretching a point here. You may want to mess about with language parsers, but I just want to open a library and use method calls. This will only take me a few seconds to do. How many seconds will it take you to 'tweak a language parser'!!
And, of course, you have completely neglected my point about being able to use things with old code. The new Java JDO can be used entirely transparently even with compiled old code from 10 years ago.
well, java programmers used to its extreme verborragy actually think of XML as a pretty lightweight solution, comparetively. They'll really never "get it"...
No - it is precisely the other way around - the objectors just don't "get" what XML is for or what it does: Not only does it allow any configuration to be validated, it also easily allows existing formats to be cleanly extended and transformed in standard ways, and it has standard mechanisms for embedding binary information and also can handle internationalisation.
The 'verbosity' argument is plain nonsense - any decent editor or IDE will not only auto-complete your XML for you, but will also understand the definitions and suggest tags for you.
i wish it was as simple and straightforward as old fashioned key=value pairs... how much easily handled by both human and tools can it get?
No - that is a messy way to handle things, and a totally inadequate way to handle substantial configuration. You may think having several hundred key-value pairs is a really neat way to handle setting things up - I think it is an unmanageable and unmaintainable mess.
I would love to see an example of someone trying to code up a tree structure in 'key-value pairs'!
that's "sometimes", not "every-friggin-time" like the java culture predicts
In Java, you can safely perform unsynchronized reads and writes to an int member variable without worrying that on some platform, somewhere, a thread might read garbage from that variable because of concurrency. (This statement dates to 2001; now I hear strange terms like "64-bit Java," so this might no longer be true.)
It is still true. Java guarantees the size of things like int no matter what the platform, and guarantees atomicity of accessing such variables. Of course, on 64-bit platforms you naturally get safe access to larger structures, but that is not guaranteed portable.
If Sun were to GPL Java, it would be unstoppable.
That sounds to me rather like saying "If Windows were GPLed it would be on every desktop".
In case you hadn't noticed, Java has done rather well without being GPLed.
What has happened that has enabled java to be used on "embedded" devices such as phones and PDAs is that they have stopped being low memory devices.
Typical embedded design memory space was in the 512k to 4 meg range when companies first started trying to deploy java into the space in 1997. I was there working with Wind River and transvirtual in that space. Java designs could barely manage to squeeze into 30 meg boards with the bare minimum of functionality.
The main form of Java for these situations is J2ME, which can be very small indeed - take a look at the J2ME JSR(30) -
"This configuration provides standard platform for small, resource limited, connected devices characterized as follows:
* 128K to 512K total memory available with not a bare minumum of functionality (obviously Swing is not there).
Traditionally "embedded" referred to devices which were not explicitly computers. Java is only performing strongly in devices which are becoming quite explicitly computers, and which have bountiful RAM for their tasks.
Not true. There is a rapidly growing market for Java is low-memory situations. J2ME development is strong, and it is targetted specifically at low-memory devices. The thriving mobile phone app/game market is not targetted at devices with tens of megabytes of ROM and RAM available for Java and its applications.
Also, Java is sometimes chosen as the language for extremely low memory devices because it has a highly compact bytecode, which can take up less space than native code.
nope. the problem is when you have a poor enough language without support for high level constructs and has to do literally anything with libraries. it's just a lot more tiresome than builtin language support...
It isn't a poor language - it was carefully designed to take the best of C++ while cutting out things that demonstrably led to poor maintanability (such as operator overloading). New features like generics and annotations have been added, but they are added slowly to avoid the mess that other languages grew into.
But anyway, there is a very good reason for having things in libraries - it allows competing implementations to provide functionality. For example, you can have competing implementations of ORMs, remoting, etc.
An example of why this a good idea is to see what happens when it isn't done. An example of this is in the next version of C# and VB.NET, where object persistence is handled by language extensions (LINQ). The problems are that (1) everyone has to upgrade to the latest language version to use these features and (2) you only get the features in those languages.
The Java way is better. Very few of the libraries depend on precise versions (you can use the latest JDO 2.0 with Java from 5 years ago), and you can use all the libraries from languages other than Java: I even use JDO from Ruby (as JRuby), and you can use them from Groovy, BeanShell, or Python on the JVM.
yeah, shame it's not used more often in the java world rather than the XML craze...
I have never understood the objection to XML. Having a standard format for configuration that can be easily handled by tools and cleanly upgraded seems like an excellent idea.
Configuration by convention has its place, but sometimes having explicit statement of what is being done makes things clearer.
There is _no_ common denomonator to these languages. Some have virtual machines as sophisticated as the jvm. Some have simple hand-hacked runtimes. Some are compiled. Some have features and dynamicism Java cannot hope to touch. Some are terse. Some are verbose. Some are forgotten and old. Some are quite new. Java uses more memory than every single one, and that is a major weakness of java in practical terms at this time.
I know. This is a real weakness in Java. It would have been great if it was a far more memory efficient languages, because then it could have been used in a wide range of low-memory situations like embedded devices, PDAs or mobile phones....
Er - something wrong with this argument, perhaps?
I currently avoid Java like the plauge, my reasons are the same reasons that java isnt included in debian... http://www.debian.org/doc/manuals/debian-java-faq/ ch5.html#s-license-concerns if they address those license concers i would be much happier...
Debian is simply a platform for running software. It is just a part of your system. There is no reason why Java should not be another part. Is your BIOS from debian? How about the code embedded in your graphics card? Is your processor open source?
Wow! Amazing! It's no wonder people are starting to consider Java for numerical code.
Great, usefull post.
There is a problem, though... OOP and numerics really don't go well together. To write high performance numerical Java you have to code a lot like pure C, or even worse - like Fortran.
I diagree. Java is far to bloated and complicated. I've been using it since it first came out and I balk at the vast array of libraries you need to use or choose between to get anything done. I feel really sorry for anyone coming to it for the first time.
I really don't understand this. Having a rich and versatile range of libraries is a problem?
Personally I use Ruby (on Rails) these days for web development: convention over configuration is, imo, a much more important advance in the art than object-orientation was.
And Java has had this for years. I use JDO to persist my Java objects (it is a far more powerful and versatile system than Rails - much faster, and can persist to non-relational stores as well). How much configuration do I need in principle to describe my schema? Nothing but a list of classes. By default, the schema is created and mappings are automatically set up based on the field names of my classes. By default, no configuration needed.
How long has JDO had this? Since 2000!
Convention over configuration is nothing new.
Then we run a simple benchmark on real data of the codes, and the C++ variant is 10x or faster than the Java variant.
/G7 /arch:SSE2) 399
This is simply bad coding. This kind of thing often happens when the Java is written in a more OOP way than the equivalent C or C++ applications. Even C++ can be made slow by such coding.
Java is not slow. There are some standard international benchmarks used to test language speed. One of them is Linpack:
http://www.shudo.net/jit/perf/
Typical results (MFLOP values - the higher the better):
C/icc (-O3 -xN) 402
C/Visual C++ (/Ox
C/gcc (-O3 -funroll-loops) 393
Java/Sun JDK 1.5.0 Server VM 379
Java/Sun JDK 1.4.2 Server VM 379
Java is within a few percent of gcc speed, and pretty close to better C compilers.
I remember exactly the same arguments raised against C++ in the 80s - it was 'too slow' to use compared with C. It was all a matter of coding style.
Well, I'd like to understand how you think Java is "designed for scalability". In my experience, it scales up poorly: its garbage collector is limited, object allocation has a huge overhead compared to other systems, and its libraries (e.g., collection libraries) don't work well for big collections. It seems to me Java fails already in some pretty elementary areas of scalability.
...). But most major Java numerics efforts (including Java Grande, which Edinburgh's EPCC prominently refers to) died about three years ago when it became clear that Sun wasn't going to fix Java for numerical computing. If there is any life left in numerical Java, I'd like to hear about it. As far as I can tell, Sun never even bothered to implement their multidimensional array proposal.
Sorry, but this is obviously nonsense, because scalability is the primary reason why major corporations use Java. E-Bay is one of the highest traffic sites on the web, and they use J2EE.
So who am I to believe about this - you or E-Bay, or most major banks, or stock exchanges handling hundreds of millions of transactions each day on J2EE?
Come on, be concrete. What does "one of the primary languages" mean?
I don't know - why don't you ask them?
A lot of places are using Java for research in parallel computing (and Edinburgh may be one of them); it's convenient for research because Java fails to address many of icky details of numerical computing (eg. structs, multidimensional arrays, efficient genericity, machine floating point, efficient error handling, extra precision,
You are right that Java is not well-designed for coding numerical work - it is syntactically awful for that (even so, that has not put me off), but this is not the point. This was an illustration of Java performance; that it is no longer the sluggish poor relation to C it used to be.
Java numeric work is still active - just because one project or site dies, does not mean things are over. There are now commercial numeric packages in Java such JSML, and open source packages like colt:
"There is a perception by many that the Java language is unsuited for such work. However, recent trends in its evolution suggest that it may soon be a major player in performance sensitive scientific and technical computing. For example, IBM Watson's Ninja project showed that Java can indeed perform BLAS matrix computations up to 90% as fast as optimized Fortran. "
"The latest stable Colt release breaks the 1.9 Gflop/s barrier on JDK ibm-1.4.1, RedHat 9.0, 2x IntelXeon@2.8 GHz."
So, who do we believe? IBM, CERN or you?
Well, for the kind of client you have in mind, so would I, because it's easy to sell to their management, because they have the money to pay a premium for Java and Oracle, and because they can easily pay for it. Hey, if they insist and they pay, we'll write in assembly language. But for my own company, I wouldn't dream of using Java and Oracle--it's way too expensive and development is way too slow.
Sorry, but I don't sell to management. I sell to the technical experts of the company who understand IT. You can ignore my point if you wish, but to have a platform you can trust matters - you can't (yet?) trust Mono for robust commercial server apps. Some of the companies may soon grow to the point where they will need clustered services. Mono simply doesn't provide that on Linux. J2EE does. This is not a management choice - it is a serious technical one.
The Mono developers agree about this - so who do I believe about this - you or them?
To say that development in Java and Oracle is expensive and slow is just utter rubbish. You can develop with Java and Oracle for free, and there is no reason why development in Java should be any slower than with your favourite language - C#.
Yes, isn't it great? I think the J2EE standard is really holding back Java. Oh, in the short term, a "standard" gives man
Sure it matters. A lot of people have issues with it because of the license. It would clearly expand the number of potential adopters to go open source. More adopters will mean better tools.
I really don't think that a lot of people do have issues with the license. Sure, a lot of OSS supporters do, and a reasonable number of Slashdot posters seem to, but that is, I am afraid, a small fraction of the total developer community, and hasn't stopped Java becoming dominant.
And as for better tools, well one of Java's strengths has always been the quality of tools. There are products like Hibernate, and IDEs like Eclipse or NetBeans. No-one can complain about the quality of tools.
But a lot of people would find it more desireable. You can trust that java won't go away in open source, whereas you can't really say the same as long as SUN is at the helm.
Java isn't going away with or without Sun at the helm. To state otherwise is to neglect the fact that other companies have invested hugely in Java, like IBM.
There are also obvious opportunities for performance enhancement that could be addressed in an open source process. I recently benchmarked ten of my applications in c++ and java, java is about 2x slower for most of the cases I tried, and never faster. To me, that's perfectly acceptable, but java could make more inroads into other areas of computing if it was more competitive in performance. More inroads means more developers, and that means better tools, which is what I yearn for.
It is wishful thinking to believe that a mass of open source developers could add much to the performance. Can you show me an example of any equivalent open source language that is respected for its high performance? OSS C/C++ and Fortran compilers are not known for being top of the range in this area, and OSS attempts to replicate Java lag well behind in terms of VM performance.
I regularly benchmark Java against C, as I do serious numeric work, and I find that recent VMs are very close to C, and nowhere near as slow as half the speed. This not just my experience - there are products out there that illustrate this speed - high-performance pure Java databases for example, and the Java app server Tomcat can come close to Apache speed in serving pure web pages. I don't think performance is an issue anymore.
Did you remember to do a "warm-up" phase for java to enable all JIT-compilation to take place before doing the real test? (See here for more tips on this).
This is almost always forgotten. I have seen reports that complain how slow Java is based on running benchmarks for less than a second. The JIT (or these days, Hotspot) doesn't stand a chance. I took the same benchmarks, and ran them for 5 or 10 times longer and Java easily matched C performance.
Let us not scoff at humble beginnings, assuming they even are such. As would seem particularly apt for Ruby: "A journey of a thousand miles must begin with but a single step."
:)
I think for many purposes Ruby has a really great future. Personally, I love the language. What I scoff at is the unhumble nature of so much that surrounds Ruby like now, like the Rails supporters who claim that Ruby on Rails is already demolishing Java.
A Java has shown, a journey of a thousand miles takes a lot of slow single steps
Java may have finally replaced C++, and growth may continue as it replaces legacy languages, but I think my point still stands - people no longer see it as a panacea. The 'hype' cycle is over, followed by the trough of despondency, and now we are into the phase of real use. Which is generally when the cutting-edge move off elsewhere.
.NET languages) has hardly impacted Java growth. My impression is that C# is largely being used (along with VB.NET) as a replacement for legacy VB6 and Visual C++ on client-side Windows platforms. C# is really not widely used - Visual Basic.NET and ASP.NET are more significant.
:) ?
My analysis is different. There definitely was an initial hype cycle, and definitely a later slump (largely because early Java definitely did not deliver on its promises), but now there is a real renewal of interest - after all, the replacement of C as the #1 language has only just happened. Most of the cutting edge aren't moving elsewhere - there are exciting new technologies in Java that aren't available in any other language that improve productivity, such as JSF (write once, render anywhere - JSF allows the writing of an interface that will render on web pages, SVG, Flash, even VT100) and JDO 2.0 (persist your Java objects to databases, LDAP, SOAP, CSV, XML...). The JVM itself is becoming an interesting platform for other languages like Groovy and JRuby.
C# also defangs Java to a large degree. It offers your career MS developer much the same linguistics as Java, but integration with more familiar APIs.
I have to disagree. C# (unlike other
A large amount - by volume - of web development IS in PHP.
Can I also disagree here as well
A large number of web applications are written in PHP, but that does not by any means amount to a large volume of web development.
The majority of small hosting companies don't even offer JSP hosting.
Yes, but there are specific technical reasons for this. The JVM is very poorly designed for multi-user hosting. Also, JSP development is designed to make use of memory-resident session- and application-scope storage - something you need for serious commercial development, but something you really don't want for commercial mass hosting.
I should add that I'm not wholly convinced by all Tate's arguments either; the key thing he missed for me is that the real solution most people need for the web app problem is a better client rather than a more productive JSP. If JavaScript can come back, perhaps Applets can.
Amazing work is going on with Java web clients right now. The key technology is JSF (JavaServer faces). There is a large community building up writing rich components for this system, which include built-in javascript and AJAX functionality. JSF has also started to remove the need for JSP to produce HTML, through technologies such as facelets.
I'm well aware there's more to development that web pages and web apps, but I'm still sceptical about Java desktop apps. Look-and-feel is more than using native widgets.
Which is why there is so much effort going into the next Swing version. In Java 6, Swing will be pixel-by-pixel identical to native desktop widgets on most platforms, but also extremely well integrated to the desktop systems and with hardware acceleration where available.
These are exciting times to be a Java developer.
Eh, just a little bit.
As I said, I do apologise. I made flippant and easy jokes about your post.
[Or at least, so it seems to me, but I admittedly don't know much about IBM's efforts.]
IBM write superb JVMs - they are generally faster and leaner than Sun's offerings. I often wonder why everyone focuses on Sun as a source of open source Java - IBM is such a supposed supporter of open source - why can't they provide this?
Performance isn't a hot issue for me with the sort of small/medium projects I do, but you can extend these languages in C (just like using JNI) if you've got a severe code bottleneck.
I don't think the JNI situation is comparable. The Java implementation itself may fall back to JNI for certain things (such as to handle OS-specific calls for things like threading or file handling), but user code almost never has to, because Java is now a highly performant language. And this is a good thing, because in my experience extending languages by falling back to C leads to a maintenance nightmare. You lose all the agility and portability of the original language; you end up with OS-specific libraries that have to be recompiled to deal with things like different word lengths. Even having one such library can be a major support headache.
If you've never worked at Python before, you might enjoy a look at it, too; it's also a great OO language, although it's not fully object-oriented.
I know - I use python as my main language for system scripting - I find it invaluable.
Or combine it with what you already know in Jython (that's Python written in Java)!
Unfortunately, Jython is way behind python, and development seems to have stopped.
If you liked some of the ideas behind Smalltalk (like full object-orientation and the "do:" blocks) you might want to give Ruby a try.
Oh I have, and I have even in a very very minor way contributed to the development of JRuby. I love the idea of being able to script together Java classes on the JVM using JRuby.
However, in my view, there are two problems with Ruby in any form.
The first, and most serious is performance. I deal with code that may involve batch processing of millions of records, or the processing of and reporting on gigabytes of logfiles, or the manipulations of images that may be tens of megabytes in size. Java has the performance of C, so handles these situations with ease. Ruby doesn't stand a chance.
The second is the safety of the language. I write applications that may consist hundreds of thousands of lines of code. Static type checking provides an amazing amount of checking of this code in a way that unit and functional testing could never do. This is especially the case with Ruby, where if I write:
class String
def mymethod
end
end
there is no guarantee that someone else won't also do that in their code and override my work. Clashing extensions to base classes has been a major problem with languages like Smalltalk - you can get major problems compiling in different packages. With Ruby, you don't even get that safety - added code can simply walk all over existing functionality. It may be possible to cope with this in smallish applications, but beyond that it is going to be a potential support and maintance nightmare, making applications extremely fragile.
I intend to use Ruby increasingly for future work, primarily on the JVM, but as a general development language it fails in the way that Smalltalk did before it - it has neither the safety or performance required for my work.
What's happening - and I think it's a postive thing - is that we're seeing the death of the idea that Java is going to replace all other programming languages, which seemed a major meme for a while. (Certainly University courses bought into it, teaching it as the main programming language in the 90s).
For better or worse, Java is definitely showing signs of replacing most other programming languages for the majority of development. Take a look at the widely-respected TIOBE index of internet language resources and experts, and Java has finally overtaken both C and C++ as number one language, and shows no signs of slowing growth.
Bruce Tate's 'Beyond Java' is an interesting read on the subject - his main theme is that Java has become too tied up with the needs of enterprise vendors and developers - hence it's heavy use in complex server side applications - while the actual majority (numerically) of developers needs something to simply get data onto web pages and persist it back. (The most common commercial web application is the small web-based store).
If that were true, the majority of all web-based development would have switched to PHP, which it evidently hasn't. I am very familiar with Tate's views; he is talking about one niche of development. Contrary to popular belief, development is about far more than just web pages!
Well, and what actually happened with the strategy Sun adopted? Sun lost control to "Microsoft bastardization"--.NET is essentially an incompatible Java, completely with Java backwards compatibility.
.NET and C# is simply flying in the face of evidence.
.NET implementations, giving developers easy cross-platform capabilities between Windows and Linux should they desire that.
.NET implementations, and to claim this is seriously misleading. There are open source implementations of the CLR with attempts to make .NET-compatible libraries which are not supported by the developers of .NET and which, even the open source developers of these implementations freely admit, are not up to a standard for being able to write high-performance and scalable server side applications.
So what actually happened with the strategy Sun adopted? Java has become one of the most successful languages ever released.
Take a look at the TIOBE index - "The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the world-wide availability of skilled engineers, courses and third party vendors." This is widely used measure of the state of things in IT.
Language,Language position(last year),rating
Java,1(2),21%
C,2(1),18%
C++,3(4),11%
PHP,4(5),11%
and so on.
Where is C#? Right down the list, below Basic and Perl.
C#,7(8),4%
Any statement that Sun and Java have generally lost control of anything to
Microsoft would do almost anything to get the server-side and mobile device market penetration of Java.
The open source community has created multiple C# implementations and gone to work innovating and improving the platform, as well as integrating it with the Linux desktop.As a result, some really nifty Linux desktop apps are being written in C#. And, as a bonus, there are also open source
Sorry, but nice though they are, nifty Linux desktop apps form a totally insignificant part of IT development. Also, there are not open source
BTW, this is a repeat of the NeWS disaster; that, too, was a nice core idea, the design had some serious flaws, the implementation was mediocre at best, and ultimately the industry rejected it because Sun was waffling on whether to open it or not. Sun apparently doesn't learn from their mistakes.
The industry has, of course, shown no sign whatsoever of of rejecting Java, and all the evidence (such as I have given above) indicates that it is still growing in use.
If Java is a 'mistake', it is also a 'mistake' that is being invested in by all major software companies (with the exception, of course, of Microsoft).
And it is a 'mistake' used every day by millions of developers, and backed by Sun, IBM, HP, BEA, SAP, Oracle, Peoplesoft, and countless others.
So who do we believe about this? You, or IBM, Sun, HP, Oracle?
Sorry, but if you keep posting like this, no matter how sincere your view, you will get a reputation, no matter how undeserved, as a troller. No matter how much you personally dislike Java, that dislike does not translate into it being rejected by the industry. Some new technology is inevitably going to replace Java in significant areas of its use; but that certainly has not happened yet.