Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror

Will Sun Open Source Java? 700

Posted by samzenpus
from the free-coffee dept.
capt turnpike writes "According to eWEEK.com, there's an internal debate going on at Sun whether to open-source Java. (Insert typical response: "It's about time!") Company spokespersons have no official comment, as might be expected, but perhaps we could hear confirmation or denial as early as May 16, at the JavaOne conference. One commentator said, "Sun should endorse PHP and go one step forward and make sure the 'P' languages run great on the JVM [Java virtual machine] by open-sourcing Java." Would this move Java up the desirability scale in your eyes? Could this be a way to help improve what's lacking in Java?"
This discussion has been archived. No new comments can be posted.

Will Sun Open Source Java?

Comments Filter:
  • too little too late (Score:2, Informative)

    by mycall (802802) on Monday May 01, 2006 @10:13PM (#15242664)
    Phalanger [php-compiler.net] is going to support Mono in their next release, which already support IKVM.
  • Re:This would help (Score:1, Informative)

    by aliquis (678370) <dospam@gmail.com> on Monday May 01, 2006 @10:24PM (#15242707) Homepage
    1) Yeah, it's really so hard to download Java, I mean, where do I start? http://www.microsoft.com/java [microsoft.com] maybe? oh fuck, it worked. http://www.java.com/ [java.com] maybe? Oh shit, it did. Hey, even http://java.sun.com/ [sun.com] worked, what is this?

    2) Says who? It is a virtual machine afterall, and if you run more Java apps all of them won't use as much memory as the first one did. Also memory are cheap and who cares. It's a good and safe language and you probably ends up with less bugs.

    It is very reasonable to run Java in Linux. It's harder/more painful/whatever in the BSDs but it works.
  • by SoloFlyer2 (872483) on Monday May 01, 2006 @10:26PM (#15242716)
    I currently avoid Java like the plauge, my reasons are the same reasons that java isnt included in debian... http://www.debian.org/doc/manuals/debian-java-faq/ ch5.html#s-license-concerns [debian.org] if they address those license concers i would be much happier...
  • Re:This would help (Score:2, Informative)

    by pebs (654334) on Monday May 01, 2006 @10:43PM (#15242803) Homepage
    It is very reasonable to run Java in Linux. It's harder/more painful/whatever in the BSDs but it works.

    FreeBSD now includes Sun Java [freebsd.org] as part of the distro, so it should be easy. Any Linux/BSD/etc distro can do this, it just requires spending the money to get it certified.
  • Re:Third-Party JVM (Score:5, Informative)

    by IntlHarvester (11985) on Monday May 01, 2006 @10:49PM (#15242831) Journal
    Microsoft's JVM was actually one of the fastest in the day and had extentions for a native GUI similar to eclipse. (Of course those extentions relied on illegal JVM tricks.) It was certainly much better than Netscape Java or early releases of Sun Java.

    The main reason Java has a terrible reputation (IMO) is/was it's tendancy to hang/lockup/freeze your browser when an applet loads, and general clunkyness with Swing.
  • Re:Alternate VMs (Score:3, Informative)

    by ghakko (261165) on Monday May 01, 2006 @10:55PM (#15242869)
    gcj (the GNU Java compiler) allows Java programs and bytecode to be compiled into native code. It can even generate statically-linked executables which do not require a runtime. These executables tend to start up much more quickly.

    Sun, on the other hand, does not allow anything of the sort with their own Java stack and has held off on open-sourcing because it sees its Java runtime environment as a beachhead through which it can colonize your system (especially on Windows, where it comes bundled with all sorts of seemingly-unrelated stuff, like browser toolbars). Allowing third parties to ship stand-alone executables would undermine this.

    This is probably to the long-term detriment of the Java platform because the runtime environment is now large and unwieldy enough to really complicate app deployment.

    I believe Sun intentionally obfuscates the issue by pointing out that native code is not portable, is somewhat more fragile (because it is not insulated from system dependencies by a VM) and does not necessarily perform better than bytecode in a VM with an aggressive JIT. All these are true, but is besides the point.
  • Re:Yes (Score:1, Informative)

    by Anonymous Coward on Monday May 01, 2006 @11:05PM (#15242923)
    Yes, change "Write once debug anywhere" to "Write once, run anywhere"

    Java already has the best "Write Once, Run Anywhere" technology on the market today. Programs that fail to be portable are usually due to:

    1. Idiot programmers who can't figure out that "c:\\My Files\\data.txt" is not portable across Operating Systems.

    2. Hardware inconsistencies that screw up many more programs than just Java. Hyperthreading is the worst offender, but general SMP can wreak all kinds of havoc on unsuspecting code.
  • Re:This would help (Score:5, Informative)

    by WebMink (258041) <slashdot AT webmink DOT net> on Monday May 01, 2006 @11:05PM (#15242928) Homepage
    it just requires spending the money to get it certified.

    Actually, FreeBSD were given a license at no cost by Sun, and any not-for-profit organisation with a need for access to a Sun-maintained compliance test kit can get it at no charge [sun.com]. So it's really just a matter of having the motivation to ask.

  • Who cares? (Score:3, Informative)

    by jmorris42 (1458) * <jmorris@NOSpAM.beau.org> on Monday May 01, 2006 @11:19PM (#15242984)
    Really. At this point, who cares? If they did it at this late date it would speed up the process by a year or so at the cost of keeping Sun in the driver's seat. If they don't open their implementation GCJ will catch in a year or so and it will quickly become the reference implementation that everyone will track in server environments.

    Why do I say that? Because it is the one all non-Sun/Microsoft server environments (meaning Linux & *BSD) will be shipping. RedHat is already there. If you want a different Java you have to deal with the implications of having it co-exist with GCJ. Although they do use alternatives to make that managable, they ship the IBM JDK on their extras CD, not Sun's and the Sun packages almost certainly (haven't bothered to check a recent vintage) don't deal with that, their 'rpms' are brain damaged tarballs wrapped in a thin rpm wrapper.

    So it no longer matters what Sun does. Five years ago they could have turned around the fortunes of Java when it was under serious threats. Ten years ago OPening Java would have meant we wouldn't be dealing with .NET today. But that is history that could have been and wasn't, now Sun needs to just continue to quietly fade away.
  • Re:Open Java (Score:5, Informative)

    by WebMink (258041) <slashdot AT webmink DOT net> on Monday May 01, 2006 @11:38PM (#15243073) Homepage
    Otherwise why would Apache have the Harmony project to recreate J2SE?

    Kaffe and GNU/Classpath are excellent, active projects with dedicated developers. Notably, GNU/Classpath has recently passed the 99% code coverage mark measured against the Java SE specification. Apache Harmony was started because Apache won't use code licensed under the GPL, not because of any technical defect in the work of the Kaffe and GNU/Classpath developers. Harmony is also making excellent progress and has a skilled and active community. Both are committed to making compatible implementations of Java, but licensed under the licenses their communities need.

  • Mustang changes this (Score:5, Informative)

    by ashpool7 (18172) on Monday May 01, 2006 @11:43PM (#15243099) Homepage Journal
    The SCSL is going away in Java 1.6 in favor of some much more liberal licenses. I'll be able to compile and use it on my production FreeBSD server at work and not worry about being "tainted" as a programmer.

    http://www.internetnews.com/dev-news/article.php/3 437481 [internetnews.com]
  • Amazon is not LAMP (Score:5, Informative)

    by XaXXon (202882) <xaxxon@ELIOTgmail.com minus poet> on Monday May 01, 2006 @11:50PM (#15243125) Homepage
    Yared has long called for Sun to open Java, which, he said, is "great on the back end, but LAMP is great on the Web tier, as Google, Amazon, Yahoo, Flickr, MySpace and Friendster have shown.

    Amazon is not LAMP.
  • Re:Overlords (Score:4, Informative)

    by WebMink (258041) <slashdot AT webmink DOT net> on Monday May 01, 2006 @11:55PM (#15243136) Homepage

    As the two ACs who have been modded out of view said, that particular drug already exists - Jython [jython.org] - and is already supported in Java IDEs like NetBeans (via Coyote [java.net]) and Eclipse. It's been interesting to see all the old urban myths about the Java platform being slow, bloated, single language and so on doing the rounds again though, I'd almost forgotten about them...

  • by eegreg (970843) on Tuesday May 02, 2006 @12:14AM (#15243210)
    The P's and R (Ruby) are ran by an interpreter, which essentially interprets the text into machine language. Java programs are first compiled into bytecode that is then interpreted by their JVM. This compilation step gives a big performance increase, and is the biggest reason why Java is faster than P's and R. If you could compile P's and R into Java bytecode, you could run the finished product on the JVM with great performance increases. Or you can get the benefit of mixing and matching the different languages (mostly you could use Java's libraires with P's and R). I know there is a Ruby project (JRuby) which is actually already has the ability to do this for most of Ruby's code, although it has not been optimized yet, so right now it is more a way to program in Ruby with Java libraries than a way to speed up a Ruby program.
  • Re:Open Java (Score:4, Informative)

    by pchan- (118053) on Tuesday May 02, 2006 @12:16AM (#15243217) Journal
    I'm saying there is no time to lose. Newton is gone, Palm has hit the wall ... .NET mobile will be the only binary compatible handheld platform unless Sun act now.

    As an embedded systems developer who has recently been dealing with Windows CE, let me tell you that Microsoft is pushing .NET for embedded devices, and they're pushing it *hard*. The first words out of the mouth of every new MS guy I meet are "are you using managed code?". Every single presentation I've seen, block diagrams, feature lists, tools descriptions, every one has a block dedicated to managed code, c-sharp, and the portable dotnet framework right next to native code. It's pretty obvious that there was a directive from high on up of what to do and how to do it (I've never seen Microsoft so organized about something before). On the desktop side, they expect to kill Java by pushing out the dotnet framework with the next version of Windows, so things are currently pretty relaxed. On the server side, they are working on strong integration into all of their server products and all of their development tools (vb and asp replaced by dotnet versions). On the embedded side, they are pushing dotnet like it's the cure for every development issue ever.

    The Java market is fragmenting. All these groups are taking it in different directions. The Apache people are re-implementing it, the GNU people won't deal with Sun Java, distribution is a mess. Microsoft offers a consistant product, a consistant platform, and a hard sell. Java is losing ground on the server side. On the embedded side, Microsoft is determined to "fucking kill [java]", and they're not resting. It's not all doom and gloom, Java will be around for a while. But it wouldn't hurt if Sun got off their asses and removed the obstacles in the way of their allies in the war against dotnet.
  • Re:No (Score:1, Informative)

    by Anonymous Coward on Tuesday May 02, 2006 @12:19AM (#15243227)
    If someone wants to fix a specific bug (for example, in dependency tracking) they can download the source code of Java, fix the bug, and submit a patch. Sun doesn't promise they'll apply the patch, but if you have an improvement to Java I can't see why they'd turn it down.

    There's no reason the license for Java needs to change if all you want to do is fix specific flaws in the current implementation. The only reason Java would need a more open license is to allow people to copy, modify, and redistribute the JVM (or the SDK tools).
  • by synthespian (563437) on Tuesday May 02, 2006 @12:40AM (#15243295)
    SML with MLton (optimizing compiler) fares better than Ocaml, according to this:

    http://shootout.alioth.debian.org/gp4/ml.php [debian.org]
    http://shootout.alioth.debian.org/gp4/ocaml.php [debian.org]

    Two SML implementations are SML/NJ, MoscowML.
  • Re:Third-Party JVM (Score:5, Informative)

    by Call Me Black Cloud (616282) on Tuesday May 02, 2006 @12:50AM (#15243332)
    People must be tired to mod you up. Performance isn't really an issue anymore and hasn't been for a couple of years. Blaming any perceived slowness on Swing is like saying C++ is slow because of Windows overhead. Most Java code doesn't make use of Swing (think server-side). As for the "122 ms", well, you just made that up.

    Other problems with your post: Eclipse is an application; Swing is a language feature. A Smalltalk derivative (Squeak) is not a suitable replacement for Java. I'd go so far as to say Ruby and Python aren't either, though both are very powerful and are better suited to some tasks than Java.

    Nice try at a troll...subtly nonsensical.
  • Re:This would help (Score:5, Informative)

    by icebattle (638355) on Tuesday May 02, 2006 @12:51AM (#15243336)
    "1. Restrictive licenses make it more difficult to reasonably deploy than any competing technology in a linux environment."

    Pretty meaningless comment, unless you can supply some examples. I've done consulting and development for a number of large, lawyer heavy organizations, and none of them had a problem deploying Java solutions on linux. None.

    "2. JVM is fat fat fat, it uses way more RAM than is reasonable."

    Sadly uninformed, probably due to severe lack of experience with large applications. Per example, a couple of years ago I worked in a team that bid on and developed an application that, in a nutshell, receives up to 20Megs per sec of market data, breaks it up into itty-bitty messages, and then makes it available to any number of subscribing clients. Call it a proxy, if you will. We developed the app in pure Java, using the new NIO functionality. We competed with another team who started out in C, moved to C++ midway through, and were barely in a position to go alplha when we were ready to deploy. The client, since they were paying and had a lot of anti-Java staff, insisted on waiting, even though the delivery date had long since passed. When they finally had something to show, the apps were launched on identical hardware, and allowed to run 24/7. Our app ran smoothly, uninterrupted (except for a blown network interface) for the duration of the test. The other team had to restart their app several times a day, resulting in unnacceptable outages. Their restart time was, likewise, poor. Their app required 2Gigs to run. Ours ran happily under a Gig.

    The client paid both teams for their efforts, then licensed our solution.

    So, my quesion then is, where's the fat?

  • by dodobh (65811) on Tuesday May 02, 2006 @01:04AM (#15243383) Homepage
    Better languages than the PHP disaster? Perl, Python, Ruby. They work _very_ well.
  • Re:No (Score:3, Informative)

    by el_womble (779715) on Tuesday May 02, 2006 @01:11AM (#15243396) Homepage
    But that brings in the biggest problem with Java, when to use it. I completely agree with you that Java, for small apps, is a nightmare. Compare getting a single JSP running under Tomcat 5.0 to getting an rhtml page running in Ruby on Rails, or a PHP page with mod_php.

    The problem is worse with medium scale apps because Java offers something most frameworks don't: choice. Do you use Spring, Hibernate, JSF/EJB3, JSP/EJB2, Struts or a mixture of all of the above (shudder). Thats one man month gone already and you haven't even written a prototype. This makes finding your team hard too, as even if you are Sun Certified, each framework is a language in itself with its own quirks and thats before you get inhouse arguments over which patterns you are going to use and where. Thats before we even start to talk about writing the same code three times (interface(s), bean, XML)

    I think Java has lost the small to medium enterprise battle, but then it never really wanted to win those battles. XDoclet and hibernate take some of the hardwork out of Java programming, but the battle isn't with the frameworks so much as the language itself. Compared to C/C++ Java might look light, but compared to Ruby/Python/PHP its nightmare of repitition and bordom. Arguments about speed of execution are as relevent with Java/Ruby(et al) as they were with Java/C and C/Assembler. Thats not to say that Java isn't faster than modern scripting languages (although just as in Java vs. C that is debateable), its just that the time to support and build a scripting language is so much less that the additional hardware is cheap in comparision.

    If you find yourself writting a Java webapp for a project whose volumetrics don't mean that you need to be running on at least 3 Sun Servers (or equivalent), then you're almost certainly using the wrong tool, and even if you are the chances are that Ruby on Rails is still probably worth a look.
  • by I'm Don Giovanni (598558) on Tuesday May 02, 2006 @01:22AM (#15243423)
    Actually, MySpace switched from Cold Fusion to ASP.NET 2.0 and IIS 6.
    Here is a blog by a Microsoft ASP.NET dev describing the details (it's an interesting read):
    http://weblogs.asp.net/scottgu/archive/2006/03/25/ 441074.aspx [asp.net]

    Note that some parts of MySpace still use .cfm extensions, but those are mapped to ASP.NET as well:
    "Some parts of the site like Browse are all .aspx extensions. As Jeff mentioned above, other parts of the site still have a .cfm extension, some of which is mapped to BlueDragon.Net -- which is an ASP.NET IHttpHandler that parses and can run ColdFusion syntax (but which is still running on ASP.NET). The backend cache servers are also all ASP.NET based."


    And just to add more proof (since I know that most here will be skeptical ;-)), here's an entry to the above cited blog from MySpace developer "Chris":
    "Hi everyone,
    I work on the MySpace C# codebase...
    To clarify, we wrote a custom configuration section that maps "fuseaction" URL parameters to ASPX extensions so that we'd maintain link integrity. The only place we aren't doing this is 'Browse' and certain other new features. Meanwhile, as Scott said the parts of the site that are running in ColdFusion are essentially doing so in ASP.NET 2.0 (via BlueDragon).
    Thanks for the mention, Scott. It's been an exciting time putting this together and I can't imagine pulling this off on another platform.
    Chris"
  • by subStance (618153) on Tuesday May 02, 2006 @01:52AM (#15243500) Homepage
    I run a dual English/Japanese Fedora AMD64 and x86 win32 system, and have never had any troubles with java and language input or display on any of them. Especially with Eclipse which I use probably 5-10 hours of every day. SCIM-Anthy is great, it very quickly learned and suggested the most commonly used kanji versions too, as windows does.

    I call bullshit - just because you don't know how to set up your machine properly doesn't mean java has language problems.
  • Re:This would help (Score:3, Informative)

    by asserted (818761) on Tuesday May 02, 2006 @01:57AM (#15243523)
    Apparently not so.

    Quoting Deb Goodkin of FreeBSD Foundation (from here [ittoolbox.com]):

    We spent close to $35,000 for this release. It is hard to estimate the future costs of maintaining the Java releases since we expect to build updated distributions in response to all security advisories released by Sun.

    So, while the license itself might have been given gratis, this clearly shows that the process of obtaining it was cumbersome and costly, and the result is still a limited, version-dependent, binary-only distribution.
    Yes, Java is still evil. Changing license for something more liberal would certainly help much with adoption here.

  • by ufoot (600287) on Tuesday May 02, 2006 @02:00AM (#15243533) Homepage
    > So what exactly is the problem?

    The problem, exactly, is that SUN only implements its JDK on the platforms it judges as "interesting enough". Running a non-mainstream OS on some non-i386 hardware will always end up with you unable to run any SUN JDK -> simply doesn't exist. Well, Blackdown can help and hacking and going all sort of self-punishment you might end up in getting it to work, but well, compare the number of platforms GCC or Perl [perl.com] run on, and compare the number of platforms supported by SUN JAVA, and well, you'll see that SUN JAVA's portability is purely theorical. Now the usual answer "but nobody does this!". Some vendors, and SUN is no exception, are very smart at knowing what people want, without even asking them. Should you want to do something they didn't plan, you cease to exist.

    Now it's perfectly true people have the specs, people are free to implement. Look at the efforts made by GCJ [gnu.org] and Classpath [gnu.org] and you'll see that even with many talented developpers involved, it's hard to catch up with SUN.

    What could SUN benefit? Obviously, get many free software developpers to get interested in Java at all. Many software developped in C++ could have gone the Java way, if there had been a way to run Java programs freely, using the *latest* JDK. For now, people have to beg SUN (and possibly IBM) to port the JDK to this or that platform to get a chance to run their Java 1.5 program on *any* platform. Not to mention the fact that some people care about freedom and the right to know what they are running on their computers...

    IMHO, SUN will publish Java under a Free (as in freedom) and/or Open Source licence the day the concurrent implementations (GCJ,Kaffe,Classpath...) will catch up. On that day SUN's JVM will have absolutely no added value but the stamp "this is SUN software" (which is what counts more for many). Think of Motif, it got free the day GTK and Qt/KDE where ahead of it. Same for OpenSolaris [opensolaris.org] which comes at a time the Linux kernel is pretty advanced in term of features and is obviously (even if not technically fully equivalent) taking significant market shares so that, well, Solaris is dead.

    Sun will "Open Source" Java the day it's dead, because another "Open Source" project took the lead. So if SUN ever publishes a free software JDK, you could interpret this as a signal that means something like "GCJ+Classpath is ready for production use".

  • by alanlewis0 (251219) <(alanlewis) (at) (gmail.com)> on Tuesday May 02, 2006 @02:14AM (#15243568) Homepage
    MySpace is not LAMP either - they run a Microsoft stack and rely heavily on SQL Server. They spoke at the Microsoft MIX conference and were very complimentary of Microsoft. Check your facts, dude.
  • Re:This would help (Score:4, Informative)

    by LarsWestergren (9033) on Tuesday May 02, 2006 @02:20AM (#15243586) Homepage Journal
    2. JVM is fat fat fat, it uses way more RAM than is reasonable.

    1) You do know that tools such as top and ps report a lot more memory than is really used? This has been adressed in the upcoming Java 6, which will more accurately report the memory used, you will likely see a decrease of 25-55% [java.net] reported memory use on Linux/Unix, and at least 11% of real memory used.
    2) You can use jvm startup parameters to limit memory usage and still get acceptable performance [rifers.org].
  • Re:This would help (Score:4, Informative)

    by IDontLinkMondays (923350) on Tuesday May 02, 2006 @02:38AM (#15243631)
    Can't speak on the licensing, I'd say that the technology itself however is the complication in deployment. Java has a tremendous number of rough edges and that is was is the problem.

    Now, before I take a moment to rag on your ridiculous RAM comment, let me assure you that I hate Java from that ground up. I find it to be little more than a virus.

    JVM is thin thin thin. The fact is that most non-Sun implementations of the JVM are tight and small. In fact, from a performance perspective, Java is typically superior to compiled languages because of how it handles RAM. Before you blow me off, let me justify my comment. Thanks to the Java license and NDA agreements, I in fact can not say where I learned this information, but I have extensive experience in this topic since I was forced for extended periods to suffer the Java VM on embedded devices.

    Java is a relatively simplistic (though strangley complete to the point of OVER KILL!!!) architecture/language/etc... It provides a language matched to a virtual machine matched to a set of somewhat poorly written libraries.

    What makes Java superior to compiled languages is that it compensates for several key factors. First I'll refine my definition of a compiled language to clearly specify C/C++/Pascal/other non-garbage collected languages.

    1) Application Developers are not System Developers
    Using C++ as an example, most application developers use the standard implementation of new and delete. This is fine, but the first thing to keep in mind is that memory allocation for a C++ application that makes use of a lot of small objects tend to pay a huge performance price. C developers regularly shoot down the performance of C++ without realizing that it's the limitation in the C allocation routines.

    Object oriented programming is typically very heap intensive. In many cases, developers insist on iterating through strings and lists far too much. Students are even taught in the university that data structures should be used absolutely everywhere. Of course they are taught Big-O and Little-O, but unless you're actually implementing the data structure classes and types, very little importance is placed on performance of these classes.

    Strings are abused regularly since even though the allocation unit size of the heap allocator is limited to blocks of 16 bytes (for example), programmers will actually reallocate the buffer for a string to resize it from 8 to 9 bytes in length. By reallocating, I mean they will in fact allocate a new 9 byte string, then copy the original to the new buffer and delete the original buffer.

    Application developers pay very little attention to the actual internal mechanics of the classes and functions which they use. To a certain extent, I can forgive them since an application developer is expected to think differently than a system developer. When we depend on system developers to write applications, they're often extremely fast, but relatively unusable.

    So here's where Java shines, because of the garbage collection system and because of the relocatable memory architecture, memory is managed in such a way which decreases the cycles spent in allocation and deallocation of buffers. A well written JVM actually will actually either when necessary or when time is available compress the heap to maximize performance and minimize heap consumption.

    So although Java seems like a memory hog, it's actually not that bad given the number of allocations and deallocations being performed by the developers. Sadly, the extreme memory use you're talking about is related to the poor system level development skills of application developers stacked on the additional layer which abstracts even more from the developer therefore making it less practical for the developer to understand the internals of the system.

    2) System Developers make Terrible Applications
    A system developer is typically biased towards raw high level languages such as C (not C++) because their used to making use of the stack whereever po
  • Re:Open Java (Score:2, Informative)

    by david.gilbert (605443) on Tuesday May 02, 2006 @04:10AM (#15243840)
    Here are some activity stats for GNU Classpath:

    http://www.object-refinery.com/classpath/statcvs/ [object-refinery.com]

    Progress, over the last two years in particular, has been astonishing.

  • by popeyethesailor (325796) on Tuesday May 02, 2006 @04:50AM (#15243932)
    don't ever expect .NET to be so don't bother discussing it(The wonderful Mono efforts aside)

    That's sad really, I wonder on what standards [mono-project.com] those "wonderful Mono efforts" are based on ? Yeah. There'll never be a open standard [ecma-international.org] for .NET, never bother about open source [dotgnu.org] implementations [mono-project.com].

  • Re:Alternate VMs (Score:3, Informative)

    by penguin-collective (932038) on Tuesday May 02, 2006 @05:32AM (#15244001)
    Of course, you can write efficient code in Java if you're more careful than in other languages and don't use their library for anything that is performance critical. But that kind of defeats the purpose of using Java in the first place.
  • Re:Bad idea (Score:4, Informative)

    by killjoe (766577) on Tuesday May 02, 2006 @05:46AM (#15244025)
    "very much see the merit of keeping it closed. I agree that keeping it closed does prevent forking, which would be a bad thing for Java (it's a bad thing for most software projects). I merely suggest that the benefits of opening it will outweight the risks. "

    Microsoft already forked java and called it C#. Now C# is evolving faster then Java and is making serious inroads into the java development market. Furthermore there are at least two open source implementations of java. So there are three forks right there.

    Being closed source has not prevented anybody from forking java. Whats more being open sourced has not caused python, ruby, php, perl, ocaml, or haskell to fork.

    I don't know where people get this meme from really. It makes no sense at all.
  • by mrtrumbe (412155) on Tuesday May 02, 2006 @07:20AM (#15244289) Homepage
    I can't help but notice that the vast majority of comments here seem to be focused on website development. What is this? 1998?

    Seriously, though, there are other problem domains out there. A lot of them, in fact. And even in web development, depending on the complexity and context of the solution, might require vast amounts of code that never interact with a GUI of any kind. When you evaluate these languages and platforms in context's outside of web development, Java starts to look far more robust and flexible.

    As another poster pointed out, where are the buffered readers for ruby/php? Sure File.open("name") might LOOK nice, but Java's addition of a buffer solves a common problem many programmers in the past needed to solve by hand. There are about a thousand of these examples where Java's framework is more complex than its ruby/php counterpart, but for good reason: it adds much needed functionality for the enterprise developer.

    Taft

  • by Haeleth (414428) on Tuesday May 02, 2006 @07:30AM (#15244337) Journal
    In order to be allowed to use the trademarked term "Open Source" however, whatever license they choose must (a) comply with the Open Source Definition, and (b) be approved by the Open Source Initiative.

    Did you even read the pages you were linking to? The Open Source Initiative's own certification page, that you linked to, has this to say, right in the first paragraph: "the term 'open source' itself [...] can't be protected as a trademark".

    I can call anything I like Open Source, and nobody can do a thing to stop me. The new Evil Proprietary License (a viral license that infects any software in the same room with a deadly curse that can only be lifted by the sacrifice of your firstborn) could be called Open Source. What it couldn't legally be called is OSI Certified(tm).
  • by mikaelhg (47691) on Tuesday May 02, 2006 @08:37AM (#15244680)
    Better languages than the PHP disaster? Perl, Python, Ruby. They work _very_ well.

    Of these languages, only Perl has working multithreading support. Python and Ruby both have hugely granular global interpreter locking, which makes multithreading impractical.

    What works well for a hobbyist doesn't necessary work well when professional adult programmers need to accomplish something reliably day in and day out.
  • Re:No (Score:2, Informative)

    by Falkkin (97268) on Tuesday May 02, 2006 @11:04AM (#15246112) Homepage
    Some quick examples in Python (not fully tested, but this is the basic idea):

    bufferedFile = open("foo.txt", buffering=True) # or specify an integer if you want to manually set the buffer size

    sock = socket.socket() # then set it up
    objectReader = pickle.Unpickler(gzip.GzipFile(fileobj=sock))
    obj1 = objectReader.load()
    obj2 = objectReader.load() ...

    I will admit that setting up the socket in Python follows a painful, C-like method (bind(), connect(), etc.); however, for any real networking application, you'd probably be using the Twisted library anyways, which does a whole lot more.
  • PHP in the Java VM (Score:3, Informative)

    by koreth (409849) on Tuesday May 02, 2006 @11:19AM (#15246260)
    It is already being worked on, and you can download and try it out today (though it's not finished yet). It's called Quercus [caucho.com], from the guys who do the Resin [caucho.com] open-source app server. (Which is a fabulous piece of work, I might add.) It compiles PHP to Java bytecode, which can then be JIT-compiled to native code.
  • Re:No (Score:3, Informative)

    by mrroach (164090) on Tuesday May 02, 2006 @12:35PM (#15246981)
    In python, the thing that is usually done is for libraries to operate on "file-like" objects, meaning objects that implement some useful subset of the methods of the built in "file" object.

    As an example, the GzipFile object's constructor doc says:
    """The new class instance is based on fileobj, which can be a regular
                  file, a StringIO object, or any other object which simulates a file."""


    And the socket object's makefile() method documentation says this:
    """Return a regular file object corresponding to the socket."""


    So we should be able to create a socket and do

    GzipFile(fileobj=s.makefile('r')).read()

    However, the python GzipFile implementation seems to want to be able to seek within the file object, but the object returned by socket.makefile() does not have a tell() method. The easy solution is to fix GzipFile so that it doesn't need to seek, the real solution probably won't happen till Python3000 brings the interface magic to everything... (coming RSN)

    That said, in case someone wants to know a way to stream zlib data (the compression method used by zip and gzip):
    s = socket()
    s.connect((hostname, port))
    decomp = zlib.decompressobj()
    def recv():
        return decomp.decompress(s.recv(1024))
    then run recv() until it runs out of data

    You could actually do the same with gzip data, you'd just have to know the magic number of gzip header bits to skip before you start decompressing. The nice thing with the Java code you list above, of course, is that it's already implemented for you.

    -Mark
  • by ClaudeVMS (637469) <ClaudeVMS@hotmail.com> on Tuesday May 02, 2006 @03:24PM (#15248644) Journal
    At the rate of technology change isn't Java just another 1990s invention?

UFOs are for real: the Air Force doesn't exist.

Working...