Tom Tromey writes:
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes:
Andrew If this is the case, then is there a good reason for not
Andrew starting to include 1.5 changes, that will compile with
Andrew pre-1.5 compilers, into the HEAD branch?
Andrew * less problems with
On Mon, 2004-11-15 at 19:26, Michael Koch wrote:
Am Montag, 15. November 2004 19:00 schrieb Tom Tromey:
Michael == Michael Koch [EMAIL PROTECTED] writes:
Actually, putting the new code on the trunk as well makes
merging harder, not easier. That's because when it is put on
the
Jeroen Frijters writes:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5 bytecode in the
VM is trivial, but we don't have any 1.5 source compilers yet, do we?
Sorry, I thought it was clear. Tom said Here
Andrew Haley wrote:
Jeroen Frijters writes:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5
bytecode in the
VM is trivial, but we don't have any 1.5 source compilers
yet, do we?
Sorry, I
Jeroen Frijters writes:
Andrew Haley wrote:
Jeroen Frijters writes:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5
bytecode in the VM is trivial, but we don't have any 1.5
source
Andrew Haley wrote:
We're losing context because of heavy snipping.
The question of 1.5 bytecode came up in the context of gcj.
Oh, sorry, I missed that. I thought it was a general Classpath point.
The ldc
class is a Good Thing in that context. Also, I can see no reason not
to recognize
Jeroen Frijters writes:
Andrew Haley wrote:
We're losing context because of heavy snipping.
The question of 1.5 bytecode came up in the context of gcj.
Oh, sorry, I missed that. I thought it was a general Classpath point.
The ldc class is a Good Thing in that context. Also,
Andrew Haley wrote:
In which case it'll fail because of unresolved classes. I don't see
how refusing to recognize the new format will help.
Just this Saturday I got a message from someone who tried to run a 1.5
class on IKVM and got a ClassNotFoundException, because I had forgotten
to disable
Jeroen Frijters writes:
Andrew Haley wrote:
In which case it'll fail because of unresolved classes. I don't see
how refusing to recognize the new format will help.
Just this Saturday I got a message from someone who tried to run a 1.5
class on IKVM and got a ClassNotFoundException,
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal to implement the 1.5
classes as much as possible (using 1.4 sources). I haven't thought about
it
Robert Schuster writes:
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal to implement the 1.5
classes as much as possible (using 1.4 sources).
Andrew Haley wrote:
Robert Schuster writes:
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal to implement the 1.5
classes as much as possible
Robert Schuster writes:
Andrew Haley wrote:
Robert Schuster writes:
There is actually a good reason. If the 1.5 classes are missing, the
chances that a 1.5 compiled class will run are slim. This is what Andrew
John Hughes was trying to address with his proposal to
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes:
Andrew If this is the case, then is there a good reason for not
Andrew starting to include 1.5 changes, that will compile with
Andrew pre-1.5 compilers, into the HEAD branch?
Andrew * less problems with keeping generics in sync with the
Am Montag, 15. November 2004 18:19 schrieb Tom Tromey:
Andrew == Andrew John Hughes [EMAIL PROTECTED]
writes:
Andrew If this is the case, then is there a good reason for not
Andrew starting to include 1.5 changes, that will compile with
Andrew pre-1.5 compilers, into the HEAD branch?
Michael == Michael Koch [EMAIL PROTECTED] writes:
Actually, putting the new code on the trunk as well makes merging
harder, not easier. That's because when it is put on the trunk all
the generic bits must be stripped out, meaning that we'll have
different versions of classes on the trunk
Am Montag, 15. November 2004 19:00 schrieb Tom Tromey:
Michael == Michael Koch [EMAIL PROTECTED] writes:
Actually, putting the new code on the trunk as well makes
merging harder, not easier. That's because when it is put on
the trunk all the generic bits must be stripped out, meaning
Andrew John Hughes writes:
On Sat, 2004-11-13 at 19:49, Tom Tromey wrote:
Bojan == Bojan Antonovic [EMAIL PROTECTED] writes:
Bojan Java 5.0 has some new language extensions. Many (?) of them, like
Bojan generics, are compiled in the way that the byte code binary is
Bojan
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5 bytecode in the
VM is trivial, but we don't have any 1.5 source compilers yet, do we?
I know Tom's working on gcjx, but AFAIK it isn't in a working state yet
and
On Sun, 2004-11-14 at 19:36, Jeroen Frijters wrote:
Andrew Haley wrote:
Make 1.5 bytecode a reqiurement for the 1.0 branch.
I don't understand what you mean by this. Supporting 1.5 bytecode in the
VM is trivial, but we don't have any 1.5 source compilers yet, do we?
I know Tom's working
On Sat, 2004-11-13 at 19:49, Tom Tromey wrote:
Bojan == Bojan Antonovic [EMAIL PROTECTED] writes:
Bojan Java 5.0 has some new language extensions. Many (?) of them, like
Bojan generics, are compiled in the way that the byte code binary is
Bojan compatible to older versions. While extending
21 matches
Mail list logo
