OMG Oracle/Sun ... out of the loop developer panicking
in [Java Programming]
|
From: Mike Schilling on 28 Feb 2010 20:07 Arne Vajh�j wrote: >> and if I ever had to 'migrate' to .NET I think I'd drown myself > > It is not that bad. > > You will find a lot of the stuff very familiar. Very, very familiar.
From: BGB / cr88192 on 28 Feb 2010 20:07 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4b8afff4$0$272$14726298(a)news.sunsite.dk... > On 28-02-2010 15:19, DuncanIdaho wrote: >> Well. thank's for all your comments. I've always used the development >> kits available from the apparently now defunct http://java.sun.com which >> now appears as an Oracle branded web site. > > Ofcourse. > > When Oracle buys SUN then they obviously rebrand all the SUN web sites, > > That is to be expected. > yep. > > Anyway as for IBM, I remember using some >> ghastly piece of IBM IDE nastiness whose name I have expunged from my >> memory forever. It was an explosion of green and grey with millions of >> windows and the most appalling spaghetti code nonsense you ever have >> seen ... > > Visual Age for Java 3.5 and 4.0 is on the top-10-hate-list of > many developers. > can't claim any personal experience with this one... > > and if I ever had to 'migrate' to .NET I think I'd drown myself > > It is not that bad. > > You will find a lot of the stuff very familiar. > agreed. actually, MS's tools and basic technology are fairly well polished. Visual Studio works fairly well (although, for other reasons, it doesn't entirely sway me from my primary use of Makefile's for building code...). similarly, C# is a fairly capable language (and not that much different from Java in many respects), and at well, C and C++ can also work on .NET (although one does have to force the C into pretending to be C++, but this is not too big of an issue...). CIL (AKA: MSIL) is also a fairly capable bytecode, as it can also directly handle C and C++, as well as C#, J#, VB, ... also, C++ on .NET (C++/CLI) is also capable of fairly directly accessing code and data in native land (no need for something like JNI or JNA). technically, CIL is actually a bit more capable and powerful than JBC (JBC is not particularly well suited to languages which are not Java...). granted, some non-Java languages have used JBC, but generally not cleanly (hacks are often needed), and a language like C or C++ can't be run directly (it has to be "faked" in many ways). CIL is, however, directly capable of representing C or C++ semantics (raw pointers, function pointers, ...) at the IL level. but, what of the cost?: between them, CIL is very much more complex, and its binary-representation (as a hacked-over PE/COFF image with something vaguely similar to a relational-database thrown in the mix), is generally somewhat ugly and difficult to work with (difficult to load, difficult to process, metadata has an inconvinient layout and is not really easy to convert, ...). similarly, there are not any particularly good alternative implementations (many alternative implementations exist of Java, but very few of .NET, and those which do exist are generally fairly poor...). but, I have gone and tried to make a VM which can deal with both JBC and CIL (as well, it has its own internal IL as well, of a vaguely similar style to JBC and CIL, but this IL is not particularly well suited for anything not C...). in general, the VM tries to share most of the internal machinery (mostly by me trying to keep everything modular and general-purpose), ... recently, I had also been trying to write my own implementation of the Java class library, so I can have one I can put under public domain, but then I am faced with what would seem to be the apparent task of writing a mountain of boilerplate (my experience thus far has been writing lots of code which seems to do relatively little, I have little idea why so many classes and methods are needed for all this stuff...). granted, I may be missing something here, as I primarily code in languages which are not Java... or such... > Arne
From: Lew on 28 Feb 2010 21:11 Roedy Green wrote: >> Have a look http://mindprod.com/jgloss/jdkreleasedates.html >> >> Originally we had a major release each year. We have not had one since >> 2006-12. This would be a part of Sun's financial trouble leading to >> its sale. Arne Vajhøj wrote: > It is not that unusual to see the interval between releases > increase in the second decade compared to the first decade > for a technology. It is usually a sign of increasing stability thus requiring fewer changes, increased user and installed base thus increasing the cost of changes, and increased language size and complexity thus also increasing the cost of changes. It is natural as the language gets "full" and fewer problems exist that new releases take longer. There is no reason to believe that it has anything to do with Sun's business troubles. What is the interval now between changes in, say, the C language, or COBOL? What company's financial woes are tied to that? -- Lew
From: Arne Vajhøj on 28 Feb 2010 22:34 On 28-02-2010 21:11, Lew wrote: > Roedy Green wrote: >>> Have a look http://mindprod.com/jgloss/jdkreleasedates.html >>> >>> Originally we had a major release each year. We have not had one since >>> 2006-12. This would be a part of Sun's financial trouble leading to >>> its sale. > > Arne Vajhøj wrote: >> It is not that unusual to see the interval between releases >> increase in the second decade compared to the first decade >> for a technology. > > It is usually a sign of increasing stability thus requiring fewer > changes, increased user and installed base thus increasing the cost of > changes, and increased language size and complexity thus also increasing > the cost of changes. It is natural as the language gets "full" and fewer > problems exist that new releases take longer. There is no reason to > believe that it has anything to do with Sun's business troubles. > > What is the interval now between changes in, say, the C language, or > COBOL? What company's financial woes are tied to that? C: based on C89, C99 and C1X then I would say that it was 10 years interval and may be headed for 15 years interval. COBOL: based on COBOL68, COBOL74, COBOL85, COBOL2002 then I would say it has gone 5 year -> 10 year -> 15 year. So us Java folks should not complain too much. That said then I am rather impatient for 1.7 ! :-) Arne
From: Arne Vajhøj on 28 Feb 2010 22:37
On 28-02-2010 20:07, BGB / cr88192 wrote: > "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message > news:4b8afff4$0$272$14726298(a)news.sunsite.dk... >> On 28-02-2010 15:19, DuncanIdaho wrote: >>> Anyway as for IBM, I remember using some >>> ghastly piece of IBM IDE nastiness whose name I have expunged from my >>> memory forever. It was an explosion of green and grey with millions of >>> windows and the most appalling spaghetti code nonsense you ever have >>> seen ... >> >> Visual Age for Java 3.5 and 4.0 is on the top-10-hate-list of >> many developers. >> > > can't claim any personal experience with this one... Consider yourself lucky. >>> and if I ever had to 'migrate' to .NET I think I'd drown myself >> >> It is not that bad. >> >> You will find a lot of the stuff very familiar. > > agreed. > > actually, MS's tools and basic technology are fairly well polished. .... > but, what of the cost?: > between them, CIL is very much more complex, and its binary-representation > (as a hacked-over PE/COFF image with something vaguely similar to a > relational-database thrown in the mix), is generally somewhat ugly and > difficult to work with (difficult to load, difficult to process, metadata > has an inconvinient layout and is not really easy to convert, ...). That is not a problem for those writing apps. > similarly, there are not any particularly good alternative implementations > (many alternative implementations exist of Java, but very few of .NET, and > those which do exist are generally fairly poor...). Mono is not that bad today. > but, I have gone and tried to make a VM which can deal with both JBC and CIL > (as well, it has its own internal IL as well, of a vaguely similar style to > JBC and CIL, but this IL is not particularly well suited for anything not > C...). IKVM can run Java byte code in .NET CLR. Arne |