Hi,

I've put a new FPC JVM snapshot online (corresponding to svn r19598 of the jvmbackend branch), linked from http://wiki.freepascal.org/FPC_JVM

Changes since the previous snapshot include:
* the compiler will now implicitly convert between all Pascal string types and JLString (java.lang.String)
* most, if not all, previously missing string helpers have been added to the system unit for all string types (insert, delete, pos, ...)
* several fillchar overloads for use on arrays have been added to the system unit
* generics now work
* the compiler will now generate a constructor that takes an (automatically generated) interface for all (also automatically generated) classes that are used to implement "procedure of object" procedure variables. This allows them to be used much more easily and naturally from Java code
* support for pchar, including typecasting an ansistring to pchar and indexing it like on native platforms (with read/write capabilities). Note that this does not work for unicodestring and pwidechar due to unicodestring mapping to java.lang.String, which is both opaque and immutable
* exceptions raised in invocations of virtual class methods and procedure variables are now properly propagated to the caller
* {$VARPARACOPYOUTCHECK+/-} / -Cv switch to enable checking var-parameters (and to a limited extent also out-parameters) on the JVM target for changes to the value passed as var-parameter during the function call (because they are handled via copy-in/copy-out, this may indicate unexpected bahviour later on).

Note that this code has not been synchronized with FPC svn trunk recently. Even though it's version 2.7.1, it dates from before the cpstrnew merge. I'm waiting for those changes to completely settle down before updating the JVM backend branch with them.

Jonas

Jonas,

Ik heb dit weekend wat zitten spelen met het JVM backend, voor m'n artikeltje over de JVM bytecode.

Wat is er nodig om writeln() en readln() werkend te krijgen ? Heb je dat zelf gepland of wacht je daar op patches ?

Michael.

Sorry, this was meant to be private, but it went to the list instead.

For everyone not speaking dutch:

I have been looking at the JVM backend, and noticed that file I/O is not working. I'm asking what is needed to get write(ln) or read(ln) working.

Michael.

I have been looking at the JVM backend, and noticed that file I/O is not working. I'm asking what is needed to get write(ln) or read(ln) working.

Mainly adapting rtl/inc/text.inc and rtl/inc/textrec.inc. I haven't looked yet in detail at whether the original code can be easily/ cleanly made compatible with the JVM backend or whether a separate implementation would be better.

I don't have any immediate plans to work on it.

Jonas

TextRec uses THandle for everything, I assume it can be used to store a pointer to an object (or whatever Java uses for files), since in Java everything is an object anyway ?

Michae.

TextRec uses THandle for everything, I assume it can be used to store a pointer to an object (or whatever Java uses for files), since in Java everything is an object anyway ?

Yes (once THandle is added to the JVM RTL and it is defined to Pointer or JLObject, at least :). It's generally a PrintStream: http://download.oracle.com/javase/1,5.0/docs/api/java/lang/System.html#out

There is however some functionality (e.g. writestr with ansistring) that uses the UserData byte array to store a pointer, which won't work on the JVM target. Some extra classes will also have to be moved from the jdk15 unit to the system unit to implement the functionality.

Jonas

Do you have a preference for either of them ?

That brings me to my second question/remark:
(which I had already prepared before sending my first mail ;) ):

It would be easier if the system unit could depend on jdk15 in the implementation section.

However, this is something that FPC never has been able to do, while Delphi can. It would be good if FPC could do the same, it would make some system units easier to manage. (in casu: the Java one)

I realize that the system unit cannot depend on just about any arbitrary unit, but some simple import units, or units containing only strings/constants/types should be possible.

However, I suspect that this is not a trivial task and maybe out of the scope of the JVM port.

Michael.

07.11.2011 4:39, Jonas Maebe пишет:

Interesting.
1) {$modeswitch unicodestrings} plus cpstring = nearly full string compatibility with delphi.
2) Nested routines implementation for JVM is very similar to closures. I think it could be easily advanced to complete crossplatform closure implementation.

I`m wating merging to trunk )

No, it doesn't matter. Pointer is probably more in line with the rest of the source code. As far as the compiler is concerned, they're the same thing.

Well, in that case we could just get rid of the jdk15 unit altogether and put everything directly in the system unit. The main reason I didn't do that is because it makes loading the system unit slower due to the tons of definitions (otoh, most "real" programs will probably use the jdk15 unit one way or another anyway). It's true that the downside is that occasionally definitions have to be moved from the jdk15 unit to the system unit.

Jonas

I have been looking at the JVM backend, and noticed that file I/O is not working. I'm asking what is needed to get write(ln) or read(ln) working.

One thing I forgot to mention: threadvars. They are already supported and work (should work) at the same as on other platforms, but it is not possible to automatically run code whenever a thread is started.

The way this is solved in Java is actually quite good, I think: threadvars are descendants of the java.lang.ThreadLocal class, and whenever you call the get() method of such an instance for the first time in a particular thread, its initialValue() method is called to determine the initial value of the threadvar in the current thread. This means that threadvars are only initialized when necessary, and you can easily add the required initialization code separately for every threadvar as needed.

The problem is that we don't have a Pascal language-level construct that maps to this mechanism (on other FPC targets, the initialization of system unit threadvars for I/O etc happens via some RTL-internal routines that we call whenever a new thread is registered with the RTL), and I'm not yet sure how to solve that.

Jonas

I had hoped for this :-)

separate unit.

As long as the system unit cannot handle separate units we can maybe make a jdk15sys.inc, and include this in jdk15.pp and in the implementation section of system.

Michael.