Discussions

News: Apache Portable Runtime 1.0 Release

  1. Apache Portable Runtime 1.0 Release (9 messages)

    Apache Portable Runtime (APR) 1.0.0 is now available. The APR Project aims to provide an API to which software developers may code and be assured of predictable if not identical behavior regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features.

    The primary core subsystems of APR 1.0 include atomic operations, dynamic shared object loading, file I/O, locks (mutexes, condition variables, etc), memory management (high performance allocators), memory-mapped files, network I/O, shared memory, thread and process management, various data structures (tables, hashes, priority queues, etc).

    Note that APR 1.0 is not binary compatible with earlier APR 0.9 releases.

    If you have been using the Apache Portable Runtime libraries in your project, let TheServerSide community know how useful it has been.

    Read more: Apache Portable Runtime 1.0

    Visit the Apache Portable Runtime home page

    Threaded Messages (9)

  2. Apache Portable Runtime 1.0 Release[ Go to top ]

    Note that Apache Portable Runtime 1.0 is not binary compatible with earlier APR 0.9 releases.
    I think calling such stuff "portable" is just pathetic.
  3. Apache Portable Runtime 1.0 Release[ Go to top ]

    Note that Apache Portable Runtime 1.0 is not binary compatible with earlier APR 0.9 releases.
    I think calling such stuff "portable" is just pathetic.
    Why?
  4. Apache Portable Runtime 1.0 Release[ Go to top ]

    Note that Apache Portable Runtime 1.0 is not binary compatible with earlier APR 0.9 releases.
    I think calling such stuff "portable" is just pathetic.
    I understand what you mean. Maintaining portability is difficult if each minor update breaks compatibility. But that's not the case here. Version 1.0 generally means (the API is frozen until version 2.0 where the API update is also frozen until version 3.0). Other 1.x versions should be backwards compatible with 1.0. If it isn't (see GCC C++ for an example), I'll agree with you.
  5. Apache Portable Runtime 1.0 Release[ Go to top ]

    I don't think this is good enough. V2 needs to be binary compatible with V1 as does V3 and V4. If you want to break compatibility then it should be a major deal and you need to provide a lot of notice to users.

    If you want it to be a platform then this behavior should be a given. If you don't do this then it's not a platform for anything. Other open source projects have the same trouble and it's a MAJOR problem for people using the software. Two components get used which need different versions of the 'platform' component and bang, you're hosed, everybody has to port to the latest and greatest platform and what you have now is a release nightmare as everybody needs to be marching to the same version and that just doesn't work as the product gets larger. You really need to make sure that even if Vn of the platform is in a JVM that components using Vn-3,Vn-2,Vn-2 and Vn can coexist on the same class loader with out a recompile. This is a minimum requirement.

    My two cents.
  6. Apache Portable Runtime 1.0 Release[ Go to top ]

    I don't think this is good enough. V2 needs to be binary compatible with V1 as does V3 and V4. If you want to break compatibility then it should be a major deal and you need to provide a lot of notice to users. If you want it to be a platform then this behavior should be a given. If you don't do this then it's not a platform for anything. Other open source projects have the same trouble and it's a MAJOR problem for people using the software. Two components get used which need different versions of the 'platform' component and bang, you're hosed, everybody has to port to the latest and greatest platform and what you have now is a release nightmare as everybody needs to be marching to the same version and that just doesn't work as the product gets larger. You really need to make sure that even if Vn of the platform is in a JVM that components using Vn-3,Vn-2,Vn-2 and Vn can coexist on the same class loader with out a recompile. This is a minimum requirement.My two cents.
    Understood but it is usually acceptable for non compatibility with a pre-1.0 -> 1.0 version. That's fairly standard in my experience.
  7. Apache Portable Runtime 1.0 Release[ Go to top ]

    I think some people are confused here. This project is not a JAVA based project but rather a C based one. It aims to provide a common platform for programs created in C/C++. (Much like a JVM).

    It was built to allow the Apache HTTP Server to be built on a number of platforms. The Mozilla team did a very smilair thing with their browser.

    And unlike a Java program in a shared JVM, you can have "multiple" inconpattible versions arounds since each program instance links in the specific code its needs, assuming you use static linking.
  8. Why is this on a Java forum[ Go to top ]

    OK. That makes sense.

    The primary problem is that a new C-based product is posted on a Java forum without telling people it is not Java. No doubt we are scratching our heads!
  9. What is this?[ Go to top ]

    What is APR? I have visited this home page and this don't seem very clear. It appears that its goal is to achieve platform independency (this is the same goal of Java language so I think APR would be a non-Java alternative to JVM).

    Can anybody help?

    Thanks,

    Finsals
  10. I think calling such stuff "portable" is just pathetic.
    It's quite descriptive, as in this case "portable" refers to platform portability, not version portablility. It is a library written in portable C that allows it to be compiled on as many platforms as have a C compiler.

    APR actually has pretty strong guarantees on version portability, as well. See http://apr.apache.org/versioning.html for details.