Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Sun Backs Ruby by Hiring Main JRuby Developers 211

Posted by ScuttleMonkey from the feel-the-love dept.
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."
This discussion has been archived. No new comments can be posted.

Sun Backs Ruby by Hiring Main JRuby Developers More

Sun Backs Ruby by Hiring Main JRuby Developers

Comments Filter:

  • Great News (Score:5, Interesting)

    by RAMMS+EIN ( 578166 ) on Tuesday September 12, 2006 @05:48AM (#16087330) Homepage Journal
    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: (Score:2)

      by FyRE666 ( 263011 )
      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: (Score:3, Funny)

        by chthon ( 580889 )

        A fast Ruby with a compiler is called Common Lisp.

        • Re: (Score:2)

          by chthon ( 580889 )

          I should have added ;-)

        • Re: (Score:3, Informative)

          by TheRaven64 ( 641858 )
          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: (Score:3, Interesting)

            by arivanov ( 12034 )
            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 c

            • Re: (Score:3, Insightful)

              by recordMyRides ( 995726 )
              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.
            • 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

            • Re: (Score:2)

              by Pike ( 52876 )

              So, how does the not-invented-here syndrome explain why we are now using a language invented in Japan [wikipedia.org]?

              I didn't even know smalltalk was french until I read this.

          • Re: (Score:3, Interesting)

            by masklinn ( 823351 )

            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

            • Re: (Score:2)

              by plopez ( 54068 )
              Ruby also has quite a lot of Perlish roots, which make it a quite "practical" language.

              I think you hit the nail on the head there, being a Perl hack (second class only) I like Ruby because I found it easy to tranlate over and I can do the crazy wierd Perl-like stuff that I cannot do in C# or Java (or have to jump through a lot of hoops to do).
              All the while it is better in object orientation and they did clean a few things up as well.

              Ruby is becoming my new Perl. I predict more Perl hacks will cut over as we

      • Re:Great News (Score:5, Interesting)

        by Per Wigren ( 5315 ) on Tuesday September 12, 2006 @06:25AM (#16087401) Homepage
        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 (Score:4, Insightful)

          by LarsWestergren ( 9033 ) on Tuesday September 12, 2006 @08:42AM (#16087818) Homepage Journal
          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".
        • Are you sure about all that? I have not heard any plans for YARV to have a JIT, and I have heard no indication that it will approach the speed of Java. I have tried it out, and seen speedups of about 2-3x, but this is far short of being competetive with Java.

          Understand that I am a huge Ruby supporter, which is why I don't want to see unrealistic expectations about YARV that don't deliver, thus tarnishing Ruby's reputation.
          • From the TODO-list [atdot.net]:
            Optimize
              * JIT Compile (current: experimental)
              * AOT Compile (current: experimental)

            If you search the mailing lists you will find results of experiments by Sasada showing VERY fast execution on examples using code the JIT compiler supports so far.

        • There are advantages to having a common JIT engine, though.

          I've been sitting on the sidelines, watching all of this, wishing desperately for a clear winner. I'm looking for:

          • Bytecode. I don't want to have to compile separately for every platform I'd support, but I want to be able to go proprietary.
          • Fast. Faster-than-C if possible. I'll accept some performance loss, but not too much. Ahead-of-time compilation is a huge plus -- I have seen Java apps take forever to start, and I don't want my program to

          • Re: (Score:2)

            by vsync64 ( 155958 )

            Scheme/Lisp/Erlang/others. Every one of these I've looked at has one fatal flaw: It's not JIT'ed, or compiled. Erlang can be compiled, but then you lose one killer feature: even if they're just bytecode-compiled, compiled functions cannot be replaced at runtime, the way other Erlang functions can.

            Common Lisp compilers:

            • CMUCL [cons.org]
            • SBCL [sourceforge.net]
            • ABCL [armedbear.org] (compiles to Java bytecode)
            • CLISP [cons.org] (compiles to bytecode)

            I know that in all of these you can replace a compiled function at runtime with another compiled function,

            • I'm even more amused by LISP's parentheses, but I can live with them. I think of Ruby as exciting not because it's new, but because it's most of what I like about LISP without the ugliness. I mentioned Scheme because I seemed to remember it having a bytecode engine.

              But the real problem seems to be the same problem as with everyone's pet language. In theory, LISP could do everything I want, but I can't find a single implementation of LISP or Smalltalk that does it. Well, that's not true -- I can find on

        • Well, I call bs on YARV ruby vm being "about as fast as Java and .NET in most situations". I benchmarked Java vs C vs Smalltalk, and the results were basically:

          GCC: 1
          Java: 0.8-2, sometimes upto 4
          Smalltalk: 4-20, sometimes upto 80

          This was against highly optimized cincom smalltalk, the fastest around at the time, and even on OO tests like method dispatch. And Ruby has all the same issues as smalltalk (dynamic dispatch, boundless integers, blocks/closures, etc).

          Ruby, Python, Perl, Smalltalk, etc sometimes te

        • Re: (Score:2)

          by misleb ( 129952 )
          My own benchmarks of YARV for some particularly slow real world tasks such as referencing items in a hash show only a modest performance boost. For example, I am trying to read 35,000 records from an SQLite database into a Ruby Array and it takes 23 seconds. The query itself only takes 1 second, but iterating over the records from SQLite is what takes so much time. I've profiled it and everything. It is definitly the iteration over the ResultSet that is the problem. Using the latest YARV from SVN only gets
      • ``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.

        • 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.

      • 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.

    • 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 unders

      • ``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 sp
        • 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: (Score:3, Informative)

      by LarsWestergren ( 9033 )
      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]
      • ``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 co
        • 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.

    • 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.

    • Re: (Score:3, Informative)

      by vhogemann ( 797994 )

      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 d

    • "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: (Score:3, Interesting)

        by RAMMS+EIN ( 578166 )
        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 t
    • 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.

      I actually find this to be the most promising aspect of this announcment. Not really surprising, considering the marketing speak M$ has been going thru lately regarding improving the CLR for dynamic languages, and what's happening with Iron Python (on .NET). I'm glad to see both of the main VM-based languages out there pushing towards a friendly environment for dynamic

  • Support for Dynamic languages (Score:5, Insightful)

    by EqualSlash ( 690076 ) on Tuesday September 12, 2006 @05:55AM (#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 (Score:5, Insightful)

      by TheRaven64 ( 641858 ) on Tuesday September 12, 2006 @06:26AM (#16087402) Journal
      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: (Score:3, Insightful)

        by egghat ( 73643 )
        This is a *good* PR move.

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

        Bye egghat.
    • 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: (Score:2)

      by killjoe ( 766577 )
      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.

  • The way I see things... (Score:2, Interesting)

    by Anonymous Coward
    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 t

    • Re: (Score:2)

      by Viol8 ( 599362 )
      "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: (Score:3, Informative)

        by erig ( 1000750 )
        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: (Score:3, Insightful)

      by masklinn ( 823351 )

      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

    • Re: (Score:2)

      by jma05 ( 897351 )
      > 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

  • good thing, too (Score:3, Funny)

    by macadamia_harold ( 947445 ) on Tuesday September 12, 2006 @06:10AM (#16087370) Homepage
    Sun has thrown some corporate weight behind Ruby

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

  • GPL? (Score:5, Interesting)

    by giafly ( 926567 ) on Tuesday September 12, 2006 @06:16AM (#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: (Score:2)

      by Aladrin ( 926209 )
      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: (Score:2, Insightful)

      by mrjatsun ( 543322 )
      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.
    • 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: (Score:2, Informative)

      by olabini ( 1002032 )
      This is just not true. GPL is one of three licenses for JRuby, which is easy to find on the front page for the project. A direct quote: "Distributed under a tri-license (CPL/GPL/LGPL)" But anyway, as other people have posted, JRuby will continue, with it's own community, just with the support of employment for the two main guys.

  • Jython -- they need a boost too (Score:3, Informative)

    by ovapositor ( 79434 ) on Tuesday September 12, 2006 @07:25AM (#16087559) Journal
    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.

  • 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

    • 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

  • after letting Jython languish (Score:5, Insightful)

    by hashmap ( 613482 ) on Tuesday September 12, 2006 @08:30AM (#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

    • 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

    • Re: (Score:3, Informative)

      by RAMMS+EIN ( 578166 )
      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
  • Does anyone know for sure where/how/why JSP is going to fit in all of this?
    • 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.
    • 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
      • Right, so the HTML in the example that I gave went missing, of course. Oh well, I'll blame it on Slashdot's "Plain Old Text" not actually handling plain old text. I guess if you view the page source you can get the example, but the idea is that you can put Ruby code in #{...} inside whatever you have, and it will be executed and whatever it returns converted to a string and inserted in the whatever you have. Works not just for HTML, but for anything you use it with.
  • ... if only someone would throw some money my way to work on Hecl (http://www.hecl.org/ [hecl.org]) :-)

  • Missing the point (Score:3, Insightful)

    by metamatic ( 202216 ) on Tuesday September 12, 2006 @10:01AM (#16088192) Homepage Journal
    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".
  • So, the creator of a proprietary platform acquires key developers of open source add-on for that platform. This likely means that Sun will add more Sun Java-specific features to JRuby and that JRuby will not work on IKVM or Classpath in the future.

    I wonder whether Sun tried acquiring Jython first and was turned away...
    • I would mod you troll if I had mod poits...

      Java is an OPEN platform, based on well established standarts that are made public, royality-free. Everyone is free to make their own implementation of the JavaVM, this commitment to open standarts made efforts like IKVM, Kaffe, Classpath and ohters possible on the first place.

      Also, every bit of the Sun's Java implementation sources are avaliable. And every future modification on the Java standart is made public avaliable way before its deployed, including a refere
  • Sorry to play the cynic, but you have to ask how long this goodwill will last. Sun has a layoff announcement every 6 months it seems. "Non-core" business units are shut down at every turn.

    I love Sun, and I think it's great that they're doing this. I hope they prove me wrong.

  • instead of speculating? Here's Tim Bray's blog post about hiring them here [tbray.org] and a follow up here [tbray.org].

    from Tim's blog:

    Why is Sun hiring JRuby developers Charles Nutter and Thomas Enebo? First, they are excellent developers. Technologies like Ruby are getting intense interest from the developer community, and Sun is interested in anything that developers care about.

    What will their new role be at Sun? First, they have to get JRuby to 1.0 and make sure that the major applications are running smoothly and a

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close