while true do;

15 Responses to “Do you wanna see an enormous potential tool? Here’s the pascal for Java and Android”

1. duardbr Says:
   November 28th, 2011 at 7:03 pm

   Very nice … I want to code pascal for Android. I have a Samsung Galaxy SII .

   []’s from Brazil !

2. Dmitri Popov Says:
   November 28th, 2011 at 8:12 pm

   Is there any significant performance loss compared to “native” Java-written app?

3. Lex Li Says:
   November 29th, 2011 at 2:24 am

   There should be little performance loss, as Oxygen for Java programs are compiled to bytecode and executed on the same JVM.

   I think that is similar to C# and VB.NET running on .NET, same VM but different languages.

4. Dorin Duminica Says:
   November 29th, 2011 at 5:36 am

   @Dmitri Popov it shouldn’t be any, but if there is, it would be almost insignificant.

   @Daniele it is very interesting indeed, however, I’m way past the phase “it must be pascal-like if I am to code for X platform or using Y tool”, it would be much better to actually learn java rather than going for something like this, don’t get me wrong, I will give it a try when I will have time, but this is my honest opinion…

5. Eric Says:
   November 29th, 2011 at 8:48 am

   How far beyond cosmetic dressing does it goes?

   I was under the impression you still dealt directly with Java classes, like Oxygene for .Net deals directly with .Net class, so you couldn’t reuse code around platform beyond simple snippet that don’t involve maths, string manipulations, collections, File or DB accesses etc.

6. Cristiano Narcisi Says:
   November 29th, 2011 at 8:57 am

   I want it too. The Embarcadero can’t ignore Android World. I hope to see the native compilation of Android application into the Delphi ide. :-))

7. Daniele Teti Says:
   November 29th, 2011 at 10:02 am

   @Dmitri Popov:
   No, AFAIK there should not be. Oxygene compile Pascal code in Java byte code. So the JVM is the same and I dont think that RemObjects had changed to much on byte-code generation side. Even more on the Android side where the java byte code is recompiled in DalvikVM byte code.

   @Dorin Duminica:
   I’m no more in that phase since years ago, but surely is not a bad thing having more possibilities. See what .NET does with same CLR and different languages.

   @Eric
   Yes, this is the REAL problem. To overcome this problem, in Oxygene for .NET, there is a thin wrapper around some .NET classes that mimic the Delphi RTL. So your code could be more “portable” if it only use the Delphi RTL (AFAIK this “wrapper” is still not available on Java side). However, if you are using specific component in Delphi, you cannot use that code in other environment, but this is a broader problem and you have the SAME problem also in Delphi when you want to change some components with other “similar” components (e.g. Remove BDE to use dbExpress or something else). If you code depends by concrete classes (and not on their interfaces), you are tied to that class implementation. In other words, Oxygene for Java it’s a Pascal COMPILER, is not a Delphi for Java. However, IMHO, it’s VERY interesting. I hope that RemObjects will push a better integration with the Delphi RTL and the non visual components.

8. Leonardo M. Ramé Says:
   November 29th, 2011 at 1:06 pm

   Here’s another alternative:

   http://wiki.freepascal.org/Android_Interface

9. marc hoffman Says:
   November 29th, 2011 at 3:02 pm

   @Dmitry: there’s literally no performance loss, as Oxygene generates the exact same kind of byte code as the Java Language compiler does

   @Dorin: agreed with the “it has to be Pascal”. But Oxygene adds a lot more to the table than just the syntax (it’s a much more powerful language than Java), and doesn’t have the usual “it abstracts away the real platform” downsides. So with that - it doesn’t HAVE to be Pascal, but if it CAN, then why not?

   @Eric: it’s not cosmetic dressing at all. It’s just as native to the platform jas the Java Language is; it’s simply a different language chice (just like .NET has many language choices)

10. Eric Says:
    November 29th, 2011 at 3:13 pm

    Yes, I know about components and broader issue, but how deep really is the cross-platform RTL?

    Are there cross-platform collections and generics for instance? So that you can build up a minimum of reusable code? Or is it going to be limited to the bare bones?
    For instance is there a cross-platform Format equivalent? A set of stringwhatever conversion routines? Generic lists? Hash tables? Sorts? File access? Maths routines?

    To build any sort of reusable code, given the platforms involved don’t have raw, low-level-memory access, you need a fairly sizeable RTL to begin with.

    I’m wondering about a Delphi for Java here, but if an Oxygene for Java is compatible with Oxygene fro .Net, or if in practice, for production-sized code, you end up with incompatible code bases, like if it were a different dialect of Pascal.

11. Eric Says:
    November 29th, 2011 at 3:14 pm

    Typo:
    …I’m NOT wondering about…

12. Daniele Teti Says:
    November 29th, 2011 at 3:34 pm

    @Eric
    Yes, I share your vision about RTL and language portability. At this time, there isn’t. Maybe in a near future.

13. marc hoffman Says:
    November 29th, 2011 at 4:30 pm

    @Eric, @Daniele,

    there’s an open source effort top create a Delphi RTL wrapper for Oxygene/.NET, called ShineOn. Initially, Embarcadero was going to push that more as we partnered with them form Prism, but it has not seen much action lately. If there is interest, it could be expanded to cover Oxygene/Java as well. But, personally, i dont see as big a use case for sharing code between classic Delphi and Oxygene.

    More relevantly, there’s a separate project that was started to create a compatibility layer for core .NET classes to be available in Oxygene for Java (by mapping them to Java classes, or reimplementing them). This i think is a more promising/fruitful endeavor. If any of you are interested in participating, please create an account on http://code.remobjects.com and let me know, i’ll set you up with access to the project..

14. zeroc8 Says:
    November 30th, 2011 at 10:43 am

    I think one of the best things about it is that you can use Visual Studio to create truly (as opposed to Mono, where you need to check for compability) crossplattform applications. Not having to use sluggish and overcomplicated Java IDEs alone is worth the pricetag.

15. Michael Justin Says:
    December 3rd, 2011 at 11:43 pm

    Regarding performance, the Wikipedia section refers to a test which shows slower performance of Android 2.2 compared to Java Standard Edition (SE) 6.0:
    http://en.wikipedia.org/wiki/Dalvik_(software)#Performance

    The technical background might be that Androids virtual machine (Dalvik) does not execute normal Java VM bytecode. The Java VM is a stack machine, while the Dalvik VM is a register-based architecture, so its bytecode needs to be converted from compiled Java VM class files. This also means that the Dalvik VM implementation was written from scratch , while the JVM went through many optimization stages since it was introduced in 1996.

Leave a Reply

You must be logged in to post a comment.