Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sun Backs Ruby by Hiring Main JRuby Developers

ScuttleMonkey posted about 8 years ago | from the feel-the-love dept.

211

pate writes "Sun has thrown some corporate weight behind Ruby, Rails, and dynamic languages by hiring the two main JRuby developers, Charles Nutter and Thomas Enebo. Charles posted about jruby stepping into Sun on his blog, and Thomas posted his take too. Tim Bray, who started the ball rolling posted about the JRuby Love."

cancel ×

211 comments

Sorry! There are no comments related to the filter you selected.

Great News (5, Interesting)

RAMMS+EIN (578166) | about 8 years ago | (#16087330)

This is great news for several reasons.

First, and most importantly, because Sun is now throwing its weight behind Ruby, which is a wonderful language. It does have its quirks (some weird syntax and the schizophrenia between procs and blocks), but it's still one of the better languages out there. Easy to write and understand, powerful, and succinct.

Secondly, because Sun is supporting JRuby, which is an alternate implementation of the language. This will put pressure on the language designers to spell out the language in a clear specification, rather than referring to some implementation for knowledge of how things work. One of the benefits of this is that it will cause features to be thought and debated about more, which I believe results in cleaner, nicer languages.

Thirdly, because the JRuby folks seem to have the plan to develop a compiler. This could lead to Ruby's run-time performance increasing enormously, widening the scope of the language to tasks that current Ruby implementations are simply too slow for (you can extend Ruby programs in C and JRuby programs in Java, but it would be preferable if one didn't need to).

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java. Right now, the operations that the JVM supports are very much tied to the features of Java. Implementing some more flexible primitives would benefit not only JRuby, but also about any other language that targets the JVM, and make the Java platform more competitive with .NET.

Re:Great News (1)

FyRE666 (263011) | about 8 years ago | (#16087358)

I've been looking at Ruby myself lately with a view to trying to get it used in some skunkware projects at my work. I like the language itself, but it is very slow. Much as I hope it'll succeed, I can't see running Ruby in the JVM making the performance situation any better.

BTW, any project with a lead developer named "Charles Nutter" deserves respect!!

Re:Great News (2, Funny)

chthon (580889) | about 8 years ago | (#16087369)

A fast Ruby with a compiler is called Common Lisp.

Re:Great News (1)

chthon (580889) | about 8 years ago | (#16087376)

I should have added ;-)

Re:Great News (2, Informative)

TheRaven64 (641858) | about 8 years ago | (#16087392)

I found Ruby semantics to be closer to Smalltalk than CLISP. Of course, the nice thing about Smalltalk and CLISP is that it is very easy to implement one on top of the other. And yes, most Smalltalk VMs are faster than Ruby. And the Smalltalk syntax is clearer than Ruby. Uh, why are people using Ruby, exactly?

Re:Great News (2, Interesting)

arivanov (12034) | about 8 years ago | (#16087448)

First, let me ensure I got my trenches dug to the correct depth to duck for cover.

The answer is: Because it is not French.

The sole and only reason for not using smalltalk especially in the US is the not-invented-here mentality. I have yet to see a telecoms (dunno about other parts of the industry) smalltalk project whose roots are not from continental Europe. For example the Infovista carrier stuff which uses a smalltalk core was aquiried from Quallaby which surprise, surprise started its life as a french company. There are other examples as well, but I have yet to encounter a telecoms project which uses Smalltalk as its primary language and was started in the US (or UK).

Similarly, if you dig into any pre-2004 Ruby project you end up encountering some Samurai smiling at you with that characteristic smile that makes you feel like sushi.

Anyway, now it is time to duck in the freshly dug trench and wait until the flames have died out.

Re:Great News (3, Insightful)

recordMyRides (995726) | about 8 years ago | (#16087848)

Smalltalk was invented in Palo Alto, California. [wikipedia.org]

My opinion on why we don't use Smalltalk? When it came out, the world wasn't ready for it. We were still getting our heads around object oriented programming in general. The fact that it didn't use C syntax didn't help either. Smalltalk was just too much for most programmers to learn. Nowdays, since it is decades old, it doesn't have the same sparkle of a newer language, like Ruby.

Re:Great News (1)

FatherOfONe (515801) | about 8 years ago | (#16087908)

A company I use to work in the U.S. tried to use Smalltalk before I was hired around 12 or so years ago. I will give you the number one reason it stopped being used by them. $2,000 a developer seat and a month of training for each developer.

This was an IBM shop and IBM pushed Smalltalk as an upgrade path from COBOL. Then came this language called Java and it was OO, granted not as OO as smalltalk, but the development tools were and are free, or at least a lot cheaper... IBM dropped their smalltalk push and very quickly (for IBM), started to push Java. I will say that I like the idea of primatives and the thought of doing Integer.intValue() + Integer.intValue() //made up syntax but you get the point... doesn't sound as good as i + y, but then again I am not an OO purist.

Now, I am not about to make any comments on the technical merrit of Smalltalk, it might have been the best language in the world, but from my perspective they could have taken over the world if they would have GPL'd the language from the start and because of its cost, it lost out.

I do want to say that NOBODY had a clue to what country the language came from. Trust me few people outside of Redmond Washington care where a product comes from. Now I will say that people here will tend to go to a product that has docs and support in English and they tend to want to play it safe. By safe they tend to be lemmings and follow what other businesses do, but a ton of businesses here run Linux, SAP and other software and they don't care at all.

Lastly, I will say that a ton of businesses here are starting to get pissed off at the support being in India. It has got so bad lately that most shops have just started to live with bugs and crappy software to avoid calling Oracle/Dell(India). So in the long run they will stop purchasing that product(s).

Re:Great News (2, Interesting)

masklinn (823351) | about 8 years ago | (#16087480)

Mmm reasons for not using Smalltalk:

  • It's syntax is fairly alien. Most people don't like alien syntax. Ruby's syntax is much more in line with "traditional" languages such as Java
  • Ruby also has quite a lot of Perlish roots, which make it a quite "practical" language.
  • Smalltalk is a fairly unique language in the sense that it's image-based: your code always lives in your image, you never need to get out of the environment, the feeling is different
  • Smalltalk is fairly old, since it never took of most people never heard of it.
  • Last, but probably not the least, Smalltalk was quite "closed" as an architecture, for a long time the only useable implementations were commercial, which was not a good thing since there were no heavyweight backers of the language (C# has the former issue of a primarily commercial -- even if free via C# compilers and Visual C# Express -- implelementation, but it has all the weight of MS behind it)

But yeah, Ruby is much closer to Smalltalk than Lisp indeed, Ruby's main "ancestors" are Smalltalk and Perl with some bits of Lisp & others thrown in.

Another SmallTalk Derivative (bit OT) (1)

jscotta44 (881299) | about 8 years ago | (#16088123)

This is a bit off topic but maybe in line with the current thread. There is a SmallTalk/C derivative (at least heavily influence by SmallTalk and built on top of C). The Cocoa Frameworks using Objective C are gaining a bit of traction, even if it is only used for the niche Apple Macintosh market.

Re:Great News (1)

CableModemSniper (556285) | about 8 years ago | (#16087517)

Perl is the gateway drug to ruby. Ruby is the gateway drug from perl (regexps, $_, etc.) to smalltalk. That's my theory anyway. It's all part of an intricate plot started by the Ancient Illuminated Seers of Smalltalk to make Smalltalk the one true programming language. This is why to be safe, I only program in K&R-style C.

Re:Great News (4, Interesting)

Per Wigren (5315) | about 8 years ago | (#16087401)

The language itself isn't slow, the current interpreter is.

The solution is YARV [atdot.net] (Yet Another Ruby VM) which will be the official Ruby VM in v2.0. Ruby 2.0 (thanks to YARV) will have JIT and a superfast optimizer. You can get a (very buggy) pre-beta version from SVN right now. Benchmarks show that it will be about as fast as Java and .NET in most situations. Slower in some situations, faster in some.

Re:Great News (3, Insightful)

LarsWestergren (9033) | about 8 years ago | (#16087818)

The solution is YARV [...] Benchmarks show that it will be about as fast as Java and .NET in most situations. Slower in some situations, faster in some.

Yes, but the JVM is a moving target. By the time all those bugs have been ironed out, JRuby will have improved their execution speeds too. Lets not declare the winner until we have the finished products to compare, otherwise we are just playing the old Microsoft game of "lets compare the features of our future products with the features of our competition today".

Re:Great News (1)

RAMMS+EIN (578166) | about 8 years ago | (#16087407)

``I like the language itself, but it is very slow. Much as I hope it'll succeed, I can't see running Ruby in the JVM making the performance situation any better.''

I don't know why you would think that. Ruby is very young yet, and not a lot of effort has gone into making it run fast. Even if the JVM introduces a bit of a slow down compared to native executables (which is a topic of heated debate), it's entirely possible that a JVM implementation of it will outperform the current, slow C implementation.

Re:Great News (1)

masklinn (823351) | about 8 years ago | (#16087494)

Ruby is very young yet

Ruby is older than Java.

and not a lot of effort has gone into making it run fast.

That one's right though, the current implementation of Ruby is pretty much the slowest way you could ever implement it. All the backend should be reimplemented for Ruby 2.0 (including a true VM) with YARV.

Re:Great News (1)

MemoryDragon (544441) | about 8 years ago | (#16087672)

Once the stuff is compiled in as classes into the vm it will become a load faster, heck even a port of php5 to native java compilation made it 3-5 times faster. The reason for this is, all the jit, dynamic optimization etc.. mechanisms which have been developed for the jvm suddenly can start to do the work. Java is not an interpreted language it is far from that and it is one of the fastest vms you can get currently.

Re:Great News (1)

Ougarou (976289) | about 8 years ago | (#16087362)

If now, with .NET, this is the first time that Sun is thinking about adding other language compilers for their bytecode then they are way to late.
Although I wouldn't be supprised if this is Suns' response to the .NET hype, I don't think they will ever be able to top the .NET support already there. If they think this is competing with .NET, it's to little, to late.
More probable: Sun is going to add Ruby on rails to their JSP system, which is probably the only way they kan add anything to anything. They won't get anywhere with thinking they can compete with .NET features.

Re:Great News (3, Insightful)

LarsWestergren (9033) | about 8 years ago | (#16087418)

If now, with .NET, this is the first time that Sun is thinking about adding other language compilers for their bytecode then they are way to late.

Two seconds of Googling could have told you that the JVM has supported more languages than .net [robert-tolksdorf.de] for a long time.

I don't think they will ever be able to top the .NET support already there. If they think this is competing with .NET, it's to little, to late.

You do know that Java is MUCH bigger than .Net out in the real world?

More probable: Sun is going to add Ruby on rails to their JSP system, which is probably the only way they kan add anything to anything.

You really have no idea what you are talking about. Java developers could use Ruby to do fast and easy unit tests for instance. The scripting sessions at the last JavaOne showed lots of other interesting uses. Also it wouldn't surprise me if one possible long time plan wouldn't be to make the JVM the fastest, most stable and therefore the most attractive platform to run all Ruby programs.

Re:Great News (4, Insightful)

masklinn (823351) | about 8 years ago | (#16087505)

Two seconds of Googling could have told you that the JVM has supported more languages than .net for a long time.

I may be overreaching here, but I think that part of his point was that Sun never ever officially endorsed any language but Java on the Java platform. Only now that MS has started championing a pretty much official IronPython effort has Sun discovered dynamic languages, and started working towards making the JVM more dynamic-languages friendly.

Which is a damn shame, because they had Jython years ago, which they could easily have supported at almost no cost, and they let the project die on it's own.

Re:Great News (1)

Ougarou (976289) | about 8 years ago | (#16087749)

Two seconds of Googling could have told you that the JVM has supported more languages than .net for a long time.
I didn't mean the number of things to do with languages written in Java. What I was hinting at was language A to java bytecode compilers. If you search around the web, you will also hear that CIL is less language oriented then java bytecode.
You do know that Java is MUCH bigger than .Net out in the real world?
Yes. But I hoped to point to the future and say: "well, maybe". Not tell people how the world is (haha, it's purple, haha).
You really have no idea what you are talking about. Java developers could use Ruby to do fast and easy unit tests for instance.
Ok, so Ruby is a nice language. And having another possibility to run Ruby somewhere is good. And yes, JVM might become the most attractive place to run Ruby. But for the desktop, I can't really see that happening.

To keep other poeple from telling me I can't and don't know the future, these are just my 2 cents.

Re:Great News (1)

zootm (850416) | about 8 years ago | (#16087758)

To be fair, though, in technical terms the Common Language Infrastructure/Runtime was designed from the ground up with far more emphasis on language interoperability. The fact that this is having influence upon the Java creators is a good thing, and should not be dismissed so easily. The Java system itself is currently being changed to have better support for dynamically-typed languages and scripting languages in general, which is clearly the effect of the outside popularity of these types of language.

.NET (CLR/CLI/whatever) is a very similar project to Java, with slightly different (technical) goals which means that it can influence the evolution of Java by competing more closely with it. I seriously doubt that JRuby is a manifestation of this, but there has been positive developments, which competition of this sort will usually if not always bring, such as a proposal for Java closures [blogspot.com] (giving an equivalent to function types and .NET's delegate types).

I agree that .NET will not kill Java, of course. In fact, my belief is that it'll do nothing but bolster it, by forcing it to evolve beyond the rut which it was beginning to be stuck in. .NET's language flexibility is something else that Java would do well to learn from, and it looks like it is. :)

Re:Great News (1)

leonmergen (807379) | about 8 years ago | (#16087377)

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java. Right now, the operations that the JVM supports are very much tied to the features of Java. Implementing some more flexible primitives would benefit not only JRuby, but also about any other language that targets the JVM, and make the Java platform more competitive with .NET.

I think this mainly means adjusting the assembler of Ruby to output code that can be understood by, for example, Jasmin [sourceforge.net] , rather than making the JVM understand instructions which are ruby-specific. You don't need to make a different instruction set for a virtual machine when you want to support multiple languages, just like you don't need to make a different instruction set for a processor to be able to run, say, Visual Basic executables or C++ executables. It's just a matter of a compiler needing to translate to the right instructions.

Re:Great News (1)

RAMMS+EIN (578166) | about 8 years ago | (#16087415)

``You don't need to make a different instruction set for a virtual machine when you want to support multiple languages, just like you don't need to make a different instruction set for a processor to be able to run, say, Visual Basic executables or C++ executables. It's just a matter of a compiler needing to translate to the right instructions.''

Of course, and I didn't say that Ruby _can't_ be made to compile to JVM bytecode, I just said that the JVM bytecode is very much tied to Java. If you look at the specifications, for example, you will see that there are lots of references to Java's type system, and high-level support for Java's methods and calling conventions, without low-level primitives that could be used to implement, say, closures and proper tail calls efficiently.

Re:Great News (1)

TobascoKid (82629) | about 8 years ago | (#16087519)

Groovy has closures. They seem reasonably effecient (it's a scripting language on top of Java, so let's face facts - run time effeciency is not the main reason for choosing the language).

I also seem to recall that the next version of Java will have some enhancements for dynamic languages (though it came out of Sun's effort to port Visual Basic to Java)

Re:Great News (1)

schlenk (941701) | about 8 years ago | (#16087506)

Sure you can load the burden onto the compiler of all languages you want to port, instead of making the VM more flexible and support dynamic features. Look at the Intel/HP Itanium processors non-success how well it works to put the burden on the compiler writers.

If you add some nice opcodes to the VM you can save lots of compiler writers from doing extremly complex translations all over the place. Try for example to compile Tcl code to Java Bytecodes, especially with things like variable and command traces, redefining core commands on the fly and so on. There is a reason most languages under the Java VM are mostly interpreters, not compilers. Doing good compilers for dynamic languages is hard.

The only reason Sun could get away with burdening the compiler writers with the trouble of working around the shortcomings of the Java VM is the pure marketshare of Java. Quite similar to the strategy of Microsoft with .NET/CLR.

Re:Great News (2, Informative)

LarsWestergren (9033) | about 8 years ago | (#16087394)

The JRuby folk can also help iron out bugs in the JDK/JRE which inderectly benefit all Java developers/users. Also this will hopefully ease off the preassure to include everyones' favourite feature X into Java, something that in my opinion is threatening to turn Java into an even bigger mess than C++ (you know, an octopus created by nailing extra legs on a dog).

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java.

JSR 223 [jcp.org] , a framework for "allowing scripting language programs to access information developed in the Java Platform and allowing scripting language pages to be used in Java Server-side Applications" has been kicking around at least since 2003 and is included in the upcoming JDK6 which comes with the Rhino JavaScript engine included. Other scripting people like JPython and Groovy have done great work (from what I understand, I'm not a fan of dymanic languages myself).

Good that this was finally posted on Slashdot, I was a bit peeved when my submission was rejected [slashdot.org] .

Re:Great News (1)

RAMMS+EIN (578166) | about 8 years ago | (#16087432)

``Also this will hopefully ease off the preassure to include everyones' favourite feature X into Java, something that in my opinion is threatening to turn Java into an even bigger mess than C++ (you know, an octopus created by nailing extra legs on a dog).''

That goes to show how important it is to design your language to be flexible from the start. Java is the kind of language you _have_ to modify to get some desireable features. See, for example, the overhaul of the type system that was necessary to get containers to work nicely.

Re:Great News (1)

EsbenMoseHansen (731150) | about 8 years ago | (#16088280)

See, for example, the overhaul of the type system that was necessary to get containers to work nicely.

And even then, the type system is still not up to scratch. E.g, there is no way to cast from Object to Map in a typesafe way. That is, you can cast, but the object might turn out to be a Map or similar. This is because the Java type system cannot carry around the parametric types.

Re:Great News (0)

dkf (304284) | about 8 years ago | (#16087708)

threatening to turn Java into an even bigger mess than C++ (you know, an octopus created by nailing extra legs on a dog).

Not an octopus, a centipede.

Re:Great News (1)

MemoryDragon (544441) | about 8 years ago | (#16087447)

Ahem, there always have been numerous languages running on the VM, all Sun did lately was to add standardized runtime weaving to the mix, so that extremly dynamic languages can alter the compilates on the fly. This stuf has been in since 5.0 but only on the Sun VM in 6.0 it is standardized. Most of the dynamic languages running on the vm so far have been relying on pure interpretation, those now can be compiled thanks to the dynamic runtime code weaving.

cleaner language? (1)

backwardMechanic (959818) | about 8 years ago | (#16087560)

One of the benefits of this is that it will cause features to be thought and debated about more, which I believe results in cleaner, nicer languages.


I'm all for debate, but does that really create cleaner languages? Is c++ cleaner now that a panel decide what goes into it (I'm thinking of the STL here)? I kind of like the model of one guy with a neat idea, trying to produce a language that works the way he wants it to.

Re:cleaner language? (1)

dkf (304284) | about 8 years ago | (#16087684)

The advantage of a committee is not that the committee is better than one man with a vision (I can't think of any instance where that's true, even when the committee includes the original one man) but rather that the committee can keep going even when some of its members leave or are busy. The one-man-band approach can't do that.

Re:Great News (2, Informative)

vhogemann (797994) | about 8 years ago | (#16087810)

Fourthly, because there is just a slight chance that Sun will decide to make the JVM more flexible and amenable to languages other than Java. Right now, the operations that the JVM supports are very much tied to the features of Java. Implementing some more flexible primitives would benefit not only JRuby, but also about any other language that targets the JVM, and make the Java platform more competitive with .NET.


AFAIK, The 6th major revision of the Java platform, codename Mustang, already provides a well defined interface for scripting languages (JSR-223). There is already an official implementation of the Javascript language bundled with it, named Rhino, and the Groovy script language (that is somewhat influenced by Ruby) is officialy supported too.

Also, it seems that Sun is trying to address some issues that prevented scripting languages from accessing the full power of the JVM, this is particulary true for dynamic typed languages such as Ruby and Python. As Java is itself a static typed language, the JVM is optimizated for it, so there's lot of room for improvements... but they probably won't appear until after Mustang is released.

Just my $0.02

Re:Bad News (1)

namekuseijin (604504) | about 8 years ago | (#16088039)

"it will cause features to be thought and debated about more, which I believe results in cleaner, nicer languages"

I can see where this will lend to: a convoluted syntax more close to Java and less of the conciseness of Smalltalk and Perl...

Re:Bad News (2, Interesting)

RAMMS+EIN (578166) | about 8 years ago | (#16088100)

I very much doubt that. It's languages like Perl, PHP, Ruby, and Python that have the odd features that cause massive problems when the language grows out of its initial niche and starts being applied to large, Real World problems. Many of these languages have little hacks that seemed advantageous when originally conceived, but later turned against them. Java has comparatively few of these issues (no list context vs. scalar context, scopes that don't nest, unpredictable syntax, etc.) - its main problem is that it's extremely verbose and repetitive.

First Psot! (-1)

Anonymous Coward | about 8 years ago | (#16087331)

^_-

Support for Dynamic languages (4, Insightful)

EqualSlash (690076) | about 8 years ago | (#16087343)

Long ago, Microsoft hired Jython creator Jim Hugunin to work on IronPython. The aim is to make dynamic languages like python work better in .NET platform. Looks like Sun doesn't want to lose out in the race in supporting dynamic languages.

Re:Support for Dynamic languages (4, Insightful)

TheRaven64 (641858) | about 8 years ago | (#16087402)

Smalltalk, the archetypal dynamic language, already runs quite happily on top of the JVM. Sun doesn't need better technology, they need better marketing. Last time I checked, there were more languages supported by the JVM than the .NET CLR, but Sun only ever talk about Java while Microsoft talk about everything. This is a PR move to let the world know that the JVM is not just for Java.

Re:Support for Dynamic languages (2, Insightful)

egghat (73643) | about 8 years ago | (#16087568)

This is a *good* PR move.

Which is not the norm when you're talking abount Sun microsoystems.

Bye egghat.

Too young to remember Tcl/Tk at Sun (1)

Richard W.M. Jones (591125) | about 8 years ago | (#16087523)

Well, it's hardly the first time that Sun has got involved in scripting/dynamic languages.

Back in 1994, Sun hired the core developer behind Tcl/Tk [www.tcl.tk] , and asked him to form a team around the language / graphical toolkit. The toolkit was very widely used and quite promising (for the time), but it languished at Sun and eventually they dumped it.

Rich.

Re:Support for Dynamic languages (1)

killjoe (766577) | about 8 years ago | (#16087729)

Ironpython just got to 1.0. You still can't write DLLs in python and call them from C# or VB.NET. That road only goes one way. You can call DLLs you wrote in C# from python but not vice versa.

I am not saying it sucks but it does seem half assed to me.

Not exactly a good thing (-1, Troll)

Anonymous Coward | about 8 years ago | (#16087357)

Java is a marketing driven answer to a non existant technical problem, the best move would have been replacing Java with Ruby, but we cannot expect this from Sun. Heh!
Now, if and when some good Ruby software will be written by these folks which will rely on a JVM to be run, and people starts adopting it, we'll know that Sun is screwing the Ruby community. Think about what Azureus would be if it was written in a decent programming language.

Re:Not exactly a good thing (1)

RAMMS+EIN (578166) | about 8 years ago | (#16087395)

``Java is a marketing driven answer to a non existant technical problem,''

To be fair, Java does have some advantages over C and C++ for application development, and I think that Java has worked wonders in the corporate world.

``the best move would have been replacing Java with Ruby,''

Not necessarily. Java and Ruby have different strengths. For example, Java has static typing, which helps catch errors at compile time.

``Now, if and when some good Ruby software will be written by these folks which will rely on a JVM to be run''

Not necessarily. Just because Sun supports JRuby doesn't mean CRuby is going to disappear.

``Think about what Azureus would be if it was written in a decent programming language.''

You can't very much blame the state of Azureus on Sun. It was, after all, the Azureus developers who made it the way it is, through language choices and programming practices.

Re:Not exactly a good thing (0)

Viol8 (599362) | about 8 years ago | (#16087410)

>To be fair, Java does have some advantages over C and C++ for application development,

Apart from supposed portability I can't think of any. And that portability is overrated
anyway since how often do companies mix and match Windows with X terminals with java stations
to run a front end GUI, and how often does something think that a huge 1 million line
backend mainframe program would be so much better if it could run on a cheap PC too?

Re:Not exactly a good thing (3, Informative)

RAMMS+EIN (578166) | about 8 years ago | (#16087445)

``Apart from supposed portability I can't think of any.''

I don't think portability is the real advantage. I even doubt if Java really is more portable. No, the real advantages are safety and garbage collection. C and C++ programs are rife with format strings, unchecked return values, unchecked casts, unsafe I/O primitives, and manual memory allocation. All of these are rich sources of bugs. Buffer overflows are in the top three of most common vulnerability types (probably first after injection vulnerabilities, which Java's SQL API protects against, too). Memory leaks are also common, e.g. Firefox suffers badly from them. Unchecked return values have been responsible for some major privilege elevation vulnerabilities in Linux. All of these can't happen in Java, or at least, Java greatly reduces the risks.

And don't forget about identifiers (1)

Gorath99 (746654) | about 8 years ago | (#16087470)

Another big advantage is the fact that java identifiers (variable/procedure/class/etc. names) actually make sense. Sure, it's verbose, but syntax completion and a decent resolution on your monitor practically negate that problem. The added clarity more than makes up for it.

Disclaimer: YMMV, and yes, I do know that you can use verbose identifiers in C/C++. That doesn't help much if nobody else does so.

Re:And don't forget about identifiers (0)

jma05 (897351) | about 8 years ago | (#16087723)

> Another big advantage is the fact that java identifiers (variable/procedure/class/etc. names) actually make sense.

???

> Sure, it's verbose, but syntax completion and a decent resolution on your monitor practically negate that problem. The added clarity more than makes up for it.

No. They don't. "Syntax completion" helps me write code, not read it.
Verbosity != Clarity
Here is the dictionary meaning of Verbose
Verbosity: long-winded: using or containing too many words

Java is verbose because it lacks features that ought to be there in modern languages in the first place to properly express the logic at the appropriate level of abstraction. And that is by design. It was intentionally created for the least common denominator - initially for web monkeys (applet rage) and later for cheap commodity coders for the the enterprise (J2EE craze). Of course, I am not belittling Java coders. Smart people do work with Java. And there are other reasons for it than the language - more jobs, critical mass advantage etc.

Java was released in 1995. Is Java better than C++? Maybe. Depends on how you look at it. But Java was a step backwards in every way compared to any serious language released from around that time onwards.

> Disclaimer: YMMV, and yes, I do know that you can use verbose identifiers in C/C++. That doesn't help much if nobody else does so.

I think you are confusing language features vs language culture. Language culture has more to do with it's application. Business logic obviously will be written quite differently than bit twiddling.

Re:And don't forget about identifiers (1)

LordLucless (582312) | about 8 years ago | (#16087930)

To be fair, Java was not originally created for applets; the idea behind it was for embedded applications. It just so happened that nobody really wanted it for embedded applications, and the web just started to boom at the right time for applets to catch on. Sun didn't intentionally create it for applet authors, they're just the first people who picked it up.

Re:Not exactly a good thing (0)

Anonymous Coward | about 8 years ago | (#16087642)

AFAIK Ruby is garbage-collected. So why does it have to run on Java?

Also, I doubt Sun makes a big commitment to Ruby, as they already have Groovy for the same purpose (Java-suited dynamic language).

Re:Not exactly a good thing (0)

Anonymous Coward | about 8 years ago | (#16087456)

Java has garbage collection and is a simpler language than C++. The Java library is huge, but the actual language doesn't have nearly as many things that will bite you in the ass as C++ does. So it's easier to learn and harder to shoot yourself in the foot. I must not be as smart as the C++ fans, cause I prefer having a language like that for most of my development. I find that I can get things done in Java faster just because I spend less time catching bugs. My favorite's language is actually Ruby these days, but that's still impractical for a lot of things I like to do.

I rather like C. For kernel hacking, I can't imagine using anything else. But I haven't done kernel hacking in five years -- it's just not something that comes up in my life these days. :-P And while Java's not simpler than C, it is still safer.

Re:Not exactly a good thing (1)

masklinn (823351) | about 8 years ago | (#16087521)

Java has garbage collection and is a simpler language than C++. The Java library is huge, but the actual language doesn't have nearly as many things that will bite you in the ass as C++ does. So it's easier to learn and harder to shoot yourself in the foot. I must not be as smart as the C++ fans, cause I prefer having a language like that for most of my development. I find that I can get things done in Java faster just because I spend less time catching bugs. My favorite's language is actually Ruby these days, but that's still impractical for a lot of things I like to do.

You should try the D Programming Language (from Digital Mars). It's much cleaner than Java, and faster. Has all the advantages of java (but the number of third-party packages I guess) with pretty much none of the inconvenients.

Give it a try between two Ruby sessions ;)

Re:Not exactly a good thing (1)

Abcd1234 (188840) | about 8 years ago | (#16088166)

but the number of third-party packages I guess

And thus you illustrate why it's not successful. Let's pick a quick list of very successful languages:

Python
Perl
Ruby
Java .NET

You know what this list has in common? An extremely powerful set of standard libraries. Hell, the whole reason I enjoy working with Perl and Java is because of the very rich set of APIs made immediately available to me (and in the case of Perl, this extends to CPAN, which is ridiculous in it's breadth).

APIs are the key. Without them, no developer will bother. As a contrasting example, despite the fact that I love the concepts in Lisp, I've never embarked on a major project in it because I'm invariably forced to roll my own <insert library here>. The same is true of Objective-C (unless you're on a Mac), Smalltalk, and I'm sure many *many* others.

Re:Not exactly a good thing (1)

masklinn (823351) | about 8 years ago | (#16088254)

Standard Libraries are first-party packages, I was talking about third-party packages. D has a fairly good stdlib (less extensive than Python's or Java's, but pretty much at Ruby's level, and with a documentation that doesn't quite suck as much).

Re:Not exactly a good thing (2, Insightful)

$RANDOMLUSER (804576) | about 8 years ago | (#16087478)

Think harder.

How about a bazillion prewritten, documented, tested, standardized, open source library modules, many of them supplied by Sun with the language, to do bigmath/network/file/database/sql/2D-3Dgraphic/GUI /whatnot ops?

Tell you what, you roll anything trickier than "hello world" from scratch in C/C++, and I'll do the same in Java, and we'll see who has the choice of more predefined stuff to use, and who finishes faster with a program that runs more correctly.

Re:Not exactly a good thing (0)

Anonymous Coward | about 8 years ago | (#16087590)

)and who finishes faster with a program that runs more correctly.

That program -and its jvm- will however run almost everywhere under a C++ + C operating, system under a C+asm kernel, and often will call functions contained in C or C++ libraries for speed reasons. This is a chain where one link can break all the others. If your Java program still runs fine it's because even software written with other languages can (as it did for decades).

Re:Not exactly a good thing (2, Insightful)

Grr (15821) | about 8 years ago | (#16087816)

Tell you what, you roll anything trickier than "hello world" from scratch in C/C++, and I'll do the same in Java, and we'll see who has the choice of more predefined stuff to use, and who finishes faster with a program that runs more correctly.

I pick a 3d shooter. Now you get to pick anything less yawn inspiring than a database driven office app right? This is a fun game. ;)

Seriously though, each language has applications that it's well or badly suited for. Each moderatly proficient software developer should be able to pick the right tools for the job and be able to use them. No need to start holy wars over them.

Re:Not exactly a good thing (1)

Anonymous Brave Guy (457657) | about 8 years ago | (#16088109)

Damn, where are my mod points?

You're absolutely right. Java and C++ are different tools, with different strengths and weaknesses. Attempting to compare them like-for-like is meaningless, as is making general statments about which language is "better".

If you want to do serious mathematical modelling, for example, you have a pretty limited selection of languages available. Most of them start with "C". Most of the others start with "M" and are written in languages starting with "C".

On the other hand, for CGI, most of the languages I use start with "P". I wouldn't dream of trying to write a database-backed web-page generator in C++, because I could have written the whole thing in Perl or PHP by the time I'd worked out how to link in the right libraries for C++.

Java seems to have found the (rather large) niche of developing back-end, "business" applications (i.e., database apps). Again, I probably wouldn't choose to use C++ there, since Java already has loads of pre-supplied functionality, and perhaps as importantly, a whole community of developers with experience in the field.

As the parent says, it's all about picking the right tool for the job. Most of us have succumbed to language holy wars in the past, and hopefully most of us have since outgrown them.

Re:Not exactly a good thing (2, Informative)

masklinn (823351) | about 8 years ago | (#16087516)

To be fair, Java does have some advantages over C and C++ for application development, and I think that Java has worked wonders in the corporate world.

So do many other languages. The main reason why Java worked wonders in the corporate world is marketting. Basically, Java is a victory of marketting over engineering.

For example, Java has static typing, which helps catch errors at compile time.

Doesn't have near enough to be truely useful, and the explicit typing (lack of type inference) make it extremely verbose and annoying to work with. Much more than statically typed languages with type inference and extremely strong type systems (à la Haskell) for example.

Re:Not exactly a good thing (1)

RAMMS+EIN (578166) | about 8 years ago | (#16087585)

FWIW, I completely agree with you. I just wanted to defend Java for once. ;-)

Re:Not exactly a good thing (0)

Anonymous Coward | about 8 years ago | (#16087529)

- You can't very much blame the state of Azureus on Sun. It was, after all, the Azureus developers who made it the way it is, through language choices and programming practices.

Yes, of course. My point is that the corporate backing behind Java could push relatively new programmers (for example those who never had to play with an accumulator register, or align manually data to even addresses in a M68K asm code, or those who know the difference between C89 and C99 - Ok, now you know I'm 40+ :-) to make a choice without regard of the inner working of their code, its requirements and the weight it will impose on the system or other applications being run on it. The infamous saying "Nobody was ever fired for choosing Microsoft" could be abused here as well.
About Azureus, the point is that almost all if not all its weaknesses are due to the choice of Java as its language of choice. This should ring a bell.

Just to clarify my take on Java. I'm not against it as a language, the 10% I know about it says that it's well designed, powerful and pretty straightforward to learn, but I can't accept being forced to run most software under a vitual machine which makes it slower by orders of magnitude.
Using a JVM because it allows a financial application to be hidden within security layer is also a myth: one could as well hack a Z80 or 6502 emulator to do the same (no networking, no access to local files, no way to bypass the parent calling process permissions, etc. everything is already there) in much much much less cpu cycles.

I can barely understand corporate choices like "being delivered on schedule" or "instead of 2 good programmers it can be done by 10 monkeys, and they still cost us less", but for Open Source and community driven projects Java should never be considered. Let alone that if Sun goes bust (or decides to kill the platform) your project is esentially doomed. Both are very unlikely scenarios, but not impossible.

Re:Not exactly a good thing (1)

LordLucless (582312) | about 8 years ago | (#16087905)

for Open Source and community driven projects Java should never be considered.

Open Source folks will generally write in a language they're familiar with. For a lot of people, that's Java. I agree with you that the JVM is unnecessary complication in most situations, but the language itself is nice, with a large, cohesive, well-documented class library. Purely on a language basis, I prefer Java to C/C++. A lot of the time when I'm developing something for myself, I'm doing it more for the chance to muck around than to get a lean, mean, performing machine. But the Azureus folks probably wanted to fool around and see what they could to with the bittorrent protocol, and because they knew java, that's what they used. In that scenarior, efficiency and performance were never goals, so they were never factored in to the choice of language.

Let alone that if Sun goes bust (or decides to kill the platform) your project is esentially doomed. Both are very unlikely scenarios, but not impossible.

Nah. Even if development on Java was totally halted, existing Java programs would run fine. Even if distribution of Sun's JVM was halted, it's installed on many computers already (and I believe it's licence allows it to be redistributed with your program?). Even if Sun goes belly-up, there's no reason for Java to die.

The way I see things... (2, Interesting)

Anonymous Coward | about 8 years ago | (#16087366)

Ruby (which is slow as molasses) could potentially see a higher speed gain from running on the JVM than Python has (not) seen from being ported to run on the CLR. However, I don't understand the technical advantage of these dynamic languages being ported to runtimes designed to host static languages.


Lua is interesting, it runs on it's own register based VM and LuaJIT does exactly what you think. Lua is only a small language and generally faster than C-ruby and C-python. I don't see anybody rushing to port this to run on the JVM/CLR, is this because the performance and memory use would absolutely suck?

Re:The way I see things... (1)

Viol8 (599362) | about 8 years ago | (#16087414)

"is this because the performance and memory use would absolutely suck?"

No, I suspect its because no one has even heard of it. Theres dozens of
me-too languages out there but until someone starts to use one a lot
and it takes off no one cares. Fact of life I'm afraid.

Re:The way I see things... (3, Informative)

erig (1000750) | about 8 years ago | (#16087434)

Lua is used a lot as an embedded language, especially in games such as World of Warcraft [wikipedia.org] , etc., so I wouldn't say that it's unheard of.

Re:The way I see things... (0)

Anonymous Coward | about 8 years ago | (#16087454)

Lua users [lua.org] , just a list of users and applications people have never heard of like Lucas Arts (Monkey Island, Grim Fandango) and Blizzard (WOW). A little history [lua.org] demonstrated that Lua is not some "me-too" language either. If you're serious about programming, you've used or at least heard of Lua.

Re:The way I see things... (2, Insightful)

masklinn (823351) | about 8 years ago | (#16087530)

I don't see anybody rushing to port this to run on the JVM/CLR, is this because the performance and memory use would absolutely suck?

I think it's because they don't go for the same market. Lua's goal is to be a fast, simple embedded language, to enable easy scripting of your C/C++ applications for example (which is why Lua is used a lot in embedded and games devs).

Python and Ruby are full fledged, self-contained programming languages (even though you can embed them into C/C++ programs, or use C/C++ libs from them). Porting them to the JVM or the CLR gives you all of the platform's power (modules & third party packages) with more dynamic and flexible syntaxes.

Lua is definitely not "unheard of" though.

Re:The way I see things... (1)

jma05 (897351) | about 8 years ago | (#16087632)

> However, I don't understand the technical advantage of these dynamic languages being ported to runtimes designed to host static languages.

The "technical advantage" is the more or less same as implementing them over the more common "C platform".

"It was a little less than a year ago that I first started investigating the Common Language Runtime (CLR). My plan was to do a little work and then write a short pithy article called, "Why .NET is a terrible platform for dynamic languages". My plans changed when I found the CLR to be an excellent target for the highly dynamic Python language. Since then I've spent much of my spare time working on the development of IronPython."

- Jim Hugunin (primary author of IronPython and Jython)

Re:The way I see things... (0)

Anonymous Coward | about 8 years ago | (#16087698)

The "technical advantage" is the more or less same as implementing them over the more common "C platform".

Both the CLR and JVM are written in C, so I guess you're saying there's no advantage at all? Please spare me the dreaded Jim Hugunin quote, it doesn't matter how many times it's copied and pasted into a discussion, it's still only an opinion.

Re:The way I see things... (0)

Anonymous Coward | about 8 years ago | (#16087814)

Nothing becomes faster by adding a VM. Think about it.

Re:The way I see things... (0)

Anonymous Coward | about 8 years ago | (#16087932)

Think about it? You obviously haven't.

good thing, too (2, Funny)

macadamia_harold (947445) | about 8 years ago | (#16087370)

Sun has thrown some corporate weight behind Ruby

Good thing, because that Oswald guy was starting to get on my nerves.

Re:good thing, too (0, Offtopic)

Yuioup (452151) | about 8 years ago | (#16087609)

Too bad I don't have mod points because I that was a funny post.

GPL? (5, Interesting)

giafly (926567) | about 8 years ago | (#16087382)

Currently JRuby is licensed under the GPL [sourceforge.net] .
Given Sun's past criticism [com.com] , I think it's fair to ask whether they have committed to using the GPL for future JRuby releases.

Re:GPL? (1)

Aladrin (926209) | about 8 years ago | (#16087449)

Do they have a choice? If they hired each and every person who has commited even a little code to JRuby under the GPL, then yes... They could force their employees to relicense. If they miss even 1 person, or someone quits and refuses to relicense, then no... They have no choice.

Re:GPL? (0)

Anonymous Coward | about 8 years ago | (#16087525)

If they miss even 1 person, or someone quits and refuses to relicense, then no... They have no choice.

Well, they can always throw away that person's contribution.

Re:GPL? (2, Insightful)

mrjatsun (543322) | about 8 years ago | (#16087493)

OpenOffice is GPL. Different licenses for different products. There isn't one license to rule them all. I don't see why JRuby wouldn't be GPL given Sun's (my employer) past history.

Re:GPL? (1)

LarsWestergren (9033) | about 8 years ago | (#16087579)

Given Sun's past criticism, I think it's fair to ask whether they have committed to using the GPL for future JRuby releases.

Of course they will, they can't change the licence to a less restrictive one. Also you could just have read . [bloglines.com]

Re:GPL? (1)

LarsWestergren (9033) | about 8 years ago | (#16087597)

Bah... I meant:
Also you could just have read TFA, or the FAQs, or the blogs.

Re:GPL? (0)

Anonymous Coward | about 8 years ago | (#16087600)

Except it clearly states on the homepage - "Distributed under a tri-license (CPL/GPL/LGPL)".
http://jruby.codehaus.org/ [codehaus.org]

backing dynamic languages? (1)

haupz (970545) | about 8 years ago | (#16087405)

Can Sun claim to be backing dynamic languages when people like David Ungar are looking for a new employment? http://tech.groups.yahoo.com/group/self-interest/m essage/1943 [yahoo.com]

Maybe they're too "old-school", but hey, those guys created Self!

Re:backing dynamic languages? (0, Offtopic)

ArikTheRed (865776) | about 8 years ago | (#16087756)

Wow... a Self fan. Only on Slashdot.

Re:backing dynamic languages? (1)

haupz (970545) | about 8 years ago | (#16087795)

Not a "Self" fan, a fan of dynamic languages whatsoever. ;-)

Don't get your hopes up.... (0)

Anonymous Coward | about 8 years ago | (#16087486)

Sun did the same thing with TCL years ago by hiring Oosterhoot and his gang. After the inital hoopla, not much became of it, really.

-- ac at home

Re:Don't get your hopes up.... (1)

dwarfking (95773) | about 8 years ago | (#16088019)

Speaking of TCL, why is it that it gets so little attention? With starkits [wiki.tcl.tk] TCL has the ability to simply create a single file executable, that doesn't require a local installation of a heavy VM.

It offers the scripting abilities people seem to want, is fairly easy to learn, has a nice set of available libraries.

Why does it seem to get overlooked? To me the startkit capability puts it head and shoulders above all the other scripted/interpreted languages since for little more than a meg in size I can have, as an example, a complete webserver in a single file that only requires a file copy to install.

Jython -- they need a boost too (2, Informative)

ovapositor (79434) | about 8 years ago | (#16087559)

It would be nice if Sun hired the Jython team as well. :) Consider that they would then have two very popular scripting languages nicely supported under their portfolio.

I just don't think they are taking .NET seriously enough.

It would be interesting (2)

gnufied (942531) | about 8 years ago | (#16087592)

People started speculating , this might be in response of Microsoft throwing weight behind Python, though I am not in that camp....but it would be interesting to see that how these interpreted languages will perform when hijacked by these JIT compilers( or whatever these sun guys tell you about their shiny bytecode stuff.)

I have seen JRuby code and the effort to use Java libraries from Ruby and it was plain scary, I would rather do pure Java. And support for rails is "miles before you and me can do some real code". According to Tom(one of the authors of Jruby):
"It should be stated clearly here, that the JRuby this is running on is not released code yet. In fact, our next release 0.9.0 will not quite be running this application out of the box"
So, we have a tight case there. Besides Matz is also working on Ruby2.0, which will have VM execution kind of stuff. So, though you may celebrate if you want, I would rather like to have C Ruby for my breakfast. There are two major problems of Ruby:
1. Slow (yes its slow and stylish)
2. GUI programming
And guess, what Jruby is not going to bring anything better on the table on these two fronts. With Introduction of IronPython, you can do GUI programming on Windows happily and PyGtk was there as shining example of one of the finest GTK bindings ever produced. Whereas, if you want to do, GUI programming with Ruby, how many REALLY good choices do we have? Though this might be humble opinion, but I have hated GTK for gui stuff, it sucks. Qt and Windows Forms are much better. Java applets suck even more.

Sun has a lot to offer (1)

kahei (466208) | about 8 years ago | (#16088156)


So, we have a tight case there. Besides Matz is also working on Ruby2.0, which will have VM execution kind of stuff. So, though you may celebrate if you want, I would rather like to have C Ruby for my breakfast. There are two major problems of Ruby:
1. Slow (yes its slow and stylish)
2. GUI programming
And guess, what Jruby is not going to bring anything better on the table on these two fronts.


I disagree -- there are more problems with Ruby than just those, and they are things Jruby could fix.

The big problems are:

--Slow: unlikely to be completely fixed by using a JVM, but it would probably help. Matz's VM was going to be ready Real Soon Now in about the year 2000.
--Unicode: The JVM would FINALLY give Ruby the ability to take in text in various languages and just process it in the normal way, rather than messing with individual bytes and having Japanese be a special case.
--Threads: The JVM would FINALLY give Ruby proper threads.

And another problem is:

--Project Management: Involvement from Sun might make for a more efficiently run, less 'hobby like' project.

So, I'd say there's a lot Sun could offer to Ruby. Whether any of it will happen I don't know -- and of course bad Ruby code is a lot worse than bad Java code and I'm not sure if I wouldn't rather people stuck with Java.

Typecast this (0)

Anonymous Coward | about 8 years ago | (#16087648)

One of the arguments for porting a language to the JVM or CLR is that you can use the standard libraries. Would it be possible to go the other way and compile GNU classpath using GCJ and then write generic JLib bindings to dynamic runtimes?

You can go right ahead and flame me now.

.NET already has this (1)

tiedemann (214491) | about 8 years ago | (#16087737)

There seems to be an ongoing effort to make ruby run well on the .NET-framework aswell, check out IronRuby [wilcob.com] or Ruby.NET [qut.edu.au] for further reading. Ruby.NET supposedly runs on Mono [tirania.org] although it requires a few patches.

after letting Jython languish (5, Insightful)

hashmap (613482) | about 8 years ago | (#16087770)

I gots no love for Sun ... after all Jython been out for half a decade, and Sun has shown little to no interest in it ... just imagine how much better it would be if they had the foresight to support it and improve its performance

As far as I'm concenrned Sun is playing catch-up with Microsoft, and this is no more than a half assed response to MS releasing IronPython

Re:after letting Jython languish (1)

LarsWestergren (9033) | about 8 years ago | (#16088125)

I gots no love for Sun ... after all Jython been out for half a decade, and Sun has shown little to no interest in it... just imagine how much better it would be if they had the foresight to support it and improve its performance


They can't support every open source project and everyones favourite language under the sun. From what I have heard development on Jython is picking up again, and it performs quite well. Perhaps Sun thought resources were better spent on improving speed and stability in the core, so they didn't lose the customers they already had.

The fact that they have hired the JRuby developers is not intended as a slight against the other scripting languages either, as Thomas writes in his blog:

1. Does the Sun move mean Groovy, Jython, BeanShell, and friends are being cut out of the picture? Has Sun chosen a winner in the dynamic languages realm?

Absolutely not, on both counts. I got involved in JRuby for one reason: Ruby was underrepresented in the Java world, and happened to be a very attractive language to me. Jython was fairly well-established and performed quite nicely. Groovy was gaining some traction and seeing an upswing in developer interest. JavaScript was scheduled to be included in Java 6. What about Ruby? JRuby didn't run most Ruby apps, had known major incompatibilities with C Ruby, and performance was very poor. Something had to be done.


As far as I'm concenrned Sun is playing catch-up with Microsoft, and this is no more than a half assed response to MS releasing IronPython

That is just ridiculous. As I stated in a previous post, the increased support for dynamic languages on the JVM has been planned since at least 2003. Even hiring these guys have been planned for a long time, how fast do you think the HR department works on a big company like Sun? The fact that Microsoft announced the IronPython support a week ago is just a coincidence.

Re:after letting Jython languish (2, Informative)

RAMMS+EIN (578166) | about 8 years ago | (#16088249)

Absolutely. Sun played the lock-in game by positing Java as the One True Programming language. That worked pretty well, and so they slacked off, not improving the language (although they did a good job at the runtime, but they could have gotten both right in the first place), and not helping better languages target their platform.

Then Microsoft came along and released a Java that was a better Java, on top of a JVM that was a better JVM. On top of that, they actively supported language diversity, encouraged efforts to port popular languages, and changed the VM to accomodate these languages. Soon enough, people were jumping ship; from Java to C#, because it's a better language, and from whatever they had to .NET, because it's a better platform.

Now Sun is playing catch up. They added lots of essential features in Java 5, finally making Java a somewhat useable language. Apparently, they've also gotten the message about supporting multiple languages. And they've been working on opening Java to make it more attractive to those who love software freedom or use platforms that Sun doesn't support.

It will be interesting to see it all play out. At least, I'm glad to see that Sun and Microsoft are having such good influences on one another; Microsoft coming with a very open platform in response to Java, and Sun improving the Java platform tremendously in response to .NET. While they compete, the rest of the world wins.

JSP? (1)

lbmouse (473316) | about 8 years ago | (#16087794)

Does anyone know for sure where/how/why JSP is going to fit in all of this?

Re:JSP? (0)

Anonymous Coward | about 8 years ago | (#16087832)

Wellllll... uh... you can write random scriptlets in Ruby, have them compiled as Java .classes, and call them from JSP? Surely cooler language for writing taglibs than Java itself. Just a guess...

Re:JSP? (1)

vhogemann (797994) | about 8 years ago | (#16087877)

Well,

Not JSP itself, but you'll be able to write your servlets using Ruby. I think that eventually someone will even port ActiveRecord to JRuby, and you'll be able to use RubyOnRails inside your favorite servlet container, such as Tomcat, and have access to the best from both worlds.

You can already use scripting languages, such as Ruby, to write Struts' ActionServlets, just to give you an example.

Re:JSP? (1)

WWWWolf (2428) | about 8 years ago | (#16088027)

eventually someone will even port ActiveRecord to JRuby

I was under the impression ActiveRecord already worked under JRuby? After all, Camping apparently works under JRuby [codehaus.org] and it uses ActiveRecord. The tutorial speaks of something about JDBC.

Okay, so it may not work to really useful extent yet, and I hear Rails definitely won't work yet, but it's probably a start...

Re:JSP? (1)

RAMMS+EIN (578166) | about 8 years ago | (#16088285)

JSP is like embedding Java code in HTML, aye? Well, you have been able to do same with Ruby for a long time; see, for example, erb, eruby, amrita, and kwarts.

Also, note that you can pretty simply get a similar effect using just pure Ruby, by using heredocs and interpolation, e.g.

print ...
#{some_ruby_code here} ...
EOT

Great, now if only... (1)

DavidNWelton (142216) | about 8 years ago | (#16087988)

... if only someone would throw some money my way to work on Hecl (http://www.hecl.org/ [hecl.org] ) :-)

Missing the point (2, Insightful)

metamatic (202216) | about 8 years ago | (#16088192)

Ruby on Rails has got a lot of attention. Many web sites that would have been built using Java are being built using Rails, and people were starting to ask if Ruby on Rails was the new, better Java.

This is an insurance policy for Sun, and a way for them to provide a migration path and say "Oh, OK, you can run your Rails site on our Java platform while you build the next version using J2EE".
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?