Announcement

Collapse
No announcement yet.

Mono Developers Renew Their Love For Microsoft

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by ciplogic View Post
    Did I read the same text as well? Yes, maybe I misread but the Java did care (maybe too much) on backward compatibility so it wasn't able to make a (fairly trivial from bytecode standpoint) change to support "full" generics. If you look from CIL instruction set, there is no (visible) bytecode change
    If you did read the same text, you completely skimmed over the main points. He's talking about source code compatibility and you are talking about byte code issues. I believe you that the CIL instruction set didn't change, but C# rewrote their collections classes so C# 1.0/1.1 and C#2.0 used different collections classes and that posed a source code migration issue with existing C# 1.0/1.1 client code. The C# people may have made the better choice in hindsight, but I don't see any evidence that the Java implementation was hung up on legacy byte code restrictions.

    Originally posted by DanLamb View Post
    As I've told you, NUnit is far more popular, even MSTest is integrated with Visual Studio. NAnt was more popular than .bat files, and I've seen it working in big C++ companies before MSBuild was in place. I used NRefactory and I see no replacement for controls like AvalonDock or AvalonEdit.
    But I have told you, I am completely aware and in agreement that high quality open source technology exists in the .NET space. I'm not denying that exists or challenging you to list examples.

    My perception is that the .NET culture is still much more Microsoft centric and curated and there is less tolerance or interest in technologies that are not endorsed and promoted by Microsoft/Xamarin.

    Isn't MSBuild a Microsoft created and owned tech? The NAnt/MSBuild story you cite seems to confirm my belief: the official Microsoft/Oracle had a weak build solution so open source fills the role... With Java, the third party tool achieves predominance because it's just that good. With .NET, the Microsoft tool achieves predominance because it's Microsoft.

    Originally posted by ciplogic View Post
    It is not silly to claim that he doesn't represent the team. Because for example Miguel has political views, and clearly not everyone share his views. Steve Jobs did refrain to state politics on Twitter for example.
    Sure, when Miguel expresses extreme political views or when Steve Jobs talked about his LSD experiences, clearly those have little to do with the function of the teams and the leadership role of those people. Those views aren't representative of the team or its members.

    When Steve Jobs expresses negativity towards Flash or Blu-Ray, I'm sure there is plenty of disagreement within the members of the team, but it is reasonable that that viewpoint is representative of the team as a whole and the direction they are going in.

    Originally posted by ciplogic View Post
    Yes, I fully know what you mean, and I see that most of the differences between Mono (which is an open environment, as Java is) and Java is mostly about the perceived culture.
    This is correct. The perceived culture and also the perceived level of choice and quality that result from that culture.

    Originally posted by ciplogic View Post
    If I need a fancy toolkit, there is XWT, which is developed in the open and is the base of a major IDE in the Mono world (so is "half supported"), it is a vibrant and kicking. Is it anything than Swing (which is to be deprecated) and JavaFX around in the Java world?
    Swing is already deprecated by JavaFX for new projects, but Swing will continue to be fully supported for quite a while because it is used so heavily. I had never heard of XWT. Well, that's definitely a contender for a workstation platform agnostic GUI toolkit. In the past, the Mono fans heavily advocated native toolkits over platform agnostic toolkits.

    Comment


    • #52
      Originally posted by DanLamb View Post
      If you did read the same text, you completely skimmed over the main points. He's talking about source code compatibility and you are talking about byte code issues. I believe you that the CIL instruction set didn't change, but C# rewrote their collections classes so C# 1.0/1.1 and C#2.0 used different collections classes and that posed a source code migration issue with existing C# 1.0/1.1 client code. The C# people may have made the better choice in hindsight, but I don't see any evidence that the Java implementation was hung up on legacy byte code restrictions.
      So let me clarify the original point and topic: Java historically was much more conservative because there are historical issues (like a lot of code written in a specific version of JVM) but also technological issues. My understanding of the "Java guy" is simply that even it would be possible the new collections to be "fully" generic there is a cost of source migrations that is too big. Even so, the technicalities of generics (look on the next paragraph) are a much smaller issue on the bytecode level, compared with support of bytecode instructions. It is because JVM has only 256 (theoretical) bytecodes and the semantics of the bytecodes contain the type of the operations, so adding a new primitive type adds in itself a lot of "unwanted" bloat in bytecodes usages.

      As for CIL, you get two levels of information (the same is true for JVM): the "reflection"/"class metadata" kind of informations and the bytecode operations (CIL instruction set). To support Generics as far as I'm aware is no change (maybe there is one change) from the CIL instruction set. Anyway, the original point was that to add support for unsigned integers (for example) require much more semantic instructions on the JVM level from one side, and there are less "empty" slots than in the .Net case. Going back to generics, I said that the fact that the generics code generated by Java 1.5 would run on Java 1.4, even it would require very little machinery from the JVM side (none!?), this is not the case when you have to spare some of the 16 opcodes left for 5 math operations to support unsigned. Even more when this new code would require if you want to support all unsigned int types (like from Uint8 to Uint64, all supported by .Net), you may likely not have enough bytecodes, and even you have, you don't know the future, so is a bad decision to define them with no chance to go back.

      Java can create tomorrow with very little work on their side of the bytecode level (the JVM will have a huge task ahead, as many methods should be cloned and specialized) a new set of collections (as for Java 10!?) and reified generics. The biggest work should be on "metadata" and on "hot-spot" level, which both of them may face non-trivial migration issues, but are no technical limitations. As I've told you earlier: JVM is limited on 255 arguments per method. You can change this limitation on the Hotspot level, but you can't change this on the bytecode level (as "load argument" instruction has a 1 byte after this, so you cannot write "load argument" and after that the parameter to be 320). To be clear, these can be circumvented if the .class format will have a "version 2.0" which is incompatible with "old .class files", but as for now, there are big technical limitations (which were fully adequate for 1995 year when Java was launched), but as of today, they are not so much.
      Originally posted by DanLamb View Post
      (...) Swing is already deprecated by JavaFX for new projects, but Swing will continue to be fully supported for quite a while because it is used so heavily. I had never heard of XWT. Well, that's definitely a contender for a workstation platform agnostic GUI toolkit. In the past, the Mono fans heavily advocated native toolkits over platform agnostic toolkits.
      XWT is both agnostic and "gnostic" because it is implemented over native controls and you can also access the underlying native controls. So it matches the Mono "perspective" about UI toolkits.

      Comment


      • #53
        Originally posted by ciplogic View Post
        To be clear, these can be circumvented if the .class format will have a "version 2.0" which is incompatible with "old .class files"
        The .class file format has frequently changed so that older JDKs can't use them. This type of incompatibility is the norm and is very common. Same with .NET and most similar systems.

        Originally posted by ciplogic View Post
        but as for now, there are big technical limitations
        I believe your technical comments on the current structure of the JDK/CLR byte code.

        I don't trust this personal judgement of yours as to the scale and complexity of JDK team changes to the VM byte code. I believe you are exaggerating this.

        You are dismissing Neal Gafter as some "Java guy" (your quotes), who was directly involved with the implementation of JDK generics, who quite clearly says that they designed JDK generics with erasure to avoid the source code migration issue that C# faced, not because of underlying technical reasons. You could question his honesty or motivation, but that's clearly what he is claiming. Also, this "Java guy" has been a full time employee at Microsoft working on .NET for the past several years.saying

        Comment


        • #54
          Originally posted by DanLamb View Post
          The .class file format has frequently changed so that older JDKs can't use them. This type of incompatibility is the norm and is very common. Same with .NET and most similar systems.
          I believe your technical comments on the current structure of the JDK/CLR byte code.

          I don't trust this personal judgement of yours as to the scale and complexity of JDK team changes to the VM byte code. I believe you are exaggerating this.
          Of course I'm not exagerating this, because simply I know both bytecode formats. And as I've told you, there are let's say 32 positions out of 256 remaining. The reason I'm knowing this is simply because both formats are public and clearly described. Of course, these free slots can be extended like to be an "escape bytecode" and they will describe another codes on the 2nd byte. This will change that all bytecodes of JVM use 1 byte per bytecode (and this is why I've been clearly saying: keeping the same philosophy). Of course, JVM is free to break the bytecodes and to use another convention to make eventually support of bytecodes. Or maybe it will use a trick to push as a previous instruction the word size and it will have 1 "unsigned int" and the previous "push int" instruction will say the length of this int as being: uint8, uint16, uint32, ... uint128. All these "tricks" would make handily into 256 byte codes, but... they break the way the other bytecodes are done as of today in JVM.
          You are dismissing Neal Gafter as some "Java guy" (your quotes), who was directly involved with the implementation of JDK generics, who quite clearly says that they designed JDK generics with erasure to avoid the source code migration issue that C# faced, not because of underlying technical reasons. You could question his honesty or motivation, but that's clearly what he is claiming. Also, this "Java guy" has been a full time employee at Microsoft working on .NET for the past several years.saying
          I'm not dismissing Neal , I am more than sure that he is more skilled in the JVM than I am in .Net, but still this doesn't make the points stated false: bytecode instructions are limited and they don't use type inference (as .Net does) as the bytecode level. I certainly also know much less than Herb Sutter, or Miguel de Icaza or Steve Jobs (when he was alive). There are a lot of people around, but claims can be checked.

          Type erasure takes a lot of work to get it right, and given the Java state I am sure it was a difficult decision, but yet if Java 1.5 would have full generics would break many things (not only source wise, as you can still you can write C# 1.0 ArrayList in .Net 4.5 with no breakage), I would understand the inertia in Java world.

          Java class format is fairly fixed too, and the changes in between releases are fairly trivial. (in fact is the same in .Net 1.x, 2.x-3.5x, 4.x)

          Please read an instruction in the Java world (look to any instruction from this link). Look that the instruction.

          Let's look for example to SHL (shift left, << in C languages):

          Instruction:



          ishl
          Operation

          Shift left int
          Format


          ishl
          Forms

          ishl = 120 (0x78)
          Operand Stack

          ..., value1, value2 →

          ..., result
          Description

          Both value1 and value2 must be of type int. The values are popped from the operand stack. An int result is calculated by shifting value1 left by s bit positions, where s is the value of the low 5 bits of value2. The result is pushed onto the operand stack.
          Shifts an integer value to the left (in zeroes) by a specified number of bits, pushing the result onto the evaluation stack.


          A value is pushed onto the stack.

          The amount of bits to be shifted is pushed onto the stack.

          The number of bits to be shifted and the value are popped from the stack; the value is shifted left by the specified number of bits.

          The result is pushed onto the stack.

          The shl instruction shifts the value (type int32, int64 or native int) left by the specified number of bits. The number of bits is a value of type int32 or native int. The return value is unspecified if the number of bits to be shifted is greater than or equal to the width (in bits) of the supplied value.
          This is why you have for example iadd, fadd, dadd (int add, float add, double add) in the JVM instruction set, when in CLR there is just one instruction: add (that works over all types: int*, uint*, float, double).

          Comment


          • #55
            Originally posted by ciplogic View Post
            Of course I'm not exagerating this, because simply I know both bytecode formats. And as I've told you, there are let's say 32 positions out of 256 remaining. The reason I'm knowing this is simply because both formats are public and clearly described.
            My assertion is that you are exaggerating the technical effort of implementing reified generics in Java and the effort of changing the Java byte code. I did not and do not challenge the details your knowledge of the current state of the VM or the details that you cite.

            Originally posted by ciplogic View Post
            you can still you can write C# 1.0 ArrayList in .Net 4.5 with no breakage
            I know that and so does Neal Gafter. That's not what we are talking about.

            If there is a C# 1.0 library written with ArrayList, and has many clients using it, you can't remove ArrayList and change to List<Int> without breaking source code compatibility and requiring client code to change.

            Comment


            • #56
              Originally posted by DanLamb View Post
              My assertion is that you are exaggerating the technical effort of implementing reified generics in Java and the effort of changing the Java byte code. I did not and do not challenge the details your knowledge of the current state of the VM or the details that you cite.(...)
              If there is a C# 1.0 library written with ArrayList, and has many clients using it, you can't remove ArrayList and change to List<Int> without breaking source code compatibility and requiring client code to change.
              Let's clarify once again, and I rephrase the argument, even it will state the all facts the same.
              I started the topic line with the idea that JVM will not support unsigned int and you replied:
              Originally posted by DanLamb View Post
              The current bytecodes are limited in count, but there is no reason they can't completely redesign that. That wouldn't even be that big a deal. The new VMs need to support old byte code of course, but that wouldn't conflict.
              The parts that you say: there is no reason, but you ignore the fact that I give to you the reason: the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this. Reified generics could remain debatable, as about "how easy" or "how hard" it is, but let's state for the sake of argument, that is possible. I think that is likely possible. Anyway, this is because the way in .Net the generics are implemented, can be mapped even with today's limited capabilities to some extend to Java .class support (or by having name mangling and copies in a higher level language).

              But this doesn't change the part of the "easy" and "difficulty" of a component to invalidate my first point. The bytecode remains limited. I even went to the extent to give to you the sources so you can analyze the statement and see the faults. Either in my logic or in the links. who knows, maybe for you is as easy as to say how can be defined "Unsigned int" by providing a model of how this can be done, and this to be easy to retrofit into the JVM bytecode.

              If not, to me the talk doesn't seem equal, isn't it? I can say a lot of baseless statements about Java:
              - it is easy to retrofit Oracle's Java SE on mobile phones, Oracle don't do it just for political reasons (to limit Java access on a high quality reference JVM)
              - it is easy to JVM to work with pointers directly, but Java wants to be a simple C, otherwise will be a just over-the-weekend work for them
              - Oracle added a bytecode in 12 years (from Java 1.4, that changed how trigonometric function works, there is no major another instruction addition than invokedynamic), so if it is that hard, so it will take for them 100 years to add 10 other bytecodes
              - Jigsaw is the easiest solution to take, they just copied GAC design, it was decided just because Oracle didn't like OSGi
              - etc.

              But all this statements would be false, isn't it?

              I can make as many statements with easy/hard, but for me, based on how the things are publicly documented, there is a disconnect with no source.

              Comment


              • #57
                Originally posted by ciplogic View Post
                The parts that you say: there is no reason, but you ignore the fact that I give to you the reason: the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this.
                The spec shows how it is now, but it generally doesn't show you what future versions can or can not contain. JDK 9 can ignore that entire spec and use a completely different standard with a different spec.

                Originally posted by ciplogic View Post
                I can make as many statements with easy/hard, but for me, based on how the things are publicly documented, there is a disconnect with no source.
                I don't think I have proved or even could prove my point that making VM changes is easier than you are suggesting it is. You disagree, and assert it would be a larger effort to change VM byte code, but you also can't prove that. I think we just have to accept an unresolved disagreement on this issue.

                Comment


                • #58
                  Originally posted by ciplogic View Post
                  the JVM bytecode policy doesn't allow to add bytecodes as you have limited free slots. I give to you the specification so is it really in your power to check this.
                  Let me try once more. This point shouldn't be debateable:

                  Let's say the JDK9 or JDK10 devs take the spec with the byte code limits and flush it down the toilet and write a new system with a new spec that doesn't have those limits. As the old spec is working its way through the sewer system, how does it prevent the new system from working?

                  Comment


                  • #59
                    Originally posted by pandev92 View Post
                    The linux universe is full of nazi gnu people and trolls, be water my friend.
                    Nice! So when some blob takes the code, wraps it around with few features to always stay above or un/crippled compared to open, ships it with may-not nazi eula - then its okay. And when someone designs a license to protect freedom of code, he is nazi.

                    Pee more my friend, you are full of bulls--,.. water.

                    Comment


                    • #60
                      Originally posted by DanLamb View Post
                      Let me try once more. This point shouldn't be debateable:

                      Let's say the JDK9 or JDK10 devs take the spec with the byte code limits and flush it down the toilet and write a new system with a new spec that doesn't have those limits. As the old spec is working its way through the sewer system, how does it prevent the new system from working?
                      This doesn't sound trivial to me, it is really very hard to do it. And I don't play here with the words. They can use a .Net bytecode clone, and the "legacy .class" is converted automatically in to .Net bytecode. This solution "is trivial, really!" as in a way .Net is a superset of what Java can do (excluding Invoke-Dynamic). They can create a new bytecode set, and pack two VMs like ActionScript VM did. Just raising the limit of instructions from one byte to two bytes for JVMs, is similar with the change from ANSI to Unicode (in strings), which is trivial to be done "for some" but in reality took many years to be done correctly in Windows, Linux, Mac OS, etc. I can say any time: is not a big deal.

                      Java smart guys can work to cleanup the bytes, but as for now they didn't. I'm not going to speculate why, but I can just double down on my original quote:
                      "... Java is limited as types (and will not be able to add unsigned int in my understanding) because there are no enough bytecode numbers, and even the instructions that do math are for me a bit silly: you push two integers, and after that you have to call instruction "iadd", because you cannot add them anyway with "fadd" (addition of two floats)."
                      which seems it wasn't given a simple path. Throwing to toilet for real world projects is almost unheard of: Win32 API is supported from 1994 by Microsoft's WinNT (NT 3.5). Clean DOS programs work on Windows8 and XEyes work on today's X implementations in Linux.

                      Comment

                      Working...
                      X