Please bother to read the article or at least follow the links in the headline. The licence you refer to is the SCSL. The article refers to a new licence, the JRL. I won't bother putting in the link because it is liseted above and anyone reading this can go and follow it as you should have done.
Be aware that sun now offers its Java source code under two licences, one of which was not ordained by the FSF an an open source licence (SCSL) and the other (JRL) which has yet to be judged (although I strongly suspect it will get on the FSF's list either).
> Sometimes those bugs are dangerous (as in buffer > overflows), but if you look at your average piece > of source code long enough -- source of ANY number > of lines -- I bet you can find a bug in it.
Oh yeah?! Go on then:
printf("hello world\n");
Re:What's with all of the bellyaching about speed?
on
Does C# Measure Up?
·
· Score: 2, Informative
This is one of the specific things you can't really do with JNI and Java anymore. Java graphics is now really complicated. There's no way you'll be able to use low level OS rendering methods and have them integrate with Java2D and Swing.
Fortunately, the API is being steadily improved so the need for native methods is diminishing significantly with each version of Java. Have a look at these improvements in 1.4 over previous versions (it includes benchmarks you can run to see for yourself).
The key point here is that if you write your graphics code in pure Java, it will get faster with each new release, in many cases, without you having to lift a finger - and in 1.4, it can already take advantage of things like native hardware acceleration.
> I now expect to get inundated with responses telling me that I don't understand the real world, that companies have too much invested in their Windows infrastructure to just switch everything over to Linux on a whim, etc. To which I say: bullshit.
I've got to bite. Have you never worked in a company (I mean a "regular" business - not an IT company) where they have legacy systems? One place I worked kept their mainframe system for literally decades simply because the risk/cost of porting their key business application (written in house) to *any* other platform was too high. Even if linux attains a dominant position, it will have to interoperate with windows because companies simply cannot "throw away" key piecs of software and start from scratch. It just (usually) doesn't make economic sense. Even if the long term benfits are real, the short term risk or cost may simply be too high to even consider doing this.
> Maybe my memory is slipping, but wasn't the original problem that the MS version of Java had extra features that only worked on their version?
The key problem was not *adding* features. Microsoft changed and left out parts of the core API. For instance, they didn't include RMI at all because it "wasn't important". It is new the basis of EJBs (and thus J2EE) - but they didn't want competition with DCOM. Microsoft also made incompatible changes in the core API to break WORA.
> java was created to be a write once, run anywhere > solution. because of corporate politics and > competition, it just doesn't pull it off.
Rather just re-iterating this myth, could you give some practical examples of where you have found the cross platform ability lacking?
> the VM distribution problem on windows machines > of late
Hadn't you heard that Dell and HP are going to be putting Java on all windows machines soon? Or that the latest version on java in beta (1.4.2) can auto update itself? Or that J2ME is by far and away the major platform for mobile phones will millions of VMs already in peoples hands?
> nice idea, solid effort on the technological end > -but it's going the way of betamax and solaris.
Oh I don't know. Java still seems to be pretty popular according to scans of Google.
> It's a subtle user interface trick that they've > missed out on, although I'll admit that Java 2 is > making things a little better.
I think you're making the right point for the wrong reasons. Java itself is not slow. The VM is highly evolved - have a look at the hotspot whitepapers if you don't believe me. Even the GUI performance is quite good if implemented correctly. The main problems are that correct implementation of a Java GUI takes experience. Have a look at IntelliJ for an example of a well implemented Java GUI. Sun could help by improving the defaults and more importantly supplying "best practices" for building GUIs which they are doing. The main "implementation" problem is that memory consumption is still quite high and that can have an impact of performance. Again, Sun is working in a number of areas to alleviate this. Hopefully, the "shared VM" will be available in 1.5 some time later this year.
Java has some very good IDEs, even compared to Visual Studio. Have a look at Eclipse and Netbeans for two good open source IDEs and IntelliJ for an excellent (and not that expensive) commercial IDE.
I agree completely. I'd rather see a bill that states its desires in terms of needs (functionality, security, TCO, etc...) rather than solutions. If open source is judged to fit these criteria the best, it will win. I don't believe that open source needs or should have this sort of "positive discrimination". It should win or lose based on its merits. By the way, for those who are intersted, here's the
bill.
Slashdot is for geeks so I guess a technical solution to spam seems logical. However, is fixing this legally really that hard? First, it is a problem that has governments and corporations and users - in fact everyone except the spammers - are all on one side. It should be possible to get an international agreement to ban spam in this case. International agreements can/do work if they have support and they are realistic (for example banning CFCs worked). So the support is there - is it realistic? One of the things this group avoided is to try to define spam. But why do you need to have a precise definition? Something simple should work like:
For any mass email that is sent, the sender must be able to prove that the receieve gave his/her permission. Certain standards could be set here (eg. this permission must be opt-in for example). All bulk email must contain the details of the sending company and the option to ask said company to remove your details. Any company violating any of these rules or *aiding* a company to conceal this information (eg running an open gateway) should be fined heavily. Any country not signing up should be suject to sanctions (eg they cannot receieve international internet access or IT services from any signing country until they enforce these laws).
Now there are probably places where suggesting like this could be refined - but why is a legal solution to this problem such a wrong idea in general?!
Re:Languages for the Java VM...
on
The Future of Java?
·
· Score: 2, Informative
The chips aren't being made by Sun, but by ARM who provide jazelle. ARM is a much bigger player in the embedded market anyway. Also, look at how many mobile phones already do and will support Java and you will see why Java on silicon is alive and well.
My mum recently asked me how they could reliably destroy all the data on a hard disk they are throwing away. I suggested baking it in the oven for a while. Does anyone know what temperature would be good and for how long? Or suggest an alternative that is cheap, easy and 100% effective?
No matter what you may think of Java, it is incredibly sucessful at providing the sort of standardisation the Linux is after. While there are occasional gliches, given the scope of the APIs and the fact that the apps run on completely different OSes, Java has been incredibly sucessful in the standardisation that has been necessary to make it cross-platform. Maybe the Linux crowd could learn a few things:
1. If it already works, wrap it For example, Java often wraps existing functionality with a common API and then has SPI (Service Provider Interfaces) that funciton as "drivers" to a specific implementation. For example, the Java Naming and Directory Interface (JNDI) API allows communication with DNS, File System, LDAP, NDS, etc. Each of these naming or directory services were around before JNDI but it enables them to be used in the same way.
2. If it doesn't exist yet, standardise the interface, not the implementation Some specifications don't wrap existing functionality but create something that is completely new. However, Java trys to have its cake (standardise the solution) and eat it too (allow competition). How does it achieve this seemingly impossible miracle? The interface is typically standardised (to a degree) and the competetion occurs in the implementation. Of course, the interface typically ends up only describing a subset of the functionality that is needed so:
3. If it's too hard, leave it out of the standard interface (but revisit it later!) It's important to realise that people will have trouble agreeing on the nitty-gritty aspects of a standard. So what? There will always be implementations that push the limit and go beyond the standard. This is good and necessary. What is important is that the standardisation process is a cycle where features can be wrapped into the standard (following the first 2 principals mentioned) after they have had a run competing in the wild with each other.
4. Spec, RI, Test Kit When giving a talk, it is said that you should tell people what you are going to say, you should then say it and you should then tell them what you said. Only then will they really understand. Likewise, there are 3 components to a sucessful standard - the specification (unfortunately many standards stop here), a Reference Implementation and a Test Kit. Only with the last two can competing implementations be sure that they will be compatible. Of course, like everything in the standards process, these 3 components need to be revisited as the standard is improved.
5. Don't impose the Lowest Common Denominator For those not from the Java world, the graphics libraries in Java are a useful case study in standards evolution. AWT was originally know as the Abstract Windowing Toolkit but quickly became known as the Awful Windowing Toolkit for a few reasons, the primary one being that it only implemented those widgets that were available on all platforms. Obviously, this sucked - for example, because X/Motif had no tree control, you couldn't use AWT in Windows to do tree controls. There are currently two ways around this: Sun created Swing which takes the AWT library and emulates every platform's widgets. This has both the advantage and disadvantage of consistency: It takes a lot of work to emulate an underlying feature exactly and when the underlying feature changes, people using Swing have to wait for the Swing libraries to be updated. The alternative, SWT/JFace from IBM's Eclipse project uses a cross between the AWT and Swing approach. It works like AWT in that it renders widgets natively but it doesn't restrict itself to the Lowest Common Denominator. Instead, it only uses the Swing "emulation" approach if the given widget does not exist on the underlying platform. While these APIs only refer to GUIs, the general architectural problem is the same when creating standards that wrap other standards (point 1) and need to be considered carefully.
6. Motivation The following is my personal opinion but I am sure many people will agree: Creating specifications, reference implementations and test kits is boring. Maintaining them is a pain. Trying to get people to agree even on minimum standards, especailly when people have firmly entenched beliefs is difficult to say the least. In other words, making standards is boring, painful and hard. It is also very useful because a good standard makes everyone's life easier. Think about some things that are pretty well standardised - the way you make a phone call for example. Imagine if not all phones had the same symbols. Imagine if the nozzels at certain service stations only fitted certain models of cars.
Why are these things standardised if they are boring, painful and hard to do? Personally, I think economics/money has a lot to do with it. However, I've already ranted enough here so I'll leave that for another post.:)
The Ant front page deals with the issue of makefiles:
-------- Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on. --------
To this I would add that it is not only a standard amongst open source IDEs for Java but practically all major commercial IDEs support Ant as well.
> What you really need is generics (as in C++
> templates). Java collections are vile, since they
> suffer from type loss even when used with "real"
> objects. I'm surprised that didn't come into this
> top ten; it's a major language deficiency.
I can think of 2 reasons why they weren't in this article:
Generics will will be included in Tiger (1.5)
They don't break either source or binary compatibility (at least not the way Sun is going to do them).
You can even download the beta compiler and give it a whirl if you're eager.
Java Generics
Sounds like you have C++ envy. Maybe you should change languages if you really need all that. Java works quite well for most things without any of these features.
I think Word even gets around this - it tells you what the grammatical error it thinks has occurred. The thing is, my french is good enough to know if the grammar checker is right - but it's still far more difficult for me to _see_ the errors myself in French. If I'm reading English, grammatical errors tend to "jump out" more.
For any transaction where something ther than hard cash is accepted (and I am using transaction is a broad sense here, such as being able to enter a secured area for exampleas well as making a purchase), it is necessary to authenitcate the client, be it with a credit card number, signature, photo id, fingerprint, retinal scan, facial scan, DNA test, some other mechanism or a combination.
In all such transactions: - Authentication is necessary. (ie the transaction requires at least one of these mechanisms). - All the authentication methods are vulnerable - no security mechansim is perfect. - All of these could be subverted by to invade your privacy.
However, if you can't use cash for your transaction or you prefer not to for the convenience, you've got to live with the authentication tradeoffs.
As pointed out, authentication is necessary for many transactions - there is no escaping this fact. So the best questions when evaluating the technology is RELATIVE to its alternatives.
So fingerprint readers can be spoofed easily (assuming you can get a copy of the finger you want to copy, which is not necessarily easy). Well credit cards numbers can be obtained and used fradulently; signatures can be forged.
None of these mechanisms are fundamentally good or bad. However, I believe having alternatives IS good for two reasons:
1. It provides competition between different authentication mechanisms so that people get a choice in what security/convenience tradoff they want to make.
2. Having multiple authentication mechanisms automatically increases the diversity of the authentication infrastructure which means that it is harder for an organisation to subvert because they need to coordinate your identity across multiple systems rather than having a single one.
In the scenario described (and many previous articles on the same subject at Slashdot), these new systems augment rather than replace existing ones. As long as this continues to be the case, I am more than happy for these mechanisms to exists and compete.
I disagree - while I am quite happy typing a document in English (my native language) without the help of a grammar checker but when I am hammering out something in French, I find it invaluable. It is very easy to miss little things (accents, incorrect conjugations, agreement of participles or adjectives) very easily when it is not your native language. I am sure this is just as significant for people who use the grammar checker when English is not their first language.
I fully agree with the original poster - a good (and in my case French) grammar checker is the only reason why I cannot switch to using OpenOffice full time.
Re:Itterative Development/Refactoring
on
Agile Modeling
·
· Score: 1
Maybe test-driven development may help keep you more focused on what you really need to code? If what you're writing doesn't help make your tests work, don't write it.
Re:I was just reading this at the bookstore...
on
Agile Modeling
·
· Score: 1
I agree with almost all of your points here. Especially iterative development: it is simply _impossible_ for the programmer, designer, architect or client to know all of the requirements perfectly in advance for any reasonable size project. Also, some requirements change - it's a fact of life. Instead of getting angry about this, simply accept it and enable a mechanism in you development process to deal with it - that's what iterative development is all about.
Where I disagree somewhat is with "deliver the most value-producing code first". I would prefer to emphasise:
Deliver the highest risk code first.
For example, if there is a new tool, technology, system, or whatever that you haven't used before and is critical for the project, this is probably the highest risk part. If the project, has strict performance requirements, this may be the highest risk part that requires a load testing framework to be established early and used rigorously thoughout the project. While it is nice politically to give users useful code ASAP, this may or may not be a high risk - if it is, of course, do it first. I really believe that having prioritys being "risk-driven" rather than "user-driven" is a more correct approach.
Slashdot Mirror
Please bother to read the article or at least follow the links in the headline. The licence you refer to is the SCSL. The article refers to a new licence, the JRL. I won't bother putting in the link because it is liseted above and anyone reading this can go and follow it as you should have done.
Be aware that sun now offers its Java source code under two licences, one of which was not ordained by the FSF an an open source licence (SCSL) and the other (JRL) which has yet to be judged (although I strongly suspect it will get on the FSF's list either).
> Sometimes those bugs are dangerous (as in buffer
> overflows), but if you look at your average piece
> of source code long enough -- source of ANY number
> of lines -- I bet you can find a bug in it.
Oh yeah?! Go on then:
printf("hello world\n");
This is one of the specific things you can't really do with JNI and Java anymore. Java graphics is now really complicated. There's no way you'll be able to use low level OS rendering methods and have them integrate with Java2D and Swing.
Fortunately, the API is being steadily improved so the need for native methods is diminishing significantly with each version of Java. Have a look at these improvements in 1.4 over previous versions (it includes benchmarks you can run to see for yourself).
The key point here is that if you write your graphics code in pure Java, it will get faster with each new release, in many cases, without you having to lift a finger - and in 1.4, it can already take advantage of things like native hardware acceleration.
> I now expect to get inundated with responses telling me that I don't understand the real world, that companies have too much invested in their Windows infrastructure to just switch everything over to Linux on a whim, etc. To which I say: bullshit.
I've got to bite. Have you never worked in a company (I mean a "regular" business - not an IT company) where they have legacy systems? One place I worked kept their mainframe system for literally decades simply because the risk/cost of porting their key business application (written in house) to *any* other platform was too high. Even if linux attains a dominant position, it will have to interoperate with windows because companies simply cannot "throw away" key piecs of software and start from scratch. It just (usually) doesn't make economic sense. Even if the long term benfits are real, the short term risk or cost may simply be too high to even consider doing this.
> Maybe my memory is slipping, but wasn't the original problem that the MS version of Java had extra features that only worked on their version?
The key problem was not *adding* features. Microsoft changed and left out parts of the core API. For instance, they didn't include RMI at all because it "wasn't important". It is new the basis of EJBs (and thus J2EE) - but they didn't want competition with DCOM. Microsoft also made incompatible changes in the core API to break WORA.
And as soon as I can buy a scanner I'm getting one!!! No more lost keys, lost wallet, lost camera. Only problem - what if I loose the scanner...?
> This is not a troll.
> Why does anyone use Java, ever?
*snip*
I'm having real problems reconciling your first two sentences.
> java was created to be a write once, run anywhere
> solution. because of corporate politics and
> competition, it just doesn't pull it off.
Rather just re-iterating this myth, could you give some practical examples of where you have found the cross platform ability lacking?
> the VM distribution problem on windows machines
> of late
Hadn't you heard that Dell and HP are going to be putting Java on all windows machines soon? Or that the latest version on java in beta (1.4.2) can auto update itself?
Or that J2ME is by far and away the major platform for mobile phones will millions of VMs already in peoples hands?
> nice idea, solid effort on the technological end
> -but it's going the way of betamax and solaris.
Oh I don't know. Java still seems to be pretty popular according to scans of Google.
> It's a subtle user interface trick that they've
> missed out on, although I'll admit that Java 2 is
> making things a little better.
I think you're making the right point for the wrong reasons. Java itself is not slow. The VM is highly evolved - have a look at the hotspot whitepapers if you don't believe me. Even the GUI performance is quite good if implemented correctly. The main problems are that correct implementation of a Java GUI takes experience. Have a look at IntelliJ for an example of a well implemented Java GUI. Sun could help by improving the defaults and more importantly supplying "best practices" for building GUIs which they are doing. The main "implementation" problem is that memory consumption is still quite high and that can have an impact of performance. Again, Sun is working in a number of areas to alleviate this. Hopefully, the "shared VM" will be available in 1.5 some time later this year.
Java has some very good IDEs, even compared to Visual Studio. Have a look at Eclipse and Netbeans for two good open source IDEs and IntelliJ for an excellent (and not that expensive) commercial IDE.
I agree completely. I'd rather see a bill that states its desires in terms of needs (functionality, security, TCO, etc...) rather than solutions. If open source is judged to fit these criteria the best, it will win. I don't believe that open source needs or should have this sort of "positive discrimination". It should win or lose based on its merits. By the way, for those who are intersted, here's the bill.
Slashdot is for geeks so I guess a technical solution to spam seems logical. However, is fixing this legally really that hard? First, it is a problem that has governments and corporations and users - in fact everyone except the spammers - are all on one side. It should be possible to get an international agreement to ban spam in this case. International agreements can/do work if they have support and they are realistic (for example banning CFCs worked). So the support is there - is it realistic? One of the things this group avoided is to try to define spam. But why do you need to have a precise definition? Something simple should work like:
For any mass email that is sent, the sender must be able to prove that the receieve gave his/her permission. Certain standards could be set here (eg. this permission must be opt-in for example). All bulk email must contain the details of the sending company and the option to ask said company to remove your details. Any company violating any of these rules or *aiding* a company to conceal this information (eg running an open gateway) should be fined heavily. Any country not signing up should be suject to sanctions (eg they cannot receieve international internet access or IT services from any signing country until they enforce these laws).
Now there are probably places where suggesting like this could be refined - but why is a legal solution to this problem such a wrong idea in general?!
The chips aren't being made by Sun, but by ARM who provide jazelle. ARM is a much bigger player in the embedded market anyway. Also, look at how many mobile phones already do and will support Java and you will see why Java on silicon is alive and well.
My mum recently asked me how they could reliably destroy all the data on a hard disk they are throwing away. I suggested baking it in the oven for a while. Does anyone know what temperature would be good and for how long? Or suggest an alternative that is cheap, easy and 100% effective?
No matter what you may think of Java, it is incredibly sucessful at providing the sort of standardisation the Linux is after. While there are occasional gliches, given the scope of the APIs and the fact that the apps run on completely different OSes, Java has been incredibly sucessful in the standardisation that has been necessary to make it cross-platform. Maybe the Linux crowd could learn a few things:
:)
1. If it already works, wrap it
For example, Java often wraps existing functionality with a common API and then has SPI (Service Provider Interfaces) that funciton as "drivers" to a specific implementation. For example, the Java Naming and Directory Interface (JNDI) API allows communication with DNS, File System, LDAP, NDS, etc. Each of these naming or directory services were around before JNDI but it enables them to be used in the same way.
2. If it doesn't exist yet, standardise the interface, not the implementation
Some specifications don't wrap existing functionality but create something that is completely new. However, Java trys to have its cake (standardise the solution) and eat it too (allow competition). How does it achieve this seemingly impossible miracle? The interface is typically standardised (to a degree) and the competetion occurs in the implementation. Of course, the interface typically ends up only describing a subset of the functionality that is needed so:
3. If it's too hard, leave it out of the standard interface (but revisit it later!)
It's important to realise that people will have trouble agreeing on the nitty-gritty aspects of a standard. So what? There will always be implementations that push the limit and go beyond the standard. This is good and necessary. What is important is that the standardisation process is a cycle where features can be wrapped into the standard (following the first 2 principals mentioned) after they have had a run competing in the wild with each other.
4. Spec, RI, Test Kit
When giving a talk, it is said that you should tell people what you are going to say, you should then say it and you should then tell them what you said. Only then will they really understand. Likewise, there are 3 components to a sucessful standard - the specification (unfortunately many standards stop here), a Reference Implementation and a Test Kit. Only with the last two can competing implementations be sure that they will be compatible. Of course, like everything in the standards process, these 3 components need to be revisited as the standard is improved.
5. Don't impose the Lowest Common Denominator
For those not from the Java world, the graphics libraries in Java are a useful case study in standards evolution. AWT was originally know as the Abstract Windowing Toolkit but quickly became known as the Awful Windowing Toolkit for a few reasons, the primary one being that it only implemented those widgets that were available on all platforms. Obviously, this sucked - for example, because X/Motif had no tree control, you couldn't use AWT in Windows to do tree controls. There are currently two ways around this: Sun created Swing which takes the AWT library and emulates every platform's widgets. This has both the advantage and disadvantage of consistency: It takes a lot of work to emulate an underlying feature exactly and when the underlying feature changes, people using Swing have to wait for the Swing libraries to be updated. The alternative, SWT/JFace from IBM's Eclipse project uses a cross between the AWT and Swing approach. It works like AWT in that it renders widgets natively but it doesn't restrict itself to the Lowest Common Denominator. Instead, it only uses the Swing "emulation" approach if the given widget does not exist on the underlying platform. While these APIs only refer to GUIs, the general architectural problem is the same when creating standards that wrap other standards (point 1) and need to be considered carefully.
6. Motivation
The following is my personal opinion but I am sure many people will agree: Creating specifications, reference implementations and test kits is boring. Maintaining them is a pain. Trying to get people to agree even on minimum standards, especailly when people have firmly entenched beliefs is difficult to say the least. In other words, making standards is boring, painful and hard. It is also very useful because a good standard makes everyone's life easier. Think about some things that are pretty well standardised - the way you make a phone call for example. Imagine if not all phones had the same symbols. Imagine if the nozzels at certain service stations only fitted certain models of cars.
Why are these things standardised if they are boring, painful and hard to do? Personally, I think economics/money has a lot to do with it. However, I've already ranted enough here so I'll leave that for another post.
A+
The Ant front page deals with the issue of makefiles:
--------
Why another build tool when there is already make, gnumake, nmake, jam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.
Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.
Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.
Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an task that allows different commands to be executed based on the OS that it is executing on.
--------
To this I would add that it is not only a standard amongst open source IDEs for Java but practically all major commercial IDEs support Ant as well.
> While their motivation may be purely profit-driven
Um - aren't pretty much all (profitable) companies profit-driven?
I mean Microsoft, Red Hat, Sun, IBM, etc - none of them are charities right?
Generics will will be included in Tiger (1.5)
They don't break either source or binary compatibility (at least not the way Sun is going to do them).
You can even download the beta compiler and give it a whirl if you're eager. Java Generics
Java + Multiple Inhereitence + Operator Overloading + Direct Memory Access.
Sounds like you have C++ envy. Maybe you should change languages if you really need all that. Java works quite well for most things without any of these features.
I think Word even gets around this - it tells you what the grammatical error it thinks has occurred. The thing is, my french is good enough to know if the grammar checker is right - but it's still far more difficult for me to _see_ the errors myself in French. If I'm reading English, grammatical errors tend to "jump out" more.
For any transaction where something ther than hard cash is accepted (and I am using transaction is a broad sense here, such as being able to enter a secured area for exampleas well as making a purchase), it is necessary to authenitcate the client, be it with a credit card number, signature, photo id, fingerprint, retinal scan, facial scan, DNA test, some other mechanism or a combination.
In all such transactions:
- Authentication is necessary. (ie the transaction requires at least one of these mechanisms).
- All the authentication methods are vulnerable - no security mechansim is perfect.
- All of these could be subverted by to invade your privacy.
However, if you can't use cash for your transaction or you prefer not to for the convenience, you've got to live with the authentication tradeoffs.
As pointed out, authentication is necessary for many transactions - there is no escaping this fact. So the best questions when evaluating the technology is RELATIVE to its alternatives.
So fingerprint readers can be spoofed easily (assuming you can get a copy of the finger you want to copy, which is not necessarily easy). Well credit cards numbers can be obtained and used fradulently; signatures can be forged.
None of these mechanisms are fundamentally good or bad. However, I believe having alternatives IS good for two reasons:
1. It provides competition between different authentication mechanisms so that people get a choice in what security/convenience tradoff they want to make.
2. Having multiple authentication mechanisms automatically increases the diversity of the authentication infrastructure which means that it is harder for an organisation to subvert because they need to coordinate your identity across multiple systems rather than having a single one.
In the scenario described (and many previous articles on the same subject at Slashdot), these new systems augment rather than replace existing ones. As long as this continues to be the case, I am more than happy for these mechanisms to exists and compete.
I disagree - while I am quite happy typing a document in English (my native language) without the help of a grammar checker but when I am hammering out something in French, I find it invaluable. It is very easy to miss little things (accents, incorrect conjugations, agreement of participles or adjectives) very easily when it is not your native language. I am sure this is just as significant for people who use the grammar checker when English is not their first language.
I fully agree with the original poster - a good (and in my case French) grammar checker is the only reason why I cannot switch to using OpenOffice full time.
Maybe test-driven development may help keep you more focused on what you really need to code? If what you're writing doesn't help make your tests work, don't write it.
I agree with almost all of your points here. Especially iterative development: it is simply _impossible_ for the programmer, designer, architect or client to know all of the requirements perfectly in advance for any reasonable size project. Also, some requirements change - it's a fact of life. Instead of getting angry about this, simply accept it and enable a mechanism in you development process to deal with it - that's what iterative development is all about.
Where I disagree somewhat is with "deliver the most value-producing code first". I would prefer to emphasise:
Deliver the highest risk code first.
For example, if there is a new tool, technology, system, or whatever that you haven't used before and is critical for the project, this is probably the highest risk part. If the project, has strict performance requirements, this may be the highest risk part that requires a load testing framework to be established early and used rigorously thoughout the project. While it is nice politically to give users useful code ASAP, this may or may not be a high risk - if it is, of course, do it first. I really believe that having prioritys being "risk-driven" rather than "user-driven" is a more correct approach.
Have a look at this.