Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 62

Thread: Mono Developers Renew Their Love For Microsoft

  1. #51
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote Originally Posted by ciplogic View Post
    Let me clarify: when Java faced the option to have reified generics and change the VM, they decided to not change the VM because it was a big deal.
    This is just false. It was end developer source code migration compatibility, not VM or byte code issues. Directly from Neal Gafter who was a principal author on the JDK at that time

    http://gafter.blogspot.com/2006/11/r...for-java.html:

    Generics are implemented using erasure as a response to the design requirement that they support migration compatibility: it should be possible to add generic type parameters to existing classes without breaking source or binary compatibility with existing clients. I wrote about this two years ago. Migration compatibility is exploited widely in JDK5; all of the collection classes and interfaces use generics, yet existing code using collections continues to work. Without migration compatibility, the collection APIs could not be retrofitted use generics; we would probably have added a separate, new set of collection APIs that use generics. That was the approach used by C# when generics were introduced, but Java did not take this approach because of the huge amount of pre-existing Java code using collections.
    I prefer the C# solution and I believe most other devs do as well.

    Quote Originally Posted by ciplogic View Post
    JVM may have a descentralized culture, but can you name something that come from a non descentralized source? Like a non de-facto implementation. If you make your own Java, can you name it Java? Or do you need to pass JCK suite and to pay Oracle for this certification!?
    "name something from a non decentralized source"? Non decentralized is centralized, so Oracle? I don't think that's what you meant. Obviously, almost everything in the Java world comes from outside of Oracle: the popular languages (Scala, Clojure, Groovy), the two major IDEs (Eclipse and IntelliJ), the popular build tools (Ant, Maven, Groovy, SBT), plus the popular web frameworks, logging frameworks, testing frameworks, mocking frameworks, etc.

    A non de-facto implementation? Like RoboVM or IcedTea or JRockit (was acquired and merged into mainline JDK) or the ones from here: http://en.wikipedia.org/wiki/List_of...rtual_machines

    Java is a trademark protected word. You can't name your own tech Java, just like you can't name your own tech company Microsoft or Google either. That's not an unreasonable restriction.

    You can also freely fork Java, as long as you keep it under GPL terms, which Google didn't want to do with Android.

    I completely acknowledge there is uglier legal or political issues invovling the JCP and the disputes with Apache Harmony and even Android.

    Quote Originally Posted by ciplogic View Post
    The fact that MS offers many infrastructure projects like NuGet, good Xml parsers, good libraries for almost anything made much useless to create libraries for various aspects where Java created them. There is no need for Maven or OSGi in .Net's world, or a very little reason to exist a project like Jigsaw or InvokeDynamic.
    This is where we agree to disagree. You point out all these open source .NET projects and activity which I'm generally aware of and point out that C# has official ECMA standardization which I already know, but then you say that MS technologies are so good, that .NET doesn't need the same type of open source choices. That last part is where we can agree do disagree. I've worked in C# companies for years, and often there's various Microsoft standards, which to others are fine, but to me are awful, and there's just a widespread hostility to non-Microsoft alternatives. I find that stifling. Clearly, you are happy with .NET as a more heavily curated ecosystem, and so are a lot of other perfectly intelligent developers.

    Quote Originally Posted by ciplogic View Post
    First of all I never suggested that Xamarin is neutral, but I didn't see any point where Oracle is technology neutral.
    The one big difference is that when Oracle does something arguably wrong, the community is more willing to adopt non-Oracle solutions.

    Quote Originally Posted by ciplogic View Post
    Another mistake is that you seem to have a bias against Xamarin as a MS supporter, but Xamarin is different from Miguel de Icaza. On his blog he writes that he doesn't present the position of his employer. So he supported Silverlight, Linq, Typescript and MS's Office Xml format, but Xamarin did not support all (some were supported like: C#, .Net, F#) but Xamarin is neutral on MS Office, Silverlight, TypeScript. Is it good to make this distinction for many reasons.
    Miguel is the founder and CTO and spokesperson for Xamarin. That is silly to claim that he doesn't represent the team when he's talking about work relevant issues. Did Steve Jobs not represent Apple? Sure, there is some difference between the leaders and the official company.

    Before Xamarin split from Novell and chose its current name, that team did support and promote Silverlight for many years before eventually cancelling it.

    Quote Originally Posted by ciplogic View Post
    At last, why you use Scala as the best example, why don't *you* support it for .Net?
    It's not my job to promote Scala and I don't want to put more effort into promoting it than making casual recommendations. Scala tried to support both JVM/CLR in the past, but I presume the cost of supporting different ecosystems, and a lack of interest from the .NET side didn't justify it. The typesafe guys make lots of effort to cater to both Java and C# developers.

  2. #52
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote Originally Posted by DanLamb View Post
    This is just false. It was end developer source code migration compatibility, not VM or byte code issues. Directly from Neal Gafter who was a principal author on the JDK at that time

    http://gafter.blogspot.com/2006/11/r...for-java.html:
    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 (there are some extra parameters the class Type has to have to make things working) to support generics explicitly. This is in stark contrast with the idea of adding support for unsigned int, in which JVM (if it follows the previous bytecode philosophy) doesn't have bytecodes to spare (and imagine the previous code will be 100% compatible, so is out of the talk of Generics that can break code).
    Quote Originally Posted by DanLamb View Post
    "name something from a non decentralized source"? Non decentralized is centralized, so Oracle? I don't think that's what you meant. Obviously, almost everything in the Java world comes from outside of Oracle: the popular languages (Scala, Clojure, Groovy), the two major IDEs (Eclipse and IntelliJ), the popular build tools (Ant, Maven, Groovy, SBT), plus the popular web frameworks, logging frameworks, testing frameworks, mocking frameworks, etc.

    A non de-facto implementation? Like RoboVM or IcedTea or JRockit (was acquired and merged into mainline JDK) or the ones from here: http://en.wikipedia.org/wiki/List_of...rtual_machines
    Yes, this is in fact what exists also in the .Net world, some parts were replaced by upstream implementations (like Nant was and is still popular, but people use today MSBuild because is well integrated with both VS or Xamarin or SharpDevelop). Some items are not yet replaced by far like: NUnit is far more popular than MSTest, and in my work for years I have not seen any MSTest "shop" to say so. NUGet makes so hard to make another replacement usable (they were, like Mono.Addins), because it is integrated vertically (from the command line to IDEs) and also horizontally: it supports C#, VB.Net, C++, etc. NHibernate was really very popular before Entity come about, and the success of Entity was based on many folds of reasons again: it was opensource, well packaged, well documented, supported by MS, as it was MVC3 or MVC4, the "new" MS way to implement web frontends. There are in fact a lot of opensource/free packages in the C# world, maybe a half of what you have in Java (with Maven), but is a non-trivial number (Stable packages: "There are 16768 packages" ).

    But what I meant by Java contributions in a descentalized source (you're right, I've mistyped) is that major contributions from outside that went back to Oracle. Like let's say an Hibernate to become the reference JPA implementation, or OSGi to be a standard way accepted by Oracle to modularize (at leas the high level components). What about MS/Xamarin. As was told earlier DLR started as an opensource project and is still opensource (even it "runs" the dynamic C# part), Ikvm.Reflect is the reflection API of the Mono's C# compiler.

    Quote Originally Posted by DanLamb View Post
    Java is a trademark protected word. You can't name your own tech Java, just like you can't name your own tech company Microsoft or Google either. That's not an unreasonable restriction.

    You can also freely fork Java, as long as you keep it under GPL terms, which Google didn't want to do with Android.

    I completely acknowledge there is uglier legal or political issues invovling the JCP and the disputes with Apache Harmony and even Android.

    This is where we agree to disagree. You point out all these open source .NET projects and activity which I'm generally aware of and point out that C# has official ECMA standardization which I already know, but then you say that MS technologies are so good, that .NET doesn't need the same type of open source choices. That last part is where we can agree do disagree. I've worked in C# companies for years, and often there's various Microsoft standards, which to others are fine, but to me are awful, and there's just a widespread hostility to non-Microsoft alternatives. I find that stifling. Clearly, you are happy with .NET as a more heavily curated ecosystem, and so are a lot of other perfectly intelligent developers.
    The one big difference is that when Oracle does something arguably wrong, the community is more willing to adopt non-Oracle solutions.
    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.

    [QUOTE=DanLamb;373771]
    Miguel is the founder and CTO and spokesperson for Xamarin. That is silly to claim that he doesn't represent the team when he's talking about work relevant issues. Did Steve Jobs not represent Apple? Sure, there is some difference between the leaders and the official company.

    Before Xamarin split from Novell and chose its current name, that team did support and promote Silverlight for many years before eventually cancelling it.
    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. Similarly, Novell had a politics (albeit criticized from Linux folks) of interoperability, so it was normal that if Miguel (or Novell) believed that they want to interoperate with MS, they have to make Mono compatible and to promote their stuff.

    Why I say that Miguel is different from let's say Xamarin or Novell, is at another level: certainly he was bashing C++ or Java on his blogs, but also people from other communities do it also. Rob Pike (Go creator) does it, Herb Shutter (is from Microsoft btw) the C++ committee head in his presentations is a collection of logical fallacies, and I think for Miguel to answer to him was at least appropriate. Is it also true from other members (I don't know all the outspoken Java folks, but Cliff Chick did comment that Java can beat C++ handily and he retracted some claims).

    Taking of the face value, Miguel was (and I think he still is) an enthusiast, a dreamer (at least technology wise, as politics he looks down to earth to me) and he made many claims promoting MS technologies (which he obviously like). Anyway, he did it many times with fairly good reasons. For example his promotion of MS OpenXml, and the support in Gnumeric is common sense for me: he stated that Gnumeric internals were matching really well the MS format, so it was much easier to support than ODF and for small projects is overkill; his promotion of Silverlight was that he didn't want that Linux to be the "second or third class citizen" in the case that Silverlight is successful. I think that these are good views in themselves (even are made from a partisan standpoint).

    Quote Originally Posted by DanLamb View Post
    It's not my job to promote Scala and I don't want to put more effort into promoting it than making casual recommendations. Scala tried to support both JVM/CLR in the past, but I presume the cost of supporting different ecosystems, and a lack of interest from the .NET side didn't justify it. The typesafe guys make lots of effort to cater to both Java and C# developers.
    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. As for me I'm not so interested in Scala(the same about Closure), but not because I have something against Java, but because sometimes the combination of IDE, tools (paid ones) that are given from my company and opensource/free ones do successfully fill my needs. 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?

  3. #53
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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.

  4. #54
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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.
    Quote 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.

  5. #55
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote 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.

    Quote 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

  6. #56
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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:

    http://docs.oracle.com/javase/specs/...ml/jvms-6.html

    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.
    http://msdn.microsoft.com/en-us/libr...vs.110%29.aspx

    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).

  7. #57
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote 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.

    Quote 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.

  8. #58
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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:
    Quote 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.

  9. #59
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote 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.

    Quote 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.

  10. #60
    Join Date
    Feb 2013
    Posts
    232

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •