Slashdot Log In
The Future of Java?
Posted by
michael
on Thu Jan 23, 2003 10:16 AM
from the probably-our-last-link-to-salon.com dept.
from the probably-our-last-link-to-salon.com dept.
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).
This discussion has been archived.
No new comments can be posted.
The Future of Java?
|
Log In/Create an Account
| Top
| 624 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Languages for the Java VM... (Score:5, Informative)
It doesn't mention SmartEiffel, though, which does generate byte codes. There are probably many others as well.
Re:Yes they did... (Score:5, Informative)
Sun's annoucement almost 6 years ago that they and Rockwell Collins would be making picoJava chips [sun.com]
JVM actually has more languages than .NET (CLR) (Score:4, Informative)
Not what the marketing folks at Microsoft would have you believe, huh?
Re:Languages for the Java VM... (Score:5, Interesting)
Also, it is very common on handhelds and cell phones. My Handspring has Sun's JDK and IBM's JDK on it, as well as Java3D.
Personally, I am still debating making my own PDA using an open-core java chip and OLED touchscreen.
Malachi
Re:Languages for the Java VM... (Score:5, Informative)
www.ajile.com (and www.systronix.com has a few boards built witht the processors).
www.ptsc.com
Also, the Jazelle technology from ARM embeds a java processor section into an ARM chip:
http://www.arm.com/armtech/jazelle?OpenDocument
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:Languages for the Java VM... (Score:5, Informative)
Rogers Sessions took the time to investigate every single one of the projects on the JVM languages page. He posted his results to the ObjectWatch [objectwatch.com] site. After long research, he found only 8 that were actual implementations of a non-Java programming language for the JVM. Of those 8, in his opinion not one was available or suitable for professional development.
In his conclusion he states "I believe that Simon Phipps and other Sun luminaries have greatly exaggerated the degree of language neutrality supported by the Java platform".
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.
Ada (Score:3, Funny)
So does that mean that my forced ada classes [gwu.edu] in college were useful?
Jython (Score:5, Informative)
Allows to write programs in python and compile into java bytecode. Access to awt for sure. I think there is also a port where you can write Tkinter applications in jython as well.
Microsoft Appeal (Score:3, Informative)
The Future of Java? Even Brighter!! (Score:4, Interesting)
On the server side it has always been a great solution (great for building complex applications, no performance degradation with 'backend' code, and very stable and safe).
On the client side, the MS/Sun ruling will be a huge boon to the applications side - of course developers will start building client side apps! "If the JVM is there, they will come"
Re:The Future of Java? Even Brighter!! (Score:5, Informative)
Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....
But it does matter, if other programming languages still run relatively faster than Java. I agree that it's not as clunky as it was a few years ago though... *shudder*
Two things I feel you've left out are:
1 - The embedded systems market. When I was at Uni this was being touted as the next best thing. I don't have any real statistics for you, but I'm sure Java is doing well in this field.
2 - The mobile phone market. Pretty similar to my first point, the KVM (Kilobyte VM - a cut-down version of JVM) and related APIs in J2ME are a big player in the mobile phone business. The company I work for is developing mobile phone games, and Java has got the support of the handset manufacturers, which will give it superiority over other technologies that havn't had as good an uptake.
Re:The Future of Java? Even Brighter!! (Score:5, Funny)
And, there should be no lack of new software because, as the article says, "Sun estimates there are about 3 million Java developers."
Re:The Future of Java? Even Brighter!! (Score:5, Interesting)
Perhaps you haven't looked at the market.
Go to some job site (dice, monster, etc...). Look for C jobs, then C++ jobs, then perl jobs, then Java jobs.
Java has been a constant hire (even during the worst parts of the IT recession). Anyone with decent Java skills can find a job, no problem.
Re:The Future of Java? Even Brighter!! (Score:5, Interesting)
I've heard time and time again from developers that applets are toys, the true reason to use Java is on the [large] server side.
Have you ever used the Zend Development Environment for PHP? It's java and doesn't feel as professional as say Dreamweaver, MS Word or standard client side applications.
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: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: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:4, Informative)
Well, I am not a java programmer, so I don't know about java, but It seems to me that you are using C arrays in C++. The STL provides several data structures that are indended to replace C arrays. These include vector, and list, both of which dynamically allocate their size and automatically resize if you overflow thier bounds:
int main(){
vector<MyClass> vec_myclass;
MyClass temp;
ifstream fin;
while(!fin)
{
fin >> temp;
vec_myclass.pushback(temp);
}
cout << vec_myclass.size();
return 0;
}
The user doesn't even need to check the size, although that is provided.
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.
enterprise applications (Score:4, Informative)
Enterprise application is a software system that is:
1. Distributed (with all the requisite problems of distributed computing)
2. Secure (authentication, authorization, auditing, and encryption)
3. Scalable (can handle increasing load without a re-write)
4. Heterogeneous
5. Fault tolerant and/or Recoverable
6. As a corollary to (5), usually involves one or more transactional DBMS
Each of these topics by themselves can take years to master.... which is why people tend to hold well-designed "enterprise applications" in high regard.
Google Search (Score:5, Informative)
Here's [tu-berlin.de] a nice list of languages that work within the Java VM. I'd like to point out that its a very long list.
Also, Java on the desktop has always had issues. Everytime someone brings up the "future" of java, they tend to forget that Java's current strength is on the server side where the average user doesn't see it and doesn't know about it. Java's competition is
GCC? (Score:3, Interesting)
Re:GCC? (Score:5, Interesting)
Language popularity ranking (Score:5, Informative)
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.
Re:Language popularity ranking (Score:5, Interesting)
Java? Future? (Score:5, Interesting)
I work as a J2EE consultant (and consulting has taken the brunt of the recession in the IT industry) and my job has not been in danger at all. J2EE is still one of the choice languages for large, complex, dynamic websites.
Most people that think its in question either do a "I haven't seen an applet/swing app in a while, so Java must be dying", or a "I heard about java in the past, but not recently so it must be dying". This is almost as sad as the "*BSD is dying troll"
I also have one side note about my sig. For those that haven't tried to comment in when the story was posted, it was posted as a new 'friends only' post for a good 20 minutes (and note, michael has no friends marked, so no one could post). This just adds to my frustration that slashdot is immature when it comes to its software lifecycle. Where's the testing build (or testing at all, for that matter)? Where's the notification when changes are coming? Shouldn't the audience know when new features are added (so at least we can test them, or can be on the watchout for bugs)?
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.
Re:Who wants multiple languages? (Score:5, Informative)
There was a game written in perl and C - perl for most of the game for garbage collection, bounds checking, etc. and C for the low level graphics to make it fast.
Many more programs mix a really low level, low level and high level language. Games mix asm, C/C++, and lisp/prolog/made-up language. Intranets often have a mix of a javascript, java, C and some high level pure functional language (that would be like SML or Haskell) (Like lotus domino has - forget what it's called.)
Being able to mix languages is a wonderful thing.
Tons (Score:3, Informative)
This page [tu-berlin.de] links to a whole whack of projects.
To give a smattering: Forth, Ruby, Cobol, Eiffel, Prolog, Basic, Lisp, Tcl.
LOTS of languages compile to Java bytecode (Score:3, Informative)
This page [tu-berlin.de] lists over 150...
Apple Cocoa (Score:5, Informative)
Both languages share so much of the same concepts that both languages can call in each other, allowing a project to be composed of both Obj-C and java.
Given Apple's recent extensions to Obj-C, the so-called Objective-C++, you can actually mix C, C++ and Obj-C source code in the same file and interchangeably make cals to and from C++ classes and obj-C classes. Then, calling Java is nearly as trivial.
These changes are finding their way back into the GCC compiler, which is the standard compiler for the Project builder environment.
Java is NOT in danger, sun is. (Score:3, Interesting)
Heh.. ok now that my rant is over...
What if Sun goes under? This could be a good thing. What if the java platform became GPL ? I think this is an important distinction to make.
Perhaps the only thing holding back the Java platform is sun holding onto it.
I have nothing to say about
--noodles
Re:Java is NOT in danger, sun is. (Score:5, Informative)
Huh? I think you'll find that GCC is most certainly licensed exclusively under the GPL. [gnu.org]
I think you need some education on what the GPL requires. The GNU FAQ explicitly covers the question of whether programs compiled with GCC are GPL'd [gnu.org] (they are not).
Jython (Score:5, Informative)
Jython [jython.org]
# Dynamic compilation to Java bytecodes - leads to highest possible performance without sacrificing interactivity.
# Ability to extend existing Java classes in Jython - allows effective use of abstract classes.
# Optional static compilation - allows creation of applets, servlets, beans,
# Bean Properties - make use of Java packages much easier.
# Python Language - combines remarkable power with very clear syntax. It also supports a full object-oriented programming model which makes it a natural fit for Java's OO design.
I Think... (Score:4, Funny)
I Think Garbage Collections are too much on my mind
I Think dumps have got a lot to do with why the world sucks
But what can you do?
Like a red rain, beating down on me
Like a Linus line, which won't let go of my brain
Like C#'s ass, it is in my head
Blame it on java
Blame it on java
Blame it on java
I Think slows are gonna drive us all crazy
And write once, run anywheres make me feel like a child
I Think crapyness will eventually be the downfall of civilization
But what can you do? I said what can you do?
Like a red rain, beating down on me
Like a Linus line, which won't let go of my brain
Like C#'s ass, it is in my head
Blame it on java
Blame it on java
Blame it on java
Like a red rain, beating down on me
Like C#'s smile, cruel and cold
Like Linus's ass, it is in my head
Blame it on java
Blame it on java
Blame it on java
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.
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:Interesting future indeed.. (Score:4, Insightful)
Java Stays Alive Despite MS (Score:5, Interesting)
I've found that Java is great for complex applications that need cross-platform ability when programmers can't spend too much time in making that compatibility happen. Mac OS X is among the strongest Java clients around, and it shows every time I download a raw JAR and just use it. YMMV, but Java has a lot of warmth left in its cup, and, if other platforms aside from MS continue to support, we'll all get free refills.
(Sorry for the many metaphors. Haven't had my cup of coffee this morning--ack, I did it again...)
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.
perspective from a CS student (Score:3, Interesting)
I'm personally ambivalent to Java. I like it for some things, but the only real reason I want to learn it is because so many use it. I just recently discovered wxPython and think it's probably easier for me than Swing or AWT.
The best thing that could come from Java for development as a whole IMO is Javadoc. If that tool were extended to support C++, C#, VB.NET, Python, PERL, etc it would make everyone's lives easier. Seriously, has anyone seen better documentation than Sun's Javadocs from something so big and complex as Java's libraries?
I'm really excited about Mono because I really like VB.NET and C#. I think the ability to use any language you want with the same libraries is a very important strength that
Universities (Score:5, Interesting)
Another issue is that as linux becomes more widely used, code that can easily be run on multiple os's becomes far more valuable. And developers may turn to Java for this reason, especially with all the cheap, fast, hardware we're all running nowadays where speed and efficiency arn't as important as they used to be in many situations.
perljvm (Score:3, Interesting)
And, coincidentally, I went to college with him, so I have to give him a plug
T
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".
Not really feasable (Score:3, Informative)
Microsoft's CLR (common language runtime; part of
Personally, I am not convinced that such a common runtime is always an advantage. The CLR basically defines its own machine language, with all the basic instructions you'd see in any other assembly language. I don't like that approach because it is too low-level, and makes optimization harder. Allow me to explain...
It is a rather common misconception that bytecode-compiled languages must necessarily be slower than native compiled languages. The opposite is actually true in many cases. If you are running your bytecode on some sort of interpreter, then yes, it will be slower, but typically bytecode is re-compiled to native code at runtime. When this happens, the compiler can perform all sorts of optimizations specific to the host machine, OS, and the exact library set in use, which would be impossible if the software were distributed as native code. Thus, the code actually ends up faster... in Java's case, it can approach the speed of C, which is surprising considering all the abstraction in the Java language -- based on the languages alone, you would expect Java to be much slower.
Anyway, getting back to the point, higher level bytecode descriptions allow more optimization on the host machine. I am actually desiging a programming language right now, and my bytecode is only a little more than a parse tree. I like it that way.
Just think of the language runtime like a library. Different programs use different libraries. What's wrong with that?
AspectJ (Score:3, Informative)
Of course, it's not a true departure from Java... it even recommends that program filenames end in .java . It can compile java code, but not the other way around.
The client doesn't control the Future of Java (Score:5, Interesting)
Does it make a difference for Java on the client? Maybe. Although most of my Java work has been on the server side of things, I have written a couple of Java client apps as well. But those were for use inside the intranet, so it wasn't a big deal to require users to install a JVM. It certainly won't solve all of Java's client-side problems. Performance is much less of a problem than it was in the early JVMs, but most Java clients are still slower than their native counterparts. Perhaps more importantly, there are quite a few bugs in the GUI libraries (both Swing and AWT) that make it difficult to write highly polished applications. And with Swing you get problems with the look-and-feel not matching the native platform, which is a problem for some. But I think that part of the reason why these are still problems is because Java on the client hasn't really taken off -- maybe more of these issues will get solved if people start looking at Java as a valid client platform (because MS is shipping it with Windows) and start writing more client apps.
But regardless of whether it makes a difference, I think the ruling does make sense. MS had a contract to provide a compatible JVM, and they didn't hold up their end of the contract. (At least that's my understanding -- I don't know the complete details of the contract.) Therefore they should have to make ammends -- maybe it is too late to "save Java" on the client, but it shouldn't hurt.
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.
Cross-language compatability (Score:3, Interesting)
Can anyone tell me if one Java-compiling language can use objects written in another one?
To me, this was a major advantage of
Lets get it out of the way... (Score:3, Funny)
Responses that are sure to follow:
Java is the new COBOL (Score:5, Interesting)
The whole C# and .Net thing is a potential competitor in the same arena, but I don't think that Microsoft's inclusion (or not) of Java is going to matter much. I always figured that Java was intended to allow cross-platform desktop app programming, but the niche it seems to be filling is a back-end role. Personally, I had expected Perl to fill this role as the new COBOL, but demand for Perl seems to be way down, except as one of those "we also expect you to know Perl" type things, which never actually turns out to be important in the job.
Java has it's place, but it has problems (Score:4, Interesting)
Java has it's place, but if you come across someone with the opinion that Java is the be all and end all, avoid them.
The very best thing about Java is the marketing hype Sun have managed to create. It's only Mac-o-philes who seem to be more obcessed (a Mac-Java geek is something to behold!).
Java's a decent clean OO language, it's got a good set of standard/accessible powerful libraries, it's handling of libraries is good (compared to say C/C++), it's simple to learn the language basics and the GUI toolkit (swing) is reasonable.
However for me Java has not delivered on it's promises. Performance generally is poor, compared to say Perl, and is dire when compared to C.
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.
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.
So use Java with your eyes wide open, it's decent, good in some areas, weak in others and eventually you'll move on to the Next Big Thing TM.
Jamie
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.
Multiple languages, good or bad? (Score:4, Insightful)
Miguel missing the point? (Score:5, Interesting)
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. If you're looking for "cross-platform" advantages,
And that leads us to:
The key is to ultimately remove the dependence upon MS products. We've all stated that time and time again. People run MS for Outlook. For Exchange. For a relatively easy sytem to administrate and patch. For Support. There's a million and one papers, editorials,
What if Evolution had been written in Java? OpenOffice, if I'm not mistaken, is written in Java and if I must say so myself, it runs VERY nicely on my machine and does everything I need it to do as an Office Productivity Suite. With OpenOffice, you see lots of people switching from MS Office, avoiding the licensing fees and troubles, and generally LIKING it (there are exceptions.. there needs to be a nice Access competitor or at least a great frontend for something like PostGRE or the like). That's one less reason to use MS, right? Great! OpenOffice runs on Windows, Sun, Linux, OS X (with X11 installed). Most importantly, see Windows? Millions of people can now look forward to using that $500 they'd spend on Office to doing SOMETHING ELSE with their money. Millions of companies can still do business without outlaying a chunk of cash for Office. There's the example.
Now, back to Evolution. If Evolution had been written in Java, like OpenOffice, you wouldn't just have people on *NIX platforms using it. No, you'd be able to use it on Windows, the biggest, most important, and most influential marketplace in the computer industry. What would that mean? Let's say you're Joe IT Manager. You've already switched your desktops to OpenOffice. Now, you could replace Outlook with Evolution, on your Windows systems at work (and saving on the licensing, to boot!). See, it's hard to convince upper management to switch to Linux whole-hogged. But if you do it, one app at a time, eventually you run OUT Of reasons to continue to pay the exorbitant licensing fees to support an Operating System that you no longer need to run the apps you run. Dig it? Dig it! Your users use the new apps, already acclimated to them. Change comes slowly, and for the better. And all that time Ximian spent on working on MONO could have been spent tweaking the interface, developing advanced calendaring functions, developing server-side calendaring/schedule making software, etc. And then Linux slips in quietly through the back door and MS is left to send armies of marketdroids to help woo the companies back, losing their marketshare inch by inch.
I may have Ximian's and Miguel's intentions completely wrong. Linux "desktop" penetration may not be his ultimate goal, although as a Linux vendor it might behoove him to think this way. Linux is inching it's way into the server rooms of corporate America (and the world), and the desktops will be a hard fought battle. Java is the kind of technology that allows you to provide the replacements that will make the transition EASIER.
To conclude, I applaud Miguel for his hard work on MONO (and Evolution, it does fucking kick-ass). Unfortunately, I think it's misguided and ultimately futile.
VB source compiled to java byte code (Score:3, Informative)
Halcyon changed it evidently to a middleware which converts ASP to Java. I don't know why they dropped the VB compatible source compiler. I think it would have been a terrific product had they released it since all the VB coders would have been able to code on multiple platforms with no learning curve. It would have been a huge market for them too, so I would love to hear the real story behind their dropping it.
They have since merged with a company called Stryon [stryon.com] if anyone wants to check it out.
Programming for the Java Virtual Machine (Score:5, Informative)
So speaking as a nominal expert, while you certainly can translate non-Java languages into bytecodes, the machine clearly isn't designed to be general-use. It has a lot of object-oriented instructions that fit the Java object model and not a lot else. You can adapt them to your language, or you can ignore them and code everything up as one big method call (except that you'll run out of space, since function size is limited, and you can't modify it once written).
I've successfully adapted languages like Prolog and Lisp, and taken advantage of Java objects to provide the continuation-like features of these languages. I've even found a couple of places where you can generate code which could not come from Java code but which is legal and verifiable (e.g. crossed loops).
I use it mostly for small projects. For example, Ontology Works [ontologyworks.com] generates Java APIs for its custom database description languages. It generates the bytecodes directly, since the APIs are too large to be conveniently compiled from Java. But that's not a general-purpose language, so the code is actually fairly simple.
I've only glanced at CLI, but it appears to be somewhat more general purpose than JVM bytecodes. (In the end it's all Turing tar pit.) However, CLI a bit more heavily oriented towards calling out to native code, which makes the code less portable and harder to optimize. The JVM also supports native methods, but they receive a lot less encouragement.
Mostly, I'm a huge fan of the way JVM does verification. It's brilliant that you can restrict code to safe code and still be Turing complete by eliminating a large class of safe-but-invalid instruction sequences. You can make huge optimizations to verified code that you can't make to generalized code. Verification also allows much more fine-grained authorization than the Microsoft way, which is all based on signed code.
You always want to choose the best language for the job. C/C++/Java are largely identical, and I think in general a group should pick one and stick to it. But there are languages (Lisp, Prolog, Haskell) which are genuinely different, and I consider it a good thing that you can write compilers for them. That has yet to completely fulfill its promise on the JVM platform, where there are proofs of the concept but they are little used.