Slashdot Mirror
The Future of Java?
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).
can be found here.
It doesn't mention SmartEiffel, though, which does generate byte codes. There are probably many others as well.
Ada has a bytecode generator. See here
So does that mean that my forced ada classes in college were useful?
I like the article, and I think it is easy to see that Java is going to continue to be a force.
:) Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....
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"
smd4985
Apple's Cocoa framework, based on Objective-C, has all been exposed to Java.
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.
I think it is important to make this distinction. Don't fall victim to Salon's BS. Granted they have a talented team, and they are good writers. But so help me I am sick an tired of their political twist on everything, and their constantly playing devils advocate on every topic. The more leftist they get.. the more they alienate many of their readers.
.NET :)
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
Anyone know of any projects to compile JVM bytecode from other languages?
...
Jython
# 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 Sun are really a huge problem
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
Sure Swing is a little sluggish, but when everyone is running a p4 2GHz, it really doesn't matter....
At the rate of PC sales, I think it's gong to be quite some time before that happens.
when you think about it, MS is really trying to kill java... and in more ways than just the JVM stuff. If you ever visit the MSDN, you might see many items for converting your java code to C#, reasons to use C#.
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.
--------
Free your mind.
It's never been too late for Java, any more than its too late for other less popular but powerful languages. Just because Perl is around doesn't make TK, or AppleScript, or Python any less useful, for instance.
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...)
Vos teneo officium eram periculosus ut vos recipero is.
My first two programming classes were in Java. I really think we would have had more fun learning the same concepts in Python. The thing that I've come to love the most about Python is that it doesn't force you to build an entire class just to test a feature. It's a great language to encourage CS students do their own experimenting with.
.NET has over Java. I know there are other languages that __can__ targe the JVM, but Sun doesn't exactly seem to be pushing that. I'll never understand why though. Java could be made into their platform's equivalent of C# and they could develop their own clone of VB for Java. Hmmmm VB-J? It'd be great if they'd build VB and ObjectPascal compilers that target the JVM.
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
Click here or a puppy gets stomped!
I think Java's future can only get better, not because of the recent ruling against Microsoft - which to be honest I don't think is all that important. Rather, the fact that all the universities (at least over here in the UK) seem to be adopting Java as their main language for Computer Science and related courses. It won't be long before a whole generation of enthusiastic Java coders emerges.
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.
They failed to mention the biggest advantage to using Java - a company can develop a front to back end solution completely using Java. Admittedly, this should be achievable using C# now, but I think this is what companies are interested in rather than any cross platform abilities of the code.
Also, it always irritates me when they ask only the most biased people imaginable whether such-and-such a technology is going to survive. It's like asking the Pope and the Ayatollah which is the best religion...and leaves us no clearer as to what is really going to happen...
And, coincidentally, I went to college with him, so I have to give him a plug
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
Well, not quite two (1 1/2 maybe :)
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".
I agree completely with your comments on the future of Java as a server side solution. JSP, servlets, and J2EE are all fantastic.
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.
---
"An eye for an eye leaves the whole world blind" - Gandhi
The Java virtual machine is very much designed around the Java programming language. I have heard about other languages being able to compile to it (isn't there an Ada -> JVM compiler?), but basically the language has to be lucky and use the same general feature set. Compiling C++ to the JVM would not be reasonably possible, since the JVM does not support raw pointers (for a good reason: if pointers were allowed, it would be impossible to verify that a Java applet was safe to run locally).
.NET) defines a virtual machine which can run many languages, while posessing the verifiably secure properties of Java bytecode specifically for those languages which make such verifiability possible (basically, languages without raw pointers). If you want a VM that supports multiple languages, the CLR is really the best option right now.
:)
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?
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.
I think people make a bigger deal of MS shipping Java than they should. Java on the client has been in pretty sad shape for a long time, yet Java's popularity has grown. It's used a lot for server-side applications, and apparently in embedded applications as well (although I'm not as familiar with that side of things). Whether or not MS ships a decent JVM on Windows doesn't change this -- Java will continue to be used just as it is today.
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.
Miguel de Icaza point to the advantage of being able to compile from multiple languages.
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.
Lisp is the Tengwar of programming languages.
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.
I know that multiple languages can compile to Java Bytecode.
.NET, and I'm wondering if Java can do it too.
Can anyone tell me if one Java-compiling language can use objects written in another one?
To me, this was a major advantage of
My Journal
NetREXX came available while Java was still in it's 1.1 iterations... Developed by Mike Colinshaw (spelling probably very wrong) at IBM.
-- The universe began. Life started on a billion worlds...
-- Except on one where stupidity was there first.
Responses that are sure to follow:
The JVM supports loads of languages and so does the CLR. But who cares? People will develop, almost exclusively, in C# and VB on the CLR and people will develop, almost exclusively, in Java (and a scripting language, Jython I hope) on the JVM.
All the rest are side shows.
The JVM is cross platform now. The CLR might be, but might not (I'll believe it when its running on PalmOs and Symbian, not just Linux and BSD).
BigTom
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.
proof, n. A demonstration that a conclusion is implied by certain premises and axioms.
The page you list shows a hundred or so that run on the JVM. A similar page for .NET shows only 27.
Not what the marketing folks at Microsoft would have you believe, huh?
---- There is a fine line between sayings that make sense.
There was a whole spec for it, picoJava I think, and I believe they even got to preliminary discussions of products. But language-specific processors have always been losers and this was always a stupid idea.
That is pure bull shit, C++ is sufficiently screwed up that nobody can get it to run in managed code. However Microsoft have got pretty much every other language - Basic, Python, Eifel, Cobol, Perl, Scheme etc. to run. So the claim that .NET is language neutral is not disproved by choosing the single contrary data point that Microsoft themselves make no effort to hide. The only major languages that don't run are Common Lisp and C++, both of which have multiple inheritance which language design has been backing off from for years.
As for C# 'copying' single inheritance from Java, COM had single inheritance from the get go. I would be very surprised if Microsoft didn't have coding rules that prohibit using multiple inheritance and compiler flags to disable it for internal use. Every large software house that tried C++ in the early days discovered that multiple inheritance led to disaster. The programs could only be understood by their original authors.
C# borrows some stuff from Java but it borrows rather more from objective C. It also has meta-data tagging which if you know how to use it is massively useful.
Sure C# could have been an evolution of Java in the same way that Java was an evolution of C. The only reason it wasn't was Sun's decision to insist on full control of Java and sicking lawyers on Microsoft for wanting to use it to do other things.
Sun has repeatedly promised to make Java open and every time it has reneged. The Java Community Process was created to ensure that Sun kept control of Java, it is not an open standards process in any meaningful sense of the term. Sun retain effective control over every aspect of Java language design. The JCP is independent in the same way Vichy France was independent of Germany.
What Microsoft wanted to do was to use Java as a replacement for C++. To do that they had to have a bunch of stuff that Java didn't have so they added it. That is how every language prior to Java has evolved. For years the standard for Fortran was VAX Fortran.
Sun's hardware business is collapsing under pressure from low cost Linux on Intel boxes. They have failled to make any money from Java, execept by using it to drive sales of their hardware boxes to dotcoms when those still existed. If you think the SCO/Unix situation is bad just wait a few years until Sun has gone the way of SGI and their lawyers are looking to extract whatever value they can from their 'Intellectual Property'.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Here's another language JiL that compiles to Java Byte Codes. It's a language that's better than Java but worse than Common Lisp, so it kind of sits there in the middle.
It allows Java programmers to get around one of Java's biggest weaknesses - the lack of a macros.
http://www.franz.com/support/documentation/6.2/doc /jil.htm
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.
What exactly is there in Java that allows one to build "complex applications"?
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!
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.
I'm the big fish in the big pond bitch.
I don't know why no one has called Miguel on his claim that you have to translate everything to Java, but .NET provides a happy shiny world where all of the languages are well-supported. Clearly that's untrue.
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
I realize that each language has its strengths and weaknesses, but bear with me for a moment. You get hired at a new job, where you inherit a .NET application. As far as anyone knows, it's C#. When you start looking at it further, you realize that it is actually made up of half a dozen languages, all of which you'll have to know at least remotely before you can understand the whole thing. Is this necessarily a _good_ thing? I don't think so. The argument Microsoft uses is "everyone can use what they know, and are most productive in". That's all well and good until those people leave.
I doubt that this qualifies as objective since it is my personal opinion, but I hope it isn't cliche-ridden.
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++.
Show me some objective evidence that Java is superior, not brochure cliches.
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.
- Vincit qui patitur.
That's exactly what always turned me off from Java. There's one spot in the Sun Java book (Core Java Vol 2) I have that compares equivalent code between C, Perl, and of course Java. The code implements a proxy server. The C code is the longest, pretty ugly, but fast as hell I'm sure. The Perl code is the shortest, not very complex, and relies on a regular expression to parse the request. The Java code isn't much shorter than the C code, plus it's THICK code (you know how Java programs have variablesThatDescribeEveryLittleThingAboutThem). Of course, they sum it up with a quick little explanation of how the C code is too long, the Perl code they describe as "completely unreadable", and show the example of the one regular expression in the Perl code to back this up. They try to explain this line of code then add in parentheses "No, we didn't figure that out ourselves. Like everybody else, we copied it from another script."
WTF is that? There was one -- ONLY ONE -- regular expression in the entire Perl script. But of course since the authors will be appealing to people they figure won't understand regular expressions yet, they can win them over by pointing out the ugliness of that one line.
I nearly burnt the book after reading that one (I collect old books, so that expression doesn't come lightly to me). If you Java advocates want to win people over, you should start doing it on the merits of the language, not by bashing others. It just makes you look ignorant.
I can code "enterprise" apps in lots of languages other than Java (and no, they aren't C#, C#, and C#). It comes down to the right tool for the job, and each language has merit. That's why Perl isn't far behind Java, and C is still popular today, so many years later.
putfwd.com - 1GB Free file storage with a twist
I know I'm probably missing his, but here's how I view his decision to go with .Net/C#:
.NET and it's VM are dependent upon MS's decision to release a VM. Yeah, you could write your own, but what if MS invokes the DMCA and prevents you from implementing a "full" VM due to patents and the like? Then you're screwed, writing applications that run on a perceived "broken" VM that lacks those things that MS has deemed fit enough to lock in. "Yeah, great, OpenSource to the rescue, we'll port our VM to every platform!" Sure, and getting people to use it? Good luck. Tell Joe IT Manager that he can use a "free, OpenSource VM" from a bunch of anonymous guys on the internet or the "official VM" from MS, what's he gonna pick?
/. comments, etc that do a good job of explaining all of that, but imagine this:
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.
If you were me, you'd be good lookin'. - six string samurai
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 if anyone wants to check it out.
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. ;)
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.
Really? Java makes it so easy to know the length of an array that I would think over-running it would be a relatively rare occurrence.
where there's fish, there's cats
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 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.
Your point about speed of development is a very good one.
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.
"Enterprise app" (My definition):
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?
Farewell! It's been a fine buncha years!
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.
...other programming languages still run relatively faster than Java...
*sigh* Repeat after me: languages don't have speeds. You can write programs which run quickly in Java. You can write programs which run dog-slow in C.
A well-written Swing program is plenty fast, and (in my experience) virtually indistinguishable from a "native" application once you get past around 500 MHz.
Of course, most programs (Java or otherwise) aren't well-written. But don't blame the language because you can't use a profiler.
When can we expect to see C# compile for JVM? And when can we expect to see Java compile for .NET?
FRA: STFU GTFO
I have been working on Kawa since 1996. Originally it just compiled Scheme to bytecodes, but it is now a multi-language framework supporting XQuery, Emacs Lisp, some Common Lisp and other languages. It is easy to compile any of those into modules, applications or servlets. These days I'm mostly working on XQuery, a very interesting and useful new language from the W3C.
In my line of work I need to deal with binary data structures received over UDP/IP from DSP based systems. A lot of the data structures contain 16 bit signed and unsigned fields (it's a 16 bit DSP, so this is natural). These can be directly represented as records or structures in languages such as Delphi or C++, but a business associate using Java must use all sorts of tricks to access these fields.
From my research on the CLI it seems to have instructions for 8, 16, as well as the common 32 bit accesses into arrays and structures, as well as the support for unsigned data as well as the common signed data.
This may be one of the main reasons that Borland is coming out with Delphi and C++ compilers that produce CLI, whereas they never did so for JVM.
MS has always claim MS.net was language agnostic where Java was Java centric.
.net, ie languages with same design scope, ways of thingking etc ... but some are nothing to do with the way you thing in Java.
.net over Java, i can just tell you this is wrong. The designer of .net just did a clone. And even if it has som small differences, who said a clone was a duplication ;)
.net whereas other big buys push Java ... If they had to install the Java platform on Win32, then everywhere you will have Java, and whatever they wanted to, the fight will be over .... and MS.net dead-born ...
:(
This is nothing but a lie, several languages have been developped to compile to the Java platform (Java bytecode+JAva API) and one of the best was Eiffel ! It was done long time ago, ever years before MS decide to get rid of their Java VM (jview), Java Windows APIS (WFC) and JAva IDE (Visual J++) to start the famous project code named "cool" (now ".net").
Of course Java language is the primary language of the Java platform just as C# is the primary language of MS.net. Take a look at VB.net and you soon notice that it is not only a cosmetic change over VB6 : 100+ new keywords, complete API changes, new full object (CLR related) philosophy,... VB.net is nothing but a new language shaped for the CLS and linked to the CLI ! In clear world, if you are not used to full object oriented design you could find trapped yourself soon or later !
About alternative Java platform languages, see
You can the whole list here !
Most of them are like all the C# flavors to
One of the best is kiev, that add prolog rules which make an enormous change to the design rules (who said backtracking sx?). An other named OpenJava, has build a newt dynamicity level to compile language using the MOP (meta object protocol) that is the most impressive stuff ever brought.
Ok, now you now that multiple languages are existing on both sides. But guess what ? I do thing that multiple languages are no a graal.
Let me explain, if the languages are bijective (ie same scope, same stuffs), then there is no special reason you should consider using a language over an other. Let's take MS.net, all the languages are bijective (with exclusion on certain fonctionality usable only in C#), that means only one is usefull. Why should people have to learn 5 languages to read a project sources ? Why should enterprise invest in 5 languages training ? There are no reason at all ! This is the reason why MS know that C# will be the only surviving middle term language (why would you choose a language where less stuff can be done). The same thing apply to bijective Java languages !
In clear words: C# is the only valid language for MS.net platform and Java language is the only valid language for Java platform !
But point is that there are languages aimed at the JAva platform that are not bijective (OpenJava, Kiev). Because they add major features and new design concerns.
Whatever MS claimed superioritty of
MS is worry and they do FUD, just because they've realized they trap themselves by doing a Java clone instead of continuing their leadership on the Java platform (remeber the 98' when both MS VMs and IDES where JAva leaders ?).
If Java get to the client side then we could have a drastic shift of platform and this could endanger the client side domination of Win32 within the next 5 years !
You could laugh at those statement, but the past year has prove that MS is now alone on pushing
Poor little MS
At my company, "nterprise" means supported software with automatic failover, guaranteed uptime, and linear scalability by adding more servers and CPUs.
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.
- Vincit qui patitur.
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.
...interesting if true.
I've read a little about the different languages that are available for .NET and I've used J# before. What I found out was somewhat disturbing and can be found documented out on the web in several places. First, it is clearly stated by MS that the intent of J# (and other langauges available on the .NET platform) is not to be able to use JAVA as you would in its "natural habitat". They'll admit that basically they wanted to allow programmers that were familiar with the *syntax* of JAVA to feel comfortable on the .NET platform. They even provided something that resembled the JAVA class library, but is horribly out of date. Why? Because they don't want you to use the JAVA class libraries, they want you to use the .NET class libraries. The version of Java's libraries they provide is intended as a stepping stone as you port your app to use the .NET libraries. When you hear MS talking about being able to use smalltalk (or whatever) on .NET they're not talking about using smalltalk with its class library (although one may be provided by MS or a third party), they're talking about using smalltalk-ish syntax to make .NET library calls. This is also why you'll hear people who understand what .NET is calling it "themes for languages" - it merely a superficial thing.
I always thought that this would be a good application of Transmeta's "Code Morphing" technology. If it can provide an x86 translation layer then I would think java would be an obvious next step, and all (most?) of their optimization techniques would still apply. Of course, if that were true they probably would have done it already, so I must be missing something.
Move on. There's nothing to see here.
I used to teach J2EE to wall street developers, and in particular new college grads. Most have no clue what an enterprise application is, so I came up with a working definition.
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.
-Stu
I've always thought the negative press about Perl came from two sources:
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.
I read the internet for the articles.
I can't really disagree with you, but when we talk about Java, we should separate the issues:
Java as a programming language
Java as a computing environment
For the first point, Java is a fine programming language and has quite many advantages over C++, but it also has some disadvantages:
lack of generic programming; at least C++ has templates, which solves 90% of the problem; I have not yet a program that does not need to use arrays and lists of different types. Although Java uses Object, objects still have to be allocated on the heap with 'new', which is a waste of resources.
no stack objects; I don't know the internals of the stack management and the complexity of C++, but since C++ managed it, why not Java ? why should I have to create an object on the heap just to use it locally ?
no structs; some times I only want to bind together some data without the overhead of classes. I can't do that with Java. That means that I can't also have a binary package represented as a struct: in C/C++, I can cast the buffer pointer to the appropriate message structure and access the data (for example received from the network) with one call, but in Java I have to code a whole series of classes in order to convert a byte array to a message.
I don't know why the garbage collection is such an advantage. In the place that I work we have written apps with milions of lines of code using C++ and we never had a problem with memory leaks. Of course, being military and scientific apps, there was a good design before coding, so we had a pretty good knowledge of when to allocate/free stuff. But it is not hard to make C++ objects garbage-collected. All that is needed is a base class that upon its construction puts the object in a global list and a template pointer that increases/decreases automatically the reference counter of the garbage-collected object when assigned to it; later, the list will be traversed and objects with no reference will be deleted.
We have used Qt for our apps, and the speed of coding is similar to that of Java. We also have a Java department and we keep hearing design issues that are derived from the lack of certain features in Java, generic programming being the most serious flaw.
By no means am I saying that C++ is better than Java, the programming language. But the goals of the two languages are different. The big problem of C++ is the lack of standardised libraries for gui, multithreading, database I/O etc. Thank god for Trolltech that we have found a piece of code really worthy of its price, and that is Qt which solves all these issues (and many more).
For the second point, I don't like either interpreted or byte-code languages with virtual machines. I think they are a waste of CPU time and resources. I am 100% certain that there is no point in having static Java apps executed by a virtual machine: they are very slow, even with top-of-the-range Pentiums. And when we say slow, we mean slow enough for an experienced user to handle: for example, I have personal experience of a versioning and control application that we use at work which is very slow, although it runs on a P4 at 1.8 GHz. It may not be slow, but it definitely feels slow.
Another problem of C++ is that it does not compile the same in every platform. The Java's VM solves the problem, but is it really needed ? aren't programming languages invented for this exact reason ? other environments offer complete source-code level compatibility for every platform (for example ADA 95) without a VM. Why Java needs a VM to run static apps ?
Does Perl/Python/LISP support enterprise javabeans
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.
Table-ized A.I.