Welcome!

Linux Containers Authors: Liz McMillan, Jason Bloomberg, Zakia Bouachraoui, Yeshim Deniz, Elizabeth White

Related Topics: Linux Containers, Java IoT

Linux Containers: Article

Java, Meet Python. Python, Meet Java

Java, Meet Python. Python, Meet Java

  • Read Sean Gallagher's technology blog

    As Sun and IBM haggle over the terms of open-sourcing Java, I think it's important to note: if they're trying to jumpstart more widespread development of Java applications on the server, they are barking up the wrong tree.

    The reason is simple - Python. The scripting language is already in widespread use, is object-oriented, is proven to scale moderately well (Marc Andreessen's Opsware wrote the entirety of the first version of their product in it), and is more friendly to the realities of most Linux deployments than Java - that is, it can run fine on cheap hardware with a finite amount of RAM.

    Over breakfast this morning, Andreessen pretty much summed up what I'd been thinking over the past few days. He talked about how Linux had usurped Unix workstations as the developer desktop, and how developers started prototyping in Python and Perl. "And they get it done in a week, and it works...and they say, 'Why do we need to move this over to something else, exactly?'"

    Java (specifically J2EE) is good at things like dealing with large number of transactions, dealing with application state, and stuff like that. But, a significant majority of applications on the Web don't necessarily generate enough of a transaction load to justify the penalties you have to pay with Java - a big memory footprint, more complicated software configuration issues, and (let's face it) somewhat more complicated than a scripting language. Java carries a lot of baggage with it to make the bytecode compiler happy that "agile" languages like Python and Perl (especially Perl) don't worry about. If they *really* need performance, they'll write it in what Linux developers invariably resort to for such a task: C.

    That doesn't mean that there isn't a place for Java in the world of Linux developers. It just means that place is a little tighter than the Java-ites might be accustomed to. Without a real niche in rapid prototyping, and without a real performance advantage, Java is sort of a happy medium - or an unhappy one, depending on how you look at it. Scripters will turn to Java reluctantly when they hit the top end of performance for things like database calls, because Java is at least less crufty than C. Faint praise, for sure.

    This is one of the reasons that people are excited about Groovy. Groovy's proponents claim that it , like Python, is an "agile" language. It seems suited to rapid prototyping, and since it's built specifically for the Java Virtual Machine, there's no need to rebuild applications in Java to make them scale better later.

    But for people to prototype on top of the JVM, the JVM has to be on their machine. Thus the desire to get Java open-sourced so it ends up on Linux distributions.

    There's just one problem: why would anybody pick an untested language on a relatively memory-heavy virtual machine to prototype on when they can just pop out Python bits that run without one? Especially when they can get by pretty much without the JVM in the first place?

    Well, there are those things that you get from Java - application state, database connection pooling, lots of messaging and transactional support - that you don't get from Python. But the thing is, you don't have to saddle yourself with developing the whole application in Java just to get those things. And, no matter how good Groovy is, I doubt anybody is going to convince Python, Perl and Ruby developers that life is all goodness and light over on the JVM, and they should just take the red pill and get it over with.

    The answer for Java is not just to take it open source. The answer is also to show open-source developers that Java plays nice with their favorite tools.

    One place where Java can get immediate traction is on the desktop. Right now, desktop development on Linux is in the Land of C: while Gnome's got some scripting support, it's still not exactly what desktop developers on other platforms are used to. And Java 2 Standard Edition fully implemented on Linux would mean that tools written elsewhere would be all set to rock and roll on Linux. But Java could also act as a front-end builder for scripted components.

    But for server applications, the best thing that the Java community can do to win the hearts and minds of open source developers is to expose Java to their existing tools.

    And guess what? That means contributing to Python.

    That's because the most obvious routes to integration between Python and Java--like SOAP, for example--aren't fully cooked yet in Python. ( SOAP::Lite for Perl is most of the way there, so Perl is less of a concern.) The Java/Python Interface (JPI) was another potential way of wiring these two worlds up, but the project seems to have gone dark.

    Regardless of what's out there in bits and pieces now, if there was some good, open-source, standardized reference implementation of a means for Python to invoke the Goodness of Java components without actually having to recode in Java, there might be a whole lot more reason for the open source community to embrace Java.

    So, Groovy is a great first step. But for Java to really get past the awkward pause in its relationship with open source developers, those keeping the Java flame have to get over themselves and the whole "not invented here" mindset that has locked them in thus far. Architectural purity is great. But pragmatism is better.
  • More Stories By Sean M. Gallagher

    Sean Gallagher is technology editor, Baseline Magazine, and blogs as the dotcommunist at http://weblog.dendro.com.

    Comments (11) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Monte Lin 03/25/04 11:23:06 AM EST

    But I hate Python's debugger.

    We need a better debug interface so that we can fire the pdb to intercept any running Python process just like the way gdb does on C/C++ process.

    gabriele 03/25/04 04:47:35 AM EST

    To me *this* article/discussion is short-sighted.

    Jython (and JRuby, that at least has a non-alpha release in this last two years) are still ruby and python.
    They have they'r own platform, libraries and so on.
    Groovy integrates tightly with java, and groovy's library is Java's one.

    Plus, if you ever took a look at the language it has some interesting features (notably, creative use of SmallTalkish/Rubyish blocks, the ability to have both ruby's function call without parenthesis and python's first class citizen functions, real lexical closures like lisp).

    I believe many people, even in this discussion are reacting to groovy jsr in a bad way for some reasons:

    1: this is a chance to grow *even* for jython, JCL, ObjectScript and so on. Dont' fall in the "they're stealing us momentum!" mood. If the platform wqich groovy is based upon (BSF) grows, and if agile languages are accpeted in the mainstream world (see the JSR) we all take advantage.

    2: choice is good. If ruby never existed prolly python won't have iterators (even if the BDFL quotes CLU).
    If python never existed probably perl won't have Objects. If AWK..

    3: It's not SUN that is pushing groovy. The authors are indipendent devs, thus if the JSR is accepted, that will' a good demonstration that the JCP is really an open process, confirming successes like the GenericJava/Pizza integration.

    Please, consider this a chance, not a problem. Try not to be insular. Look at the groovy wiki.

    Mike 03/25/04 02:00:41 AM EST

    I agree with this article 100%. I'm a somewhat recovering Java junkie from CS who got interested in Python 2 years ago, but only started realizing how cool it can be recently. I've been toying with some ideas on how to work on Python to make it more competive like adding better support for streams.

    Some ideas: http://www.blindmindseye.com/bmeblog/archives/000089.html

    Phillip J. Eby 03/23/04 08:20:57 AM EST

    I'm curious why nobody's mentioned JPE:

    http://jpe.sourceforge.net/

    90823890 03/23/04 07:40:08 AM EST

    I too am a bit comfused why Jython wasn't mentioned in the article, although I would like an easier "CPython" integration route as well for certain applications. We successfully use Jython (and other languages that are translated into JVM bytecode) in our production work.

    Michael McLay 03/23/04 12:03:47 AM EST

    """So, Groovy is a great first step. But for Java to really get past the awkward pause in its relationship with open source developers, those keeping the Java flame have to get over themselves and the whole "not invented here" mindset that has locked them in thus far. Architectural purity is great. But pragmatism is better."""

    Rule 9 from the Zen of Python:

    "Although practicality beats purity."

    Sun should remember DoD's failure with Ada. The DoD was too heavy handed in trying to control the language and they ultimately failed in the market place as a consequence. Why should the open source community buy into Java when they have a language like Python That give them more than Java? Python has its own byte code interpreter, why should it envy the JVM? Python integrates functional programming and proecedural programming with a strongly, but dynamically typed OO language. It doesn't force the developer to live in an OO straight jacket. Python also has a very easy to use C API for integrating legacy software into Python modules. Java is hostile to other languages by comparison.

    cupdike 03/21/04 05:33:42 PM EST

    As someone who uses jython in a production application, I took a brief look at groovy to assess it. I find it ironic that it's similarity to java syntax is considered a strength. IMHO, it makes the groovy code look ugly compared to jython code. The ability to paste java code into a groovy code seems of little value since it is usually done the other way around--you tinker at a scripting console and get the algorithm working and then port the code into java if needed. I doubt if groovy would port much easier than anything else since the functionality is different (that's the whole point of a using an alternative language). I have helped several developers learn python sytax so they could start scripting in jython and they always pick it up in a day or two--and then they know python too (and can access it's vast libraries that come along with it) for when they aren't restricted to using a JVM. Functionality-wise, groovy looks like it has a decent blend of features and I didn't see anything I would miss except for python's terse syntax (and triple quote syntax for literals, useful for templating without escaping embedded single and double quotes). But that's based on just browsing the docs. Pedigree-wise, groovy is very immature compared to jython (and even more so compared to python). Hence the consternation on selecting groovy as the subject of a JSR. For me, the choice to stay with jython is obvious--even ignoring groovy's immaturity. I don't just want an "agile" language for the jvm. I want an another language for the jvm that can also bridge me into the python world loaded with tools, apps, libraries and books with a vibrant community. But if you work with developers who won't be comfortable working outside of java's syntax and you only want to run on a jvm and you don't mind the relative immaturity, then groovy is probably a good alternative.

    Sean Gallagher 03/20/04 02:23:03 PM EST

    A clarification: Yes, Jython is the fastest route to achieving most of this compatibility. Which is why I'm puzzled by the Groovy project being forwarded as a JSR first; why a whole new language just for the JRE when people are already coding in Python? What I'm saying above is that the JCP should formalize Jython support (and other support for Python executing outside the Java framework) as part of the Java plaftorm if they want to reach a wider audience of Linux developers.

    Sorry I wasn't that explicit in the weblog entry; I'll add clarification on my website.

    Sean Gallagher 03/19/04 02:13:33 PM EST

    I briefly mentioned Jython in a previous post on the weblog this article was screen-scraped from. It's definitely something in the mix, but it seems, based on what the Java Community Process people are saying, that Jython is not "pure" enough for them, so Groovy is what they're pushing.

    I think that's short-sighted.

    Mike Hostetler 03/19/04 02:05:51 PM EST

    I agree with the Jython comment above. Why even bother talking about a SOAP marriage when Jython has it all -- and even better, since Jython can use and sub-class any Java class.

    Servlets in Python? Yep. SWING apps in Python? Yep. JDBC? Yep. Jython is the best thing Java has going for it.

    Check out http://www.jython.org

    Steve Toledo-Brown 03/19/04 11:28:58 AM EST

    Rather bizarre not to mention Jython in such an article.

    IoT & Smart Cities Stories
    The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
    CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
    All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
    Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
    DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
    Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
    The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
    SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...