The Future of Java? 624
Todd AvErth writes "Judge Motz recently ordered Microsoft to distribute Sun's JVM with every Windows product. Salon decided to pipe up about it with an editorial musing about whether or not it's too late. Most of it isn't all that interesting, but some of the comments from Ximian developer, Miguel de Icaza point to the advantage of being able to compile from multiple languages. Anyone know of any projects to compile JVM bytecode from other languages?" Update: 01/23 16:00 GMT by M : Comments were disallowed when this story was originally posted; fixed now. My mistake (although KDE3's stupid mouseover-activates-form-elements user interface, now finally fixed in the latest versions, has to take some blame too).
Who wants multiple languages? (Score:3, Insightful)
I mean, imagine managing a project in 5 different languages. It creates major HR and logistical issues. COBOL.NET? Gimme a break.
Interesting future indeed.. (Score:5, Insightful)
Take away the business side, what are the advantages of using java versus C#? Looking at Mono it seems to marry both technologies -- correct me if I'm wrong, but they want to compile both.
Man, I am soooo tired of Miguel and his ego! (Score:2, Insightful)
Please tell us miguel how *easy* it is to port Windows Forms to wine (which is floundering) or how *easy* it is to port all of the web services/ado.net/crystalreports/asp.net/everythin
And when Microsoft comes down like a ton of bricks with all the patents on _NON_ECMA_ stuff you guys are doing then what will you do? How hard will it be to explain to all Ximian's customers that the next great version of Evolution will be delayed because Ximian put in a bunch of ADO.NET cruft and now has to rip it out because Microsoft wields the patent club against an Outlook competitor.
Now multiply this scenario by the size of Miguel's ego and you might begin to understand what a catastrophe this could be for FOSS. Miguel is a _weasel_ and he is star struck with Microsoft and hell bent on duplicating all the API's (for god knows what reason).
It is time for the Free Software company to recognize miguel for what he is
Two languages that use the JVM bytecode (Score:3, Insightful)
NetRexx "compiles" down to java bytecode, but it does it by compiling into java first. NetRexx allows you to use any Java class.
NetRexx was developed by the IBMer who developed the Rexx programming language. It has a fairly easy syntax, provides some very powerful/easy to use string parsing facilities.
You can pick up a copy of NetRexx (available for download from http://www2.hursley.ibm.com/netrexx/)
The other language is Jcon which does compile directly to the javabyte code. Jcon is a "Java" implementation of the Icon Programming Language.
To quote the website: Icon is a high-level, general-purpose programming language with a large repertoire of features for processing data structures and character strings. Icon is an imperative, procedural language with a syntax reminiscent of C and Pascal, but with semantics at a much higher level.
If you poke around deep enough in the history of Perl, you will find references back to Icon.
Details of Jcon (and download) can be found at the Icon home page at http://www.cs.arizona.edu/icon then follow the link to Java-based "Jcon".
Re:Language popularity ranking (Score:2, Insightful)
FWIW, I survey my CS students at the first of every semester re what languages they program in, and no one has *ever* raised their hand when I asked about C#. I would guess that I've polled 500-600 students by now.
C++ and Java are the big winners, though over half still report programming in C as well.
JVM plays rough (Score:4, Insightful)
As a person who've got a feel of writing JVM-targeted compilers, I'd like to notice that it makes extremely poor target for other languages. JVM was designed explicitly for Java, without any other language in mind. Thus, writing translators from other languages takes certain number of convoluted tricks.
If your source language has closures, true lexical scoping, multimethods or multiple inheritance, JVM is clearly a suboptimal vehicle, unless you want to bend over a lot. From performance standpoint, its stack-oriented machine isn't optimal either. JVM architecture also leaves no easy ways to implement proper tail-recursion.
CLR is likely a much better target, but even that one, designed for interoperability from scratch, has some rough edges for non-mainstream programming languages.
Re:Language popularity ranking (Score:2, Insightful)
I find it more fascinating that Perl is growing faster than PHP. I dig Perl, but I keep thinking I need to get on this PHP bandwagon. Apparently, it's not much of a bandwagon.
Perl has many uses (scripting, authoring web pages, saving children from fires) and PHP is almost entirely used for "web pages".. I would expect Perl to be in larger use; it has a broader scope
Re:Interesting future indeed.. (Score:5, Insightful)
I'm prepeared to bet a great deal (well, my career, in fact) that Mono will never reliably run .NET applications produced by Microsoft (or indeed by other people using Microsoft tools). If you write for the JVM, you will have a reliable ful-featured runtime both on Sun platforms and on platforms which compete with Sun platforms. We know this from Sun's historic behaviour: Java runs extremely well both on Linux and on IBM RS/6000 boxes. If you write for .NET, you will never have a reliable, full featured run time on any platform which Microsoft sees as a serious competitor. We know this, too, from Microsoft's historical behaviour. The leopard has not changed its spots.
Re:A duck (Score:3, Insightful)
I don't think you understand what IL is. It's not bytecode, at least not in the Java sense. You can certainly write an front-end compiler to generate IL from C++ or Haskell or Scheme or FORTRAN or whatever you want. In fact, VC++ 7 does precisely that if you use the managed C++ extensions to write .NET assemblies instead of normal PE binaries.
Further, IL is not C# specific - the notion that a language has to "behave like C#" to function within the .NET CLI/CLR is laughable at best and FUD-ish at worst. It is completely language agnostic. As a matter of fact, you can write entire .NET assemblies using nothing but IL - sorta like writing GUI applications in ASM. Not that you would *want* to do that, but at least you *can*. IL is fully documented.
There are a few good books by Wrox, O'Reilly and MS Press that deal exclusively with IL - I'd suggest you give at least one a cursory look before posting things like these.
Re:Languages for the Java VM... (Score:3, Insightful)
Yes they did... (Score:3, Insightful)
Re:Java is NOT in danger, sun is. (Score:3, Insightful)
If the entirety of Java were placed under the GPL, including all of the Java API libraries, it would KILL Java because it would mean that virtually every Java program distributed would have to be released under the GPL as well. Even if you think this is a good thing, most businesses wouldn't. They'd run screaming from Java.
This is exactly why the runtime .NET APIs under Mono aren't GPL.. Only the tools themselves are.
Re:Java is NOT in danger, sun is. (Score:3, Insightful)
Re:Java hype (Score:1, Insightful)
Manager building his empire? "Architect" looking for power? Sick of butting heads with you know-it-all coworkers? Pissed at that stupid Oracle DBA who won't let you do what you want?
No problem! Just adopt the Java "development pattern" and you'll have a team of 30 coders and 3 business analysts and 10 QA people in no time flat! Nobody has any idea what the fuck is going on, but the thing will eventually get finished.
Great. Except now, the whole process has been routinized to the point that you can just ship it off-shore for 1/10th the cost and the same craptastic results. No job for you!
But wait, Microsoft still believes in The Myth Of The Ueber-Programmer. Start boning up on that dotNet...
I look at their code and it appears to me like they don't know how to use a relational database, so they spend a bunch of code on reinventing indexing, joining, multi-user contentent management, persistence, searching, sorting, etc. using "patterns"
Well said.
Re:Java hype (Score:4, Insightful)
Are you kidding? How about an extensive, reliable, tested library of networking, user interface, and I/O code which can be used to create "complex applications" extremely easily.
I look at their code and it appears to me like they don't know how to use a relational database, so they spend a bunch of code on reinventing indexing, joining, multi-user contentent management, persistence, searching, sorting, etc
I can't comment on your colleague's coding standards and style, but it appears that they may have been coding cross platform JDBC code, using only simple DB features so that they could switch databases easily. I know it's not unusual to develop initially using something like Apache/Tomcat and MySql, then switch to 3rd party commercial app servers and databases. Anyway, a criticism of their code cannot be taken as a criticism of the language. The fact that you can replace these DB functions in Java code makes it even more flexible.
Re:Java hype (Score:3, Insightful)
What is there in Java that DOESN'T allow one to build complex applications? Based on the thousands of commerical web sites now using server-side java, I think it is fair to argue there is more evidence for than against.
I look at their code and it appears to me like they don't know how to use a relational database...[yadda]
Ok, now you are confusing bad developers with the language that they are using? If you are a sucky programmer I doesn't matter if you are programming in xBase or Java, you will still suck. But that doesn't mean the language itself is the problem.
Show me some objective evidence that Java is superior, not brochure cliches.
How about some objective evidence (i.e. not from microsoft) that it is not? Meanwhile, Oracle, IBM and thousands of developers are throwing their weight behind Java.
They yanked some dynamic typing features from VB, for example, because they were not "Javish" enough.
Did you just imply that VB is somehow a better language than Java? Where to start...well, I'll let somebody else weigh in on that gem. Man, now I really can see where your rep as a troll came from.
Troll, poster, troll!
Re:The Myth of the Demand for Multiple Languages (Score:3, Insightful)
What exactly is there in Java that allows one to build "complex applications"? I hear that from Java and OO fans all the time
They also have Perl and shell scripts for scripting, Tk for tool interfaces, Expect for testing and automated interactions... and on down the line. Hiring someone to primarily code in C++, or Java or whatever is acceptable if the product is in a particular language, but if the potential employee sits in front of me with only that language to his credit he's not getting the job. The ability to use the right tool for the job is the most important aspect of being able to code.
Re:Interesting future indeed.. (Score:4, Insightful)
Re:JVM plays rough (Score:1, Insightful)
Re:Right tool??? (Score:3, Insightful)
but I'm thinking we agree. I certainly don't throw away old tools, vanilla C is still one of the best tools for some of my applications. Awk and sed still come in handy even with Perl on the scene. Anyone calling themself a programmer immediately loses some respect points. We all know the face of the industry will change, and pretty rapidly at that. Flexibility is the key.
Multiple languages, good or bad? (Score:4, Insightful)
Re:Java hype (Score:5, Insightful)
There are several features of Java that I really miss when I have to code in C or C++:
Class.forName
To dynamically load a class, I just do Class.forName(classname). Combined with the Factory pattern, this makes it much easier to create pluggable implementations. You can still do that in C++, it's just harder.
exception.printStackTrace()
C++ has exceptions, but you can't get a stack trace on-the-fly from one. In a Java program, I can handle exceptions and log them to a database for later debugging. That makes it easier to find bugs.
Also, Java lets you know when you have the potential for unhandled exceptions (some people hate that, too, but I like it).
Built-in thread awareness
This one is probably closer to laziness, but I like being able to declare a method or block of code as synchronized, which is essentially the same as protecting it with a mutex. Using something like QMutex in C++ isn't really too much extra work.
Array bounds checking
This is another that C++ can do, but you have to do extra work for it. There are plenty of times when a Java program runs off the end of an array. Instead of giving me a core dump and killing the program (if I'm lucky), I get a nice little exception that I can handle. The same goes for referencing a null pointer (reference).
Garbage Collection
Okay, it's a blessing and a curse. On one hand, I don't have to worry about keeping track of references. On the other hand, you still get memory leaks, and your Java programs consume a lot more memory. Still, I really miss it when I start having to write destructors and copy constructors. In a large system, it is more difficult to keep track of who is supposed to free what memory. You end up using reference-counted pointers, which solve a lot of problems, but not all of them.
Reflection
I don't use reflection very often when writing business logic, but it comes in handy for writing frameworks. It is great to be able to dynamically access methods and fields at runtime (you locate the method/field by name, so it doesn't have to be known at compile time). Many of the networking and database frameworks use reflection to keep you from having to write tons of custom methods just to support the framework.
The libraries
Java has a great set of libraries that come with the standard JRE/JDK. While you can find the equivalent libraries for other languages, with Java you don't have to go searching as much. Plus, you know they're going to work when you move the application from platform to platform.
Java isn't perfect, the runtime is huge, the programs take a good bit of memory, swing still seems clunky to me, but when I have to do a large server application, I'd much rather be coding it in Java than C++.
Re:Java hype (Score:5, Insightful)
There's not going to be objective evidence of a subjective comment. "Superior" is ultimately a matter of opinion. I personally think python is the "superior" language of all those I have tried, but that's my opinion.
What I can say conclusively is that a programmer of equal skill in C++ and Java can write the same program in less lines of Java code. Java does lots of stuff "for free" that gets the job done faster, like memory allocation and garbage collection, and handling pointers transparently. If your goal is a good application written quickly, Java may very well be "superior" for your needs.
Another advantage of Java over other languages (except Perl and Python) is the huge and wonderful library of methods and classes. You can accomplish these goals with C or C++, but generally you have to go out and find the libraries to do what you want, then compile them for your particular platform. Java generally includes them, and for those that are not included, they're distributed pre-compiled for the JVM.
So it's not fair to say Java is "Superior", because that really depends on what you're looking for. If you're looking to build enterprise web applications, Java is likely superior. If you're looking to crunch numbers as fast as possible, you're likely to be happier with C or C++. It depends on the project and the goals.
Re:The Future of Java? Even Brighter!! (Score:2, Insightful)
Anyone with decent Java skills can find a job, no problem.
I sympathize with your point--there are more Java jobs out there than anything else, probably--but as a smarter-than-average mid-level Java programmer with a CS degree and an impressive academic record who remained unemployed (not even a single interview) for one year before returning to school, I object to the words "no problem." Some regions are worse than others (I live in NYC, which is among the worst), but fifty job listings with a thousand applicants each is, in my opinion, a problem, no matter how well it compares to C, Perl or Lisp.
Runtimes and Multiple Languages (Score:2, Insightful)
Microsoft jumped on a rather interesting point in their new CLR environment- if the API is universal at the bytecode level, then you can build up many languages utilizing the API and compile them down into one common bytecode. This does offer many forms of interoperability between the languages, but the question of whether or not you really want to do that comes into play. This may just be my own myopic opinion, but it seems to me that that the multi-language promise of .NET has the same promise as that of the Tower of Babel...you're going to be able to get started just fine and build things beautifully for a while, until your effort is crushed by a confusing mess of different languages.
This might have not been a really big deal if it were just VB, C#, and ASP, since they all share so many similarities, but add in "managed C++" and COBOL, and give all of these languages roughly equal footing to what they're capable of, and your development team is going to be in a position of coding anything they like in whatever language they want, and that's going to become a confusing mess to maintain.
Now, before I say anything further- YES, I am a Java programmer. I also program in C, C++, and Perl, though...I just don't get paid to do those. I like Java, but I don't think it's the messiah of languages. I will say, however, that I like it because I find it easy to code in and that, in my personal experience, fewer people have wrecked my day with bad Java programming than with C or C++ programming, and that makes it a pleasant "headache free" language for me. Since it's so "headache free", and because I can do so much with it, I often default to using Java unless there's a reason to do otherwise.
Now, since I've given what is probably my ignorant and unsolicited opinion on .NET and on multi-language runtimes, let me throw out another ignorant and unsolicited opinion. To put it shortly, I think that bytecode interpreting runtimes are really going to take over in the future of programming.
If there's one thing I've forever loved in Java that I wished I had in native code languages, it was the ability to, without care of the implementation details of some remote system, load and bootstrap executable code from that system. C and C++ have dynamic resource loading capabilities, but I just don't find them as flexible as dynamic class loading in Java. I've looked at LAM and MPI and I've programmed in CORBA...all of these different technologies seem to have one thing in common to me- they struggle to put a common veneer over different machines so that they can be used together. I like MPI quite a bit, actually, but when I look at the ease with which I can create distributed services in JINI, the distributed options for native code languages just don't seem that great. The bytecode interpreting runtime (the JVM or the .NET CLR) is its own veneer over a machine's actual native operations, and so chunks of programs can be more easily exchanged, bootstrapped, and executed on disparite machines. From the heterogenity comes the power of very flexible dynamic loading of runnable code, and such a feature seems to me to be extremely important in creating distributed systems.
Again, I'm not saying Java or .NET is going to take all or be all. Honestly, I'd like to see these two bow out in a few more years and make room for a runtime that picks up where they leave off, because they both leave things to be desired. Also, rock solid native code languages are still incredibly important...not only are they necessary when you need more raw machine access, but how else will everything that bytecode languages depend on be implemented? And, of course, scripting languages that allow for fast and effective programming will be perennial.
But I think that the future of quite a bit of programming, especially a lot of business applications programming (which, at least in my experience, relies increasingly on distributed systems), is going to start going to virtual machines interpreting bytecodes.
I'm sure I'll get flamed for this, so please have at it. ;)
Re:Language popularity ranking (Score:2, Insightful)
For Fast Cross Platform Development, Java Wins (Score:4, Insightful)
I am currently developing a custom database and data collection package that MUST run both on Linux and Windows 2000. As well as the intrinsic functionality, it has a significant GUI component as well. Equally important, I don't have a lot of time to get it done. I considered many options, including C/C++ with QT, vxWindows, GTK and other "cross platform" toolkits, perl, and others. In the end, Java won the day for several reasons:
1. Java plus Swing is the closest to truly cross platform of all of the options. I have written around 6000 lines of code so far and less than a dozen have to be changed to account for differences between Windows and Linux, even though the program does some relatively low-level things like directly accessing modems through serial ports. In addition, the Swing GUI looks EXACTLY the same on all platforms. GUI toolkits which try to give you "native" L&Fs often need tweaking between platforms to look good. Once you get a Swing GUI looking good on one platform, you're done.
2. Java has an extremely complete and easy to use interface to SQL DBMSs (JDBC) which works the same on all platforms.
3. Sun's online documentation is very complete and easy to use (this can be a big plus with speed is important).
3. The higher level nature of Java compared to C/C++ (e.g., automatic memory management, better runtime checking) make for extremely quick debugging. I am achieving operational code with many fewer iterations than I ever did with C/C++. Java may be slightly slower than C++ because of these features, but this particular program is not pushing the performance envelope, so the faster development time is much more valuable.
This is the first sizable project I have programmed in Java, and overall I'm very happy with the results so far. A year ago, that's something I'd never have guessed I'd be saying.
Re:Java hype (Score:3, Insightful)
An enterprise application is one with multiple components, geographically distributed, using multiple protocols and techniques to integrate the activities of a number of different people and/or departments.
A good example would be an application in which clients can submit orders/requests via a web page, adding an order/request record to a database. This stage uses a web server, middleware, and a database server. The next stage is one in which an employee of one department interacts with the record using an intranet or client-server application. This stage could be repeated in several departments, like order intake, shipping, customer service, etc. Another stage is one in which whatever the client requested is actually delivered. This could be handled as part of the previous stage, or maybe be its own stage by involving an outside party like Fedex and personal handling of the order/request by a live person (a sales call, etc).
So, in my view, the basic idea is that it's a company-wide system which involves a bunch of departments, potentially more than one database, clients, employees, and interested third parties.
What do you think, guys? Is this a workable definition?
Re:Java hype (Score:5, Insightful)
Greetings Tablizer,
I've read many of your posts here on Slashdot as well as your web site. I've found your arguments to be well-written. However, many of your arguments are as subjective as some of the posters here. You say in your own writings, in fact, that you have difficulty thinking about things as objects with behavior. And that, in my _opinion_, is what it's really about.
Programming languages should be built for people, as they represent a communication channel between people and computers. Software texts often must account for communication to other humans, hence the need for comments.
Experienced language designers take this into account. Their experience also leads them to add things to the language to prevent or at least deter common mistakes. Those "good features" in Visual Basic you mention, have produced a history of unreadable and buggy code.
Where would you suggest today's application programmers spend their time? Is it more valuable, more marketable to learn a single OS / OE, a single database (and be a one-trick pony), or should they spend their time on learning a single, rich API that applies to multiple platforms?
I'll make no pretenses that Java is more machine-efficient than C, or that O/R mapping is faster than embedded SQL. I will say that I find domain logic easier to unit test in isolation when you use an O-O domain model with mapping. These test can be automated and even serve as a kind of usage guide to the software.
The point of this is, the Java language has an accepted and refined way to work at a reasonable level of abstraction. If machine-efficiency were always 'better' then we'd all use CPU specific assembly languages.
BTW: The popularity metric does have merit as an argument. Popularity leads to communities. Communities can work together to advance the state of the practice, to share techniques. You complained about this very fact in your essays. 'Not enough people are contributing to the advancement of Procedural/Relational practice,' you said. I believe you are correct, and the reason for this is industry support and community.
Regards,
Michael Murphree
The opinions expressed in this post are my own, and not necessarily those of my employer.
Re:Languages for the Java VM... (Score:5, Insightful)
And that page has been up for at least 4 years, and comes up top on the Google search [google.com] "Languages for the Java VM." So I think the real question is: why does the meme that Java bytecode can only be generated from javacc continue? Even if you regard most of the things on that page as academic, they're at very least proof-of-concept (and ad naseum at that, due to sheer numbers). Not to mention what the presence of clearly non- academic implementations like Jython.
I don't know whether or not Sun intended to design Java so that this was possible or easy. But it seems pretty obvious to me: you can target a VM as easily as you can target a processor, and that's what any compiler does. Why doesn't the Java-only for Java-VM meme die?
Re:Java hype (Score:3, Insightful)
That means that session data has to be either shared or stored (which means the application servers have to be clustered), or you have to set the sticky bit on two cross-linked load balancers (which is not an option in many cases since Foundry Server Irons cost $30,000 apiece and you need two so the irons can fail over too).
You can't do that with Perl or PHP as far as I know. Enterprise has nothing to do with size or features, it is all about consistent performance, uptime, and failover.
Re:Java has it's place, but it has problems (Score:5, Insightful)
FUD, FUD and more FUD.
Starting with the jdk1.3.1_x series Java has been pretty peppy. JDK 1.4.1_x is downright speedy. Do a google search. On the server, Java is very fast and even some Swing apps can beat native code. Java in 1998 was slow. Java today is not. Get over it and stop living in the past.
Java also failed to deliver it's platform independence - you just get so many problems running on different platforms and different VMs. Compare this to say Perl - if you avoid platform specifics, Perl just works. Even compare to C when using a library to abstract platform independence (e.g. things like in Gnome/Gtk or Qt), it's not so hard and at least the mistakes are usually yours. I know it's not the fault of Java as a language, but if it can't be implemented well, it won't be much good.
Well I don't know what your experience is but I have never run into any issues with Java being cross-platform. I have literaly just finished doing some bug fixes to a J2EE app for one of our clients. I develop on Win2K, test deploy on Solaris (Sparc) and will deploy it tommorow on HP-UX. All I do is redeploy the
The final major reason Java has not delivered is because it's not made programming any easier or error prone - and much has been made of this promise. Yes, gc does save some bugs (it does cause some more, but on the whole it's good). Java does not save you from uneducated developers or people who simply suck as a programmer. I've seen some steaming piles of turds writted in Java by people who really should be better. This can be said of any language, but much was made about Java being a language to make people make less mistakes - they just make different ones.
I guess this is a matter of degrees isn't it. No Java isn't perfect. But it's a darn site easier to learn and maintain than other, more obfuscated languages like Perl. Java is a language that let's you make less fatal mistakes. No buffer overflows, no pointers, strict type checking and casting rules as well as the Java sandbox go a long way in protecting a system running Java. Can the same be said about C? So even if I'm a bad java programmer, I can't be bad enough to cause the OS to crash or to introduce a system level vunerablility. C give you the freedom to do anything...kinda like giving you enough rope to hang yourself (and two of your friends sometimes).
Despite all that, use the Right Tool for the Job. If that is Java, use it. If it's C (and you can use it right) use it.
But please don't go spreading half-truths and crap to get moderated up.
Transmeta? [Re:Languages for the Java VM...] (Score:3, Insightful)
Re:Languages for the Java VM... (Score:3, Insightful)
Thus their strategy:
Sell Java's WORA capabilities
Get everyone hooked on Java
Release proprietary hardware accelerator for completive performance
Profit!
has failed.
Re:Miguel missing the point? (Score:2, Insightful)
Yes, you are.
MS made the "important stuff" standardized and "open." It still leaves MS in the position to close off the rest of the "non-important" stuff and that could break compatability.
Yes, but so what ? Mono is not a "Microsoft emulation" or "Microsoft compatibility" suite. It's a development tool primarily for Linux, that takes advantage of a good technology.
If you're looking for "cross-platform" advantages, .NET and it's VM are dependent upon MS's decision to release a VM.
This is the premise most of your post is based on, and it's rong. The goal of Mono is not binary compatibility with the MS VM. The aim is to take advantage of a decent standard technology. Think of it more as something that is comparable to C or C++ , which are also standard technologies where implementations are proprietary, as opposed to java.
Then you're screwed, writing applications that run on a perceived "broken" VM
That's like saying that gcc is "broken" because Linux doesn't have MFC, Direct3D and (shudder) Win32.
What if Evolution had been written in Java?
It would suck.
OpenOffice, if I'm not mistaken, is written in Java and
You're mistaken. It's written in C++ for the most part. You should be attributing the portability to the portability of standard languages like C, C++, and C#, not the portability of java. Of course multi-platform development in C and C++ is nontrivial, but it's certainly not impossible either. The important thing is that there's a substantial standard core language, which makes it possible to abstract away most of the platform specific code.
Re:Java hype (Score:3, Insightful)
1. Academics, who see Perl as the new BASIC. Perl wasn't designed with a lot of the "principals of language design" or whatever they're called these days. It's not orthogonal, it's a relatively modern language that isn't OO. It's not functional. Perl was designed to make simple solutions to common problems. Academics don't deal with common problems, so Perl is largely worthless in their eyes. People in the real world love it because they deal with common problems all day long and hate writing hundreds of lines of C/Java for every new problem. One particuarly telling example (in the Camel book IIRC) was dealing with regular expressions. In a "proper" language, you would not need the "+" (match one or more of the previous item) because you already have the "*" (match 0 or more of the previous item). Hence, a+ can be written as aa* and should be eliminated. In the real world, nobody wants to retype a 14 character token.
2. People who have never programmed in Perl hate it because it uses a lot of punctuation characters.
Re:The Future of Java? Even Brighter!! (Score:2, Insightful)
Re:Languages for the Java VM... (Score:1, Insightful)
Re:Java is a Jobs Program (Score:3, Insightful)
As a Java developer, I would be offended by this if it weren't so accurate.
Re:Languages for the Java VM... (Score:5, Insightful)
Roger Sessions ... now there's an unbiased observer. Once upon a time, Roger was a CORBA spec writer, until he basically got booed out of the CORBA camp for non-performance (this spec is going to be SO good when it's finished ... really!) Then he became a COM/DCOM/COM+ apologist for Microsoft. Read through his ObjectWatch newsletters and see if you can spot any unbiased commentary on technologies; you will quickly observe a trend: Microsoft good, non-Microsoft bad. I won't say that Roger is a complete bought-and-paid-for Microsoft shill, but he gets his books published by Microsoft Press... you draw your own conclusions.
As for the JVM's language-neutrality (or lack thereof): so what, big deal.
There is no such thing as a language-neutral platform, be it hardware or virtual. Every computer instruction set that has been developed to date has had biases built in; it's inevitable. The system designer has certain goals, and usually has a target set of capabilities, which may only work in assembly language. Take the X86 instruction set: only a fraction of the X86 instructions are useful to a C compiler. The rest of the instructions can only be used by writing assembly language. The only hardware instruction sets that I can think of that are completely accessible by a higher level language are those that were specifically designed to implement a single language (Forth, LISP), and they make lousy targets for other languages.
The question is: does it matter? There are very good reasons why the JVM doesn't allow pointer arithmetic and pointer casting: the designers wanted a provably secure runtime environment, so they excluded unsafe operations. So you can't implement C/C++ for the JVM; big deal. If you really need those capabilities, you're better off operating outside of the JVM and interacting via JNI or some form of RPC. That said, there are still plenty of languages that are written in Java, compile to Java, or compile directly to Java bytecodes; certainly more than currently target the .NET CLI or any other virtual machine. Use one of those, or write your own.
Re:The Future of Java? Even Brighter!! (Score:3, Insightful)
Re:Java hype (Score:2, Insightful)
JavaBeans are Java-specific. Why not LISPbeans?
Do they support database transactions (ACID)?
No, but databases do.
Since they're scripting languages and not fully OO
Does that mean that Smalltalk is not OO?
how would an application server do object pooling with them?
You have not established a need for object pooling. Object pooling might be how java does X, but that does not necessarily mean it is the only way to do X.
One common thing is to put either an EJB or an MTS object between a web server and a database (or some other resource), and use a firewall to limit access based on this. How would you do that using a scripting language?
Use something else to communicate thru a fireall. Use XML thru HTTP, for example.