I can hardly say I'm suprised that Sun don't want their code being used to improve Mono. Why on earth should they want that at all?
Just because you're drinking the M$ koolaid doesn't mean that Sun has to.
Re:higher percentage of mistakes in C++ decompilat
on
Decompiling Java
·
· Score: 1
True enough, my point is that if someone wants to hack your code, the fact that it's a native executable is hardly a giant barrier (and if you really think it is, you can native compile your java code anyway)
I've been in industry for about the same length of time. My comment about the programmer's you know stands.
Re:Want to keep your code to yourself? Use C++.
on
Decompiling Java
·
· Score: 1
C++ can be decompiled well enough.
Besides, GCJ compiles Java to native executables, so if you think that being native is some kind of "defence" against decompilation / reverse engineering then you can be just as "safe" using Java and GCJ as with C++ and GCC.
You miss the main point. Decompiling the.class file gives me a very readable.java file. Stepping through debugger is not something average programmer can do
What????!!!!
Stepping. Through code. With a debugger. THAT is something you think the average programmer can't do????
Remind me never to hire any programmers you know!:o)
Don't suppose you have that component freely available for others?
Sadly, no - I wrote it while working for my previous employer and under the usual IP contract rules - it's all theirs. It's a pity too, I found *some* third party tables, but they sucked - and they were charging an arm and a leg for them too (another good thing about Java - the open source mindset is very prevallent in the community)
Oh, and regarding the action handler thing - no, it's not being able to pass the same handler to more than one event producer (obviously you can do that in.NET and it works fine), it's having a single object that represents the action (handler, short name, description, icon etc...) and constructing the menu, the buttons from that. The action object gives you one place to mangage state, so that if you disable the action, it disables the associated menu, buttons and any other device that handles the action.
Again, I implemented it in C# and was pleased with the results, but again, it's closed source and lost to the world;o)
Yes, a DataGrid can be populated by anything that implements IList, unfortunately, that interface is utterly impoverished - it provides no way to do simple things like re-order elements, get selection events etc....
It is designed for use by DB's - it is in no way as general and flexible as a JTable. JTable is a proper MVC component which makes no assumptions about the datamodel. See JTable's custom editors, renderers, column models, selection listeners then go look at DataGrid again and tell me they're the same.
Look - I used to work doing C# development - I *wanted* to use DataGrid for general tables - I sure as hell did *not* want to reinvent the wheel - but the reality is that for.NET they haven't got to the wheel yet as far as a basic suite of UI widgets and components is concerned.
Example other than Tables: menus -.NET menus can't even have icons in them despite that this is a W32 basic element. Java, OTOH, has had these for ages despite the rhetoric about Java being a compromise because of it's cross platform nature - the reality is quite the opposite.
Another example: Action pattern (shared action handler between button and menus) - Delphi implements this, Java implements this,.NET doesn't. And it's BASIC. Utterly primitive UI stuff that.NET *doesn't* support.
I ended up having to write an entire Table component from scratch.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
Could you elaborate? I tried this and it worked for me:
Dude, you did notice that none of those code lines was a case of
A.B.C = someval?
Note: it's an assignment to A.B.C, you only ever read the value of A.B.C - I didn't claim that that didn't work!
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
By giving it a name, you're essentially wasting time performing manual C++-style name mangling (for no reason at all).
No. Not at all. When you have:
list.map(<thing you can insert here>)
There is a relationship between map and the thing that you insert as a parameter. This relationship has meaning and the interface attaches a name to that meaning. This is the whole point of interfaces expressing a contract between objects and not being anonymous like the C example you gave.
Look, you either get that documenting relations between classes is good, or you don't, if you're seriously upset about those couple of extra characters Java puts you through then you're probably not the kind of person who values maintenability over brevity anyway.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 1
But this is not a problem with properties per se, but with the special implementation of properties in C#. I don't see a reason why an implementation of properties would not be able to allow that.
But we are talking about C#, and this is the behaviour that it has. And it cannot be implementation specific, unless you're telling me that Microsoft's implementation of C# is incorrect?
You are speaking about one specific application of function pointers, which indeed would be better solved with other concepts.
I'm talking about their use as event handlers which is 99% of their use in the entirity of C#. This is hardly a niche issue.
which BTW is also possible for Java interfaces: What does the method public void mymethod(MyInterface mi) do?
Ummm... that doesn't exist anywhere in the Java APIs.
The fact is that all of the standard APIs have well named interfaces. This means you are guaranteed that the implementation of event handlers are well named in Java by design, but because of C#'s delegate system, you have no guarantees about what the event handlers are called and you have no idea from reading the class what events it handles. In other words, C# has obliterated every trace of the contract between the event producer and the event consumer. This reduces code readability, hence maintainability and is a bad thing(tm)
A simple example where function pointer make sense is the following function(I'll use C syntax since I don't know the syntax of C# function pointers):
typedef double (*real_function)(double);
double integrate(real_function f, double lower_bound, double upper_bound);
Here using interfaces would not only be overkill, it would actually be a disadvantage (what if your function comes from a different library which doesn't know anything at all about your interface? You'd have to make a wrapper for every single function of that class).
Ahhh... you're not familiar with C#'s syntax.... that explains a bit (since the 'disadvantage' you mention for interfaces applies exactly the same to delegates for precisely the same reason). It's not the equivallent to the C/C++ function pointer - you have to declare a delegate type first which types the pointer and an event property on the event producer which provides the event, and write the code which raises the event and marshalls its parameters - so you see, C# actually has pretty much the same amount of setup work to handle these kind of things as Java, it just does it without enforcing any kind of naming standards or documenting where the end point of an event actually is.
Unlike yourself, I have actually programmed with both Java and C# (and C, C++ as well) and I can tell you from actual experience, that delegates are a mess and Java's interfaces are a much more maintainable and clean approach.
You say interfaces are overkill because is C you have the svelt:
typedef double (*real_function)(double);
That's hardly a million miles away from:
Interface realFunc { public double calculate(double in); }
Well... except that the Java version is easier to read.
Re:With Java, stuck in Windows/Linux/Solaris
on
Java 1.5 vs C#
·
· Score: 1
Quite so. It's increadible how much the anti-java brigade fail to see the ammount of industry support for Java and claim that Java is just "Evil-Sun" (tm) 's Smash-OSS-O'Rama software.
Java is genuinely cross platform and genuinely open. FFS, the Apache foundation has as much influence on the direction of Java as does IBM, or BEA, or... Sun.
Those certifications do not prevent it being patent encumbered.
Re:Too bad we can't mod articles
on
Java 1.5 vs C#
·
· Score: 1
Yeah and Delphi is such a *great* environment to copy. You're right - VS.NET borrows heavily from Delphi and suffers from the same moronic view that the GUI is the sole organising structure for your code.
But... jeez, if you can't see that C# borrowed from Java you're past blind and into the "willfully stupid" catagory. C# is Java by people who just didn't get it in the first place.
Re:Java is a 32-bit language; C# is a 64-bit langu
on
Java 1.5 vs C#
·
· Score: 2, Informative
Pure and utter FUD
from http://www.manageability.org/blog/stuff/why-cant-m icrosoft-deliver-64-bin-dotnet/view
Despite having a research and development budget that is almost 7 billion dollars a year, Microsoft apparently can't deliver.NET for 64-bit Windows 2003. Infoworld in a recent analysis explains:
The lack of a 64-bit implementation of the.Net Framework means that the hard work many Windows developers have put into migrating to the.Net development model is for naught on Windows on Itanium.
In the meantime, IT shops that wish to employ 64-bit Windows as an application server or Web services platform will be forced to revert to the older, Windows DNA (Distributed Internet Applications) environment.
In stark contrast, BEA Systems and Sun have been shipping JRockit and J2SE with Itanium support ever since JDK 1.4.1 was released. Furthermore, according to the reports 64-bit Opteron support is expected at the same time JDK 1.5 is released.
Re:I code C# for a living
on
Java 1.5 vs C#
·
· Score: 2, Insightful
Properties are also good. Instead of identifying them through string matching ("get*", "set*"), language-level support for properties allows more accurate data type modelling. In the end, however, the CLR doesn't really have true support for properties.
I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because what I thought would be a property is implemented as a getter and setter or vice versa. This ends up wasting your time reading documentation to find which way getting the value is implemented. This is never a problem in java, it's always getMyVal();
The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:
A.B.C = someVal;
I beleive it's because the A.B bit puts the B value on the stack and assigning a value to it doesn't get back into A. At any rate, it doesn't work and to me it's pretty obvious that it should.
Function pointers and anonymous functions. This has got to be the biggest improvement over Java.
Again, I disagree. Function pointers are not a good feature. Implementing an interface in Java (which is the equivallent process to function pointers in C#) is better because the interface expresses a contract and the naming of the functions involved reflect that contract. What I mean is that when I see this in Java:
public void actionPerformed(ActionEvent ae)
I know that I've found a method fullfilling the ActionListener contract - what's more, the class involved will say implements ActionListener so the existence of the contract is explicit. With C# I could find a function like so:
public void myfunc(object sender)
...And that could be the end point for any old connection between classes. The good thing about OO is that the methods on classes represent the communication contract between entities. This is an important API and should be as explicit as possible, not virtually rendered anonymous as in C#
And in the end, the obvious difference between Java and C# is that Java is everywhere and open and C# isn't. Yes,.NET has *parts* of it as an ECMA standard, but ECMA standards *DONT* exclude technology which is patent encumbered. Meanwhile there are dozens of open source Java implementations and Java exists on pretty much every machine under the sun.
And many studies have shown that going with Microsoft software is cheaper than going with open sourced software.
And when you refuse to acknowledge the numbers and chant the same old slogans, you know that language bigotry has triumphed yet again over actual fact.
We're so engrained in these procedure based languages that we seem to have accepted the fact that add(a, b) is the natural way to do things.
I'd say just the same to you. It's people who are pedantic about everything looking like maths that *must* have stuff written as:
a = b + c;
Personally I find that no more or less readable than:
a.equals(b.plus(c));
or:
(setq a (+ b c))
In fact, in many ways I think that the LISP approach is infinitely superior to overloaded operators in that there is never the issue of figuring out prescedence since it always follows the prefix operator pattern.
I don't see any good reason to assume that having code that looks like maths notation is superior to code which doesn't. For a start - all code is read by coders, not neccessarily by mathematicians. In addition, having one style of applying operations in your code clearly makes code which is more consistent (therefore maintainable) than code that implements many styles.
You're so engrained in mathematical notation that you seem to have accepted the fact that a = b + c is the natural way to do things.
That's really sad. You have all the functionality you want but can't progress because your favourite syntactical sugar isn't there?
That's pathetic.
That's like saying, I've got this *great* idea but I can't code it up because I'm using C and it has brackets and not "BEGIN... END" and I just can't live without them.
Slashdot Mirror
I can hardly say I'm suprised that Sun don't want their code being used to improve Mono. Why on earth should they want that at all?
Just because you're drinking the M$ koolaid doesn't mean that Sun has to.
True enough, my point is that if someone wants to hack your code, the fact that it's a native executable is hardly a giant barrier (and if you really think it is, you can native compile your java code anyway)
I've been in industry for about the same length of time. My comment about the programmer's you know stands.
C++ can be decompiled well enough.
Besides, GCJ compiles Java to native executables, so if you think that being native is some kind of "defence" against decompilation / reverse engineering then you can be just as "safe" using Java and GCJ as with C++ and GCC.
What????!!!!
Stepping. Through code. With a debugger. THAT is something you think the average programmer can't do????
Remind me never to hire any programmers you know! :o)
Don't suppose you have that component freely available for others?
.NET and it works fine), it's having a single object that represents the action (handler, short name, description, icon etc...) and constructing the menu, the buttons from that. The action object gives you one place to mangage state, so that if you disable the action, it disables the associated menu, buttons and any other device that handles the action.
;o)
Sadly, no - I wrote it while working for my previous employer and under the usual IP contract rules - it's all theirs. It's a pity too, I found *some* third party tables, but they sucked - and they were charging an arm and a leg for them too (another good thing about Java - the open source mindset is very prevallent in the community)
Oh, and regarding the action handler thing - no, it's not being able to pass the same handler to more than one event producer (obviously you can do that in
Again, I implemented it in C# and was pleased with the results, but again, it's closed source and lost to the world
Yes, a DataGrid can be populated by anything that implements IList, unfortunately, that interface is utterly impoverished - it provides no way to do simple things like re-order elements, get selection events etc....
.NET they haven't got to the wheel yet as far as a basic suite of UI widgets and components is concerned.
.NET menus can't even have icons in them despite that this is a W32 basic element. Java, OTOH, has had these for ages despite the rhetoric about Java being a compromise because of it's cross platform nature - the reality is quite the opposite.
.NET doesn't. And it's BASIC. Utterly primitive UI stuff that .NET *doesn't* support.
It is designed for use by DB's - it is in no way as general and flexible as a JTable. JTable is a proper MVC component which makes no assumptions about the datamodel. See JTable's custom editors, renderers, column models, selection listeners then go look at DataGrid again and tell me they're the same.
Look - I used to work doing C# development - I *wanted* to use DataGrid for general tables - I sure as hell did *not* want to reinvent the wheel - but the reality is that for
Example other than Tables: menus -
Another example: Action pattern (shared action handler between button and menus) - Delphi implements this, Java implements this,
I ended up having to write an entire Table component from scratch.
Dude, you did notice that none of those code lines was a case of
Note: it's an assignment to A.B.C, you only ever read the value of A.B.C - I didn't claim that that didn't work!
No. Not at all. When you have:
There is a relationship between map and the thing that you insert as a parameter. This relationship has meaning and the interface attaches a name to that meaning. This is the whole point of interfaces expressing a contract between objects and not being anonymous like the C example you gave.Look, you either get that documenting relations between classes is good, or you don't, if you're seriously upset about those couple of extra characters Java puts you through then you're probably not the kind of person who values maintenability over brevity anyway.
But we are talking about C#, and this is the behaviour that it has. And it cannot be implementation specific, unless you're telling me that Microsoft's implementation of C# is incorrect?
You are speaking about one specific application of function pointers, which indeed would be better solved with other concepts.
I'm talking about their use as event handlers which is 99% of their use in the entirity of C#. This is hardly a niche issue.
which BTW is also possible for Java interfaces: What does the method public void mymethod(MyInterface mi) do?
Ummm... that doesn't exist anywhere in the Java APIs.
The fact is that all of the standard APIs have well named interfaces. This means you are guaranteed that the implementation of event handlers are well named in Java by design, but because of C#'s delegate system, you have no guarantees about what the event handlers are called and you have no idea from reading the class what events it handles. In other words, C# has obliterated every trace of the contract between the event producer and the event consumer. This reduces code readability, hence maintainability and is a bad thing(tm)
A simple example where function pointer make sense is the following function(I'll use C syntax since I don't know the syntax of C# function pointers): typedef double (*real_function)(double); double integrate(real_function f, double lower_bound, double upper_bound); Here using interfaces would not only be overkill, it would actually be a disadvantage (what if your function comes from a different library which doesn't know anything at all about your interface? You'd have to make a wrapper for every single function of that class).
Ahhh... you're not familiar with C#'s syntax.... that explains a bit (since the 'disadvantage' you mention for interfaces applies exactly the same to delegates for precisely the same reason). It's not the equivallent to the C/C++ function pointer - you have to declare a delegate type first which types the pointer and an event property on the event producer which provides the event, and write the code which raises the event and marshalls its parameters - so you see, C# actually has pretty much the same amount of setup work to handle these kind of things as Java, it just does it without enforcing any kind of naming standards or documenting where the end point of an event actually is.
Unlike yourself, I have actually programmed with both Java and C# (and C, C++ as well) and I can tell you from actual experience, that delegates are a mess and Java's interfaces are a much more maintainable and clean approach.
You say interfaces are overkill because is C you have the svelt:
That's hardly a million miles away from:
Well... except that the Java version is easier to read.
Quite so. It's increadible how much the anti-java brigade fail to see the ammount of industry support for Java and claim that Java is just "Evil-Sun" (tm) 's Smash-OSS-O'Rama software.
Java is genuinely cross platform and genuinely open. FFS, the Apache foundation has as much influence on the direction of Java as does IBM, or BEA, or... Sun.
Those certifications do not prevent it being patent encumbered.
Yeah and Delphi is such a *great* environment to copy. You're right - VS .NET borrows heavily from Delphi and suffers from the same moronic view that the GUI is the sole organising structure for your code.
But... jeez, if you can't see that C# borrowed from Java you're past blind and into the "willfully stupid" catagory. C# is Java by people who just didn't get it in the first place.
Java on the desktop is superior to C#. .NET doesn't even have a table component for christ's sake (Datagrid doesn't count, it's only for use with a DB)
I've used it.
I can tell you it does *not* work well.
Pure and utter FUD
m icrosoft-deliver-64-bin-dotnet/view
.NET for 64-bit Windows 2003. Infoworld in a recent analysis explains:
.Net Framework means that the hard work many Windows developers have put into migrating to the .Net development model is for naught on Windows on Itanium.
from http://www.manageability.org/blog/stuff/why-cant-
Despite having a research and development budget that is almost 7 billion dollars a year, Microsoft apparently can't deliver
The lack of a 64-bit implementation of the
In the meantime, IT shops that wish to employ 64-bit Windows as an application server or Web services platform will be forced to revert to the older, Windows DNA (Distributed Internet Applications) environment.
In stark contrast, BEA Systems and Sun have been shipping JRockit and J2SE with Itanium support ever since JDK 1.4.1 was released. Furthermore, according to the reports 64-bit Opteron support is expected at the same time JDK 1.5 is released.
I disagree. Properties increase the number of entities you have to deal with - there used to be member values and member functions, now in C# you have memnber functions, member values and member properties. Many times in C# I find my code breaking because what I thought would be a property is implemented as a getter and setter or vice versa. This ends up wasting your time reading documentation to find which way getting the value is implemented. This is never a problem in java, it's always getMyVal();
The other thing with properties is that they look like fields, but don't work that way, for example, if B and C are implemented as properties, then this will not compile under C#:
A.B.C = someVal;
I beleive it's because the A.B bit puts the B value on the stack and assigning a value to it doesn't get back into A. At any rate, it doesn't work and to me it's pretty obvious that it should.
Function pointers and anonymous functions. This has got to be the biggest improvement over Java.
Again, I disagree. Function pointers are not a good feature. Implementing an interface in Java (which is the equivallent process to function pointers in C#) is better because the interface expresses a contract and the naming of the functions involved reflect that contract. What I mean is that when I see this in Java:
public void actionPerformed(ActionEvent ae)
I know that I've found a method fullfilling the ActionListener contract - what's more, the class involved will say implements ActionListener so the existence of the contract is explicit. With C# I could find a function like so:
public void myfunc(object sender)
And in the end, the obvious difference between Java and C# is that Java is everywhere and open and C# isn't. Yes, .NET has *parts* of it as an ECMA standard, but ECMA standards *DONT* exclude technology which is patent encumbered. Meanwhile there are dozens of open source Java implementations and Java exists on pretty much every machine under the sun.
I'd absolutely switch in a second. At the moment, why bother? You trade M$'s OS monopoly for Apple's hardware monopoly - no thanks!
5, insightful for a lie?
You *DO NOT* have to set anything to null to get it gc'd and in fact you can make your code run slower by doing so.
I know that slashbots hate java, but marking out and out lies as insightful is going a bit far with the FUD.
And when you refuse to acknowledge the numbers and chant the same old slogans, you know that language bigotry has triumphed yet again over actual fact.
Go Slashbot! Go!
the typical slashbot brain at work. well done.
Resist! It's SUN trying to ruin Linux and OS again!
It even uses Java!!!! Slashbots must fight back!
I'd say just the same to you. It's people who are pedantic about everything looking like maths that *must* have stuff written as:
a = b + c;
Personally I find that no more or less readable than:
a.equals(b.plus(c));
or:
(setq a (+ b c))
In fact, in many ways I think that the LISP approach is infinitely superior to overloaded operators in that there is never the issue of figuring out prescedence since it always follows the prefix operator pattern.
I don't see any good reason to assume that having code that looks like maths notation is superior to code which doesn't. For a start - all code is read by coders, not neccessarily by mathematicians. In addition, having one style of applying operations in your code clearly makes code which is more consistent (therefore maintainable) than code that implements many styles.
You're so engrained in mathematical notation that you seem to have accepted the fact that a = b + c is the natural way to do things.
Hey! I had to read code that some Pascal-head wrote in C, and he'd done just that.
That's really sad. You have all the functionality you want but can't progress because your favourite syntactical sugar isn't there?
... END" and I just can't live without them.
That's pathetic.
That's like saying, I've got this *great* idea but I can't code it up because I'm using C and it has brackets and not "BEGIN
It's a different language - get used to it.