Beyond Java and the silent majority

I haven't read "Beyond Java" yet. When I hit the book store the other day they didn't have it :( Don't ask why, but I don't buy books online. For me, books are usually an "I want it now" affair with me. When it comes to purchasing books, I'm ssssooo pCommerce (physical commerce). Back on topic, I think there is great value in scripting languages. Picking up some JVM-based dynamic scripting language (where I can leverage my rt.jar knowledge) is inching up on my to do list. I'm trying to figure out where to start. Jython? Groovy? jRuby? No shortage of choice, that's for sure.

The discussion that "Beyond Java" invokes is a good one. However, some of the ASCII verbage and opinion I read seems to be based on something besides fact. The verbage I am talking about is the questioning of the survival of Java the language, or to some, all things Java (JVM / libraries / language). Not sure what facts those discussions are based on. The discussion I read tend to quote anecdotal evidence. Listening to the Java Posse while doing yardwork yesterday, the podcasting team put forth real data showing the growth of Java. An Evans Data survey shows Java usage is up 50% in the last 6 months in small to medium businesses. 1 in 4 developers at small firms use JEE, with a projection of another 13% within two years. 60% of developers in small to medium businesses use JSE or JEE at least some of the time, with 20% saying they use it a majority of the time, with a growth projection to 70% and 35% respectively within 2 years.

The tendency of some developers I know to "cat 'discussion thread' | parse topic | wc | conclusion" is unfortunate. Internet forums can be a poor indicator of what is really happening. There is the vocal minority and then there is the silent majority. The two are not always in agreement.

Comments:

I actually just ordered my copy from Amazon last thursday after Chris Q talked about it and following the java.net discussion on the book. It wasn't bad priced so I figured what the heck, less then 17$, or so, wasn't to bad. Should get it today I believe... Hrm, I should go check the tracking on it! ;)

The whole idea from what I gather of the book is interesting, and it will be interesting to see where Java goes from here out. But I don't like all the doom saying people, I don't think thats constructive at this point and instead of waisting all the energy fortelling the doom and preaching it, they should put that energy into something more useful like trying to help Java grow where it needs too. My take on the whole thing, I hope it helps and I'm just going to keep learning new things as I can and go from there!

My list of languages to learn so far includes Lua, Python, D, Ruby, SmallTalk, Objective-C, and to keep learning more about the languages I've already learned about. Personally I think that just learning what those languages have to offer, what they are good for, and keeping current on what I use daily puts me ahead of the game. More energy spent learning and flowing with everything, less on going postal over the doom sayers!

BTW, what was it that Tim Bray(spelling?) showed with dynamic langauges that was eye opening?

Posted by Jeffrey Olson on February 05, 2006 at 11:35 PM PST #

The best place to start JVM based scripting language is "JavaScript". Mustang includes Rhino based JS engine in it. No separate download needed. Also, Rhino's Java-to-JavaScript communication is reasonably good (to leverage rt.jar knowledge) - http://www.mozilla.org/rhino/ScriptingJava.html

Posted by A. Sundararajan on February 06, 2006 at 12:09 AM PST #

Jeffrey, the positive impact the JVM can have on these scripting languages. He threw up one test that showed a Ruby script that ran quite a bit faster on the JVM (via jRuby). I don't recall the numbers offhand :(

A. Sundararajan, all I can say is "duh". Dunno how I forgot that one. FYI, there is a blog entry today covering a JavaScript editor for NetBean.

Posted by John Clingan on February 06, 2006 at 12:28 AM PST #

Java is still a pretty suitable language for people who can't be very productive with C/C++, while wanting a similar syntax, and for people who need to deal with code written in Java/compiled to JVML in the first place. It will be for as long as such people exist. See also: COBOL, Delphi and all that. The JVM is, as a corollary, only really useful for people who need to deal with (legacy or fresh) code compiled down to Java bytecode. Such people tend to be a minority of users of non-Java languages, the rest of the developers and users is already having a good time with the platforms as they are, or they would not be using them. If people really badly wanted Java, they would be using that, and if the JVM was such a great platform for dynamic languages, Jython, JRuby, Kawa etc. would be the dominant implementations in their non-Java niches. The fact that they are not, tells a lot about actual usefulness of the JVM in practice for languages other than Java, and dynamic languages in particular. There are several fundamental problems regarding JVM's life post Java's death: 1) the JVML is a pretty poor choice as a general purpose IR. It's too simple, and too limited. It has not been designed for that purpose, so that's not a surpise. 2) the JVM integrates very. very poorly with the rest of the OS it is run on. JNI is pretty poor compared to PInvoke, for example. That, again, is by design, since Sun does not want you to use Java or the JVM as a tool, and to pollute your code with blasphemous unportable native code. See Sun's outbursts of love towards the SWT toolkit, and of course the whole J#/Microsoft JVM debacle. 3) It ramms proprietary technology down the throats of the users. Currently, using a high performance JVM largely means using a proprietary VM like Sun's, BEA's or IBM's. If the argument is to compile dynamic languages to the JVML in order to get better performance, then that also implies also forcing users to deal with all the time-wasting issues one has to deal with when using proprietary technology, from wacky licesing practices[1], to being dependant on the monetary interest and chief executive's angst of some random corporation, like Sun. Certainly nothing one would want to have to deal with if one already had a successful dynamic language implementation with its own runtime engine. cheers, dalibor topic [1] The "Read Only License" is actually a software license used by Sun Microsystems for some of the proprietary parts of Java technology. Nothing explains "wacky proprietary software licensing practices" better than a license that allows you to read the code, only, but not to compile and to run it, I think.

Posted by Dalibor Topic on February 06, 2006 at 05:57 AM PST #

>Java is still a pretty suitable language for people who can't be very
>productive with C/C++, while wanting a similar syntax, and for
>people who need to deal with code written in Java/compiled to JVML
>in the first place.

Now that’s a statement that’s pure flame bait, there is no rational proof or bases to form any thing based on logic or reason to back that up. Java is just like any other language out there, in fact a lot of folks learn it before they ever learn c/c++ in schools now. Those same folks don’t know anything about other languages syntax, they most likely don’t understand the fundamental differences for uses of the different languages, and they most likely have never been introduced to a variety of languages when first starting out. It takes time for people to acquire knowledge about languages, and even more time to understand the fundamental core differences of different languages, if that happens ever. Saying that everyone should start out with c/c++ and then if they can’t hack it move to java would be like telling a c/c++ coder they couldn’t hack it in lisp. It’s more then likely completely untrue.

Another thing, just because someone’s not as productive in one language as they are in another is influenced by many other things. Any reasonable developer should know that without question. You pick the tool that best fits the job your going to tackle, and if multiple tools fit the job, then its all fair game. Just because someone chooses Java/Swing/ or Java/SWT over C/win32 or c++/mfc doesn’t mean they can’t be productive in those other platforms, more then likely there are other circumstances affecting the choice more then “I hate c/c++ cause it suxz…”

And when you are talking about retooling an entire development department to meet the needs of the foreseeable future, especially in the case of government, you’re talking about having to pick something and stick with it for years to come. Your expertise level in such things climb to where your knowledge of it across the board is more focused on that one tech then any others. And by doing so, the shared knowledge base can be traded back and forth with your coworkers without a major loss of productivity. Versus taking someone who does VB as their day job for the last 7 years and throwing them on a C/win32 project or a Java/Swing project then back to VB, yes they are less productive but you have to expect that. There is no simple cut and dry reasoning for broad statement like that, except to bait a language fan boy to start a fight with.


>It will be for as long as such people exist. See also: COBOL, Delphi
>and all that.

Those languages appeared and took hold because of the gap they filled at the time they became massively in use. COBOL became very popular in government and businesses because it gave them something they needed. More defined was Delphi vs VB. A lot of folks hated that you had to distribute the VB runtime with a VB application; Delphi gave them the ability to distribute standalone applications without that need. I’m sure you could go on and on about the reasons those languages took hold when they did and are still around, and each reason has its merits.

>The JVM is, as a corollary, only really useful for people who need to
>deal with (legacy or fresh) code compiled down to Java bytecode.

What’s the difference between that and Python byte code? Ruby? Perl? Lisp can be ran as an interactive language built on a VM. Does that make Lisp only really useful for people who want to interactively work with the language? Nope.

For that matter, any language that runs through a VM is no different in concept then any other language that uses a VM. Execution of that language, syntax, etc… are different, sure. But at the end of the day, those languages still use the same thing, a VM to run. Perhaps Perl coders are nothing more then people who couldn’t hack using bash? Would that be a fair statement?

>Such people tend to be a minority of users of non-Java languages,
>the rest of the developers and users is already having a good time
>with the platforms as they are, or they would not be using them.

Just because you have fun using a platform doesn’t mean your going to stick with it and continue using it. Python, Perl, D, Ruby, and others are all great languages in their own regard… Sure they have their own following of zealot developers who preach how it’s the next coming, but guess what? Those languages are only as useful if something gets developed on them that is used by users! And guess what else? 99% of users don’t have the VM’s or interpreters installed on their windows boxes! Which, funny enough, means that those languages are really only useful on platforms they come installed on. You can code anything and everything you ever wanted in any language you choose, but it doesn’t mean its going to get used. As they say, the buck stops here. If its not used, then its use grows more and more irrelevant in the overall picture.

>If people really badly wanted Java, they would be using that, and if
>the JVM was such a great platform for dynamic languages, Jython,
>JRuby, Kawa etc. would be the dominant implementations in their
>non-Java niches. The fact that they are not, tells a lot about actual
>usefulness of the JVM in practice for languages other than Java, and
>dynamic languages in particular.

From what I gather, Tbray showed some internal demo to sun folks about using dynamic languages in the JVM for a substantial improvement over their native execution environments. And the use of the JVM for other languages will be helped out in the next version of Java from what I recall, they made some changes that will greatly enable the use of other languages via the JVM. Check out: http://www.tbray.org/ongoing/When/200x/2004/12/08/DynamicJava, http://java.sun.com/javaone/sf/2005/roadmaps_directions.jsp, for an example of that effort.

>2) the JVM integrates very. very poorly with the rest of the OS it is
>run on. JNI is pretty poor compared to PInvoke, for example. That,
>again, is by design, since Sun does not want you to use Java or the
>JVM as a tool, and to pollute your code with blasphemous unportable
>native code. See Sun's outbursts of love towards the SWT toolkit,
>and of course the whole J#/Microsoft JVM debacle.

Is that suns fault totally? If MS wanted Java to succeed on its platform wouldn’t they have made some effort to strive towards making it more integrated like .Net? Wait, not they wouldn’t because it’s a competing product to .Net. Same with Perl, Python, Ruby, language_of_day_here, etc… Apple has no vested interest in seeing Java succeed except that developers use it on their platform, so because of that they support it.

JNI is a beast of its own. I personally don’t find it all that hard to use. I also personally have no issues with how its currently implemented because it puts up a barrier of entry so you don’t have folks trying to do things via it just because they can. Those with the knowledge can, those without probably shouldn’t be toying with such abilities until they really have a need to. In which case there isn’t a steep learning curve to enter that fray because they most likely will have the base knowledge to know how to proceed with it.

As for SWT, I’m still out on it. I’m not a fan of it because it’s a 3rd party bundle of joy. But at the same time I can understand the claimed reasoning of it. The best part of it is that it is 3rd party so it didn’t break the core beast that is Java… Unlike Microsoft’s J# fiasco.

>3) It ramms proprietary technology down the throats of the users.
>Currently, using a high performance JVM largely means using a
>proprietary VM like Sun's, BEA's or IBM's.

Last I heard anyone could write a JVM, but in order for it to be certified it has to meet some requirements? How is that ramming proprietary tech down your throat? Not only are there several available options out there for a JVM, they provide one for free to anyone who wants it across multiple platforms. Apple provides one to OSX users. GNU has a few various projects related to it I believe too?

If anything your gripe here is that you can’t exploit various things to improve the performance of a non SUN/IBM/BEA jvm in your opensource project because it would be a violation of some agreement(s). And while that might be the case, there are usually reasons for those things… Such things as licensing IP from others to use in your product to improve the performance using a certain technique. Well guess what? That’s life in today’s world with how its come up. There is no getting around that, yes you can’t use something but guess what, find another way and then once you have find a way, you’ve just made that piece of IP a bit more useless overall. Creativity, its great.


As for my personal side on all this, I’m not affiliated with Sun. I use more languages (Python, Perl, Java, C/JNI, c/win32 across various projects I’m touching so far just this week) in a week then most folks ever learn. And I’m a big proponent of folks learning new languages & platforms just to learn, something I get chastised for at work constantly. I have my list to go through this year around my day Job.

Posted by Jeffrey Olson on February 08, 2006 at 12:01 AM PST #

>>2) the JVM integrates very. very poorly with the >> rest of the OS it is run on.If MS wanted Java >> to succeed on its platform >> ... > Is that suns fault totally? Never mind MS platforms: in the case of how badly Sun's JVM (and the whole Java "stack") has historically integrated with \*Solaris\*, it sure is Sun's fault totally. Although the situation has improved in tha last 18 months, the previous 5 years of internecine warfare (mostly PSARC-type issues) between the Java and Solaris efforts at Sun were extremely inconvenient for even expert Solaris sysadmins.

Posted by Mike Spooner on February 09, 2006 at 01:52 AM PST #

Post a Comment:
Comments are closed for this entry.
About

John Clingan

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today