What's at the top of your list for changes to Java?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 138 of 138.

• Commercial concerns must not be ignored!
  2006-08-28 05:19:39  Infernoz [Reply | View]
  
  
  Firstly, never, ever assume that you can have unlimited resources, that is childish and unreasonable! Engineering, financial, operational, social and cultural issues can and do delay resource upgrades, often for many years!
  
  10, 9 & 4. This would be suicide for a programming language, from a commercial and OSS library viewpoint, thus is not a smart suggestion.
  
  8. Primitives are needed for efficent use of the CPU and memory, especially on slow or heavily loaded commercial machines. Putting huge extra load on the Garbage Collection, memory resources and the method call layer is not a sane suggestion. It is also not smart for the compiler to pick the data-type given this could cause unpredictable value overflow/underflow or performance problems if the wrong data-type was picked. Enums are a great idea (for new APIs or methods), but not where you have combined flag field values (an API design flaw).
  
  7. There should be an application visible JVM to enable 4 byte characters/strings, with a system property to signal this feature, so that the JVM and application can switch to 4 byte character optimised libraries and convert constant character/string values, when classes are loaded. It would be stupid to enforce the change in byte-code because it would not be commercially viable.
  
  6. stop() is critical for killing hanging or badly coded threads e.g. threads which ignore interrupt(), so must be retained in some form so that limited resources can be freed. Doubles and longs are a JVM concern, if you don't like the atomic behaviour put them in a synchronized object. Anyhow I dislike floating point data-types like doubles because they are so vunerable to decimal rounding errors and lack rounding rules, unlike BigDecimal, not a good thing when money is involved!
  
  5. XML is suited for some uses, however it is very slow to parse, can be huge and has to be read from the start! I work with data from an XML based system and have seen quite serious performance problems with it, because of huge XML data size (in databases (uncompressed) and across networks (compressed)) and high marshalling/unmarshallings costs! Use of other formats, like CSV, is much more efficient in databases and networks, and they tend to compress better too. IMHO use of XML for settings files is useful in some cases, however I can often do better using standard properties and a Properties sub-class supporting heirachical text propeties e.g. store.9999.tills=2, store.9999.name=obvious
  
  3. ArrayList is broken, because like many other java.* classes it has too many private properties, this makes it useless for some applications which require ordered lists e.g. some Swing lists applications! I would like to see all Lists include a locally optimised sort method and an ordered add method, because the Collections.class methods are often far too costly!
  
  2. IO should be improved and this is happinging already, however I don't want File changed, tieing access to physical files would cause all kinds of resource and locking issues, you really don't want to go there!
  
  1. Shows that you are naive about ClassLoader security and the need to isolate dynamic class compilation and loading for application like web servers etc.
  
  I like some of your books, however they are not perfect, some of the IO books are flawed e.g. copying files with java.io streams and a byte, instead of java.nio FileChannels, yuck, I REALLY hate cruft like that, at the very least use a large byte array rather than a single byte!
  
  

• why we need Serialization ?
  2005-03-15 04:47:16  senthil_ak [Reply | View]
  
  
  In java we have Serialization to read and write objects . I want a specific reason why we need Serialization. Plz do mail me on that on
  senthil

• No
  2004-07-20 21:41:48  grlea [Reply | View]
  
  
  My comments on some of your suggestions:
  
  10. Delete all deprecated methods, fields, classes, and interfaces.
  
  Yeah, I'd like this to happen, but it's easy to see why it hasn't.
  Sun has a major pre-occupation with backwards-compatibility, and while it seriously annoys me sometimes, I'm sure there's people that have been very thankful for it (probably those who write software for money and don't want to re-write it with every JDK release).
  
  9. Fix incorrect naming conventions.
  
  Hindsight is always 20/20.
  While it'd be nice if some things were named differently, I don't think any programmer who has to maintain any program would be happy about if names were changed.
  
  8. Eliminate primitive data types.
  
  Your argument for doing this is merely that "Java would finally become a pure object-oriented language."
  I don't know that anyone really cares about that, and I don't think it's warranted to make such a change just for the sake of perfection.
  The most practical problem of primitive->Object conversion and vice-versa is covered by auto-boxing in J2SE 1.5.
  
  5. Convert file formats to XML.
  
  XML is not good on toast, cannot drive you to work, and is of very little use during a triple bypass operation. Shock horror: it's not the solution to everything.
  Why try and represent properties files, plain olf name-value pairs, with a hierarchical data format!? Why print the number 2147483647 into 10 bytes (UTF-8) when it can be serialised in 4 bytes (int)?
  
  4. Ditch the AWT.
  
  "Two GUI APIs is one too many."
  I'm sure if you mention this to any Eclipse developer they'll realise the futility of their ways and burn all known copies of SWT post-haste.
  
  "Most Java developers ..." were not contacted by the author, but he has read their minds and feels compelled to speak on their behalf.
  
  Seriously, though, there are people who still use AWT (even for new projects) and swear by it.
  You can't just delete everything that you, or even "most developers", don't use.
  
  1. Redesign class loading from scratch, this time with human interface factors in mind.
  
  Perhaps the error messages are confusing and the concept a little complicated, but the power is unmatched. We're computer scientists here, not primates. People who need to use class loaders and know how to have done amazing things with them.
  
  Summing Up
  
  Basically, the suggested "way forward" here is to spend a lot of time cleaning up, remove things that you don't use (even though others might find them useful), change some things to be the way you think they should be, throw both backwards- and upwards-compatibility to the wind (making every library ever written useless) and start from scratch again. And you can't understand why Sun doesn't want to do this? If anyone suggested taking this approach on their commercial projects, they'd be laughed at all the way to the welfare office. I believe Java is moving into the future and will continue to do so without any of the changes you've suggested. None of the changes you have suggested would make Java better for me, most of them would annoy me, and some of them would concern me greatly if they happened.

• Almost forgot... Connection.close() throws SQLException :-(
  2004-01-14 11:36:22  anonymous2 [Reply | View]
  
  
  How about non-inheritable public static methods for Interfaces?
  
  One thing that's always annoyed me is the hard division between abstract classes and interfaces. Abstract classes obviously can't be multiply inherited, and interfaces aren't allowed to contain methods.
  
  But wait a second... interfaces ARE allowed to contain public static final objects! So why not public static final methods too? Such methods would NOT be inherited by implementing objects or Interfaces extending the original. Essentially, it would be a convenient way to package utility methods without getting tangled up in the evils of multiple inheritance. And I can think of one GREAT place to start using them first... java.sql.Connection.
  
  To just about everyone's great annoyance, Connection.close() throws SQLException. OK, yes, there are cases where you'd want to catch an exception thrown while closing a connection where, say, commits happen only upon closure. On the other hand, they make a HUGE mess with cleanup code, like the following:
  
  Connection conn = null;
  try {
  conn = myDataSource.getConnection();
  // ... do stuff
  }
  catch (SQLException e) {
  // most likely due to error with Statement or ResultSet...
  }
  finally {
  try {
  if (connection != null) { conn.close(); }
  }
  catch (SQLException shutUpAlready) {}
  }
  
  What Sun SHOULD have done is to make a second SQL-related Exception -- SQLRuntimeException -- and made Connection.close() throw THAT one instead. Then, people who need to care about catching exceptions that indicate transaction failure could do it, but people just trying to clean up the connections inside a finally {} block while the rest of the class goes down in flames wouldn't have to go through the idiocy of having a try/catch block inside a finally block.
  
  Now, as for the changes I'd want Sun to make to Connection:
  
  public interface Connection {
  
  // interface definitions go here
  
  // added by Sun...
  public static Throwable close(Connection conn) {
  try {
  conn.close();
  }
  catch (Throwable t) {
  return t;
  }
  }
  }
  
  According to the proposed rules, Connection.close() would ONLY be callable as... Connection.close(). It wouldn't be inherited by Connection-implementing objects. So if class Foo implements Connection, and 'bar' is a Foo object, the following would be invalid:
  
  Foo.close(bar);
  bar.close(bar);
  
  Of course, Foo's creator could always write his own public static close(Connection) method, but it would have nothing whatsoever to do with Connection's, nor would it be inherited by Foo-implementing objects any more than Connection's method would be inherited by Connection-implementing objects. So bar.close(bar) would be invalid in any case, as would a call to this.close(Connection) from within a Connection-implementing object.
  
  
  

• Fix String handling once and for all...
  2004-01-14 10:42:34  anonymous2 [Reply | View]
  
  
  There's *no* good reason why Java programmers testing two Strings for equivalence should have to put up with abominations like:
  
  if ((foo != null) && (foo.equals("bar"))) {}
  
  I challenge anyone to think of a meaningful scenario when a Java programmer is EVER likely to care whether two Strings that render out to identical sequences of characters LITERALLY came from the same definition in the source code.
  
  At the very least, the String class' equality methods should all have static variants that take two String objects as arguments and treat null & zero-length as "blank". For example...
  
  if (String.equals(foo, "bar")) {}
  
  if (String.equals(foo, null)) {}
  
  if (String.equals(foo, "")) {}
  
  The last two evaluating to true if foo's value is null OR blank, the first returning false if foo's value is anything besides "bar" INCLUDING null or blank.
  
  I'd even go so far as to suggest that String (or at least StringBuffer) should have a constructor that takes a File object as its argument & decides how to handle it based upon the presence or absence of a BOM -- no BOM, use the default local encoding (most likely some variant of ISO-8859); BOM, sniff the unicode variant and go with it; null or nonexistent, return a blank string (if the user REALLY cared whether it's blank or null, he would have explicitly tested the File object anyway).
  
  Alternatively, annoying things like UnsupportedEncodingException should be made unchecked. I mean, for god's sake, if "UTF-8" or the system default encoding should, through some catastrophe, EVER be unsupported, the program has FAR bigger problems to deal with. Make it extend RuntimeException, and programmers who need something more exotic like Shift-JIS or ISO-8859 with Scandinavian encoding that might actually fail can catch it.

• Top Three New Features
  2004-01-08 06:00:30  anonymous2 [Reply | View]
  
  
  1. Unsigned primitives.
  
  2. Pass-by-reference.
  
  3. Comma operator.

• Multiple return values
  2004-01-08 05:06:06  anonymous2 [Reply | View]
  
  
  Imho they should add to Java the posibility to return more than one value. Now you have a few ways how to do it, but.. you need to write a lot of code to do one simple thing and it is far from being called effective. So why don't have Java for example this posibility:
  
  (int, int, int) xform(int x, int y, int z) ...
  
  ...
  ...
  
  (r, g, b) = xform(x, y, z);
  (l, a, b) = xform(xform(x, y, z));
  
  It is simple, nice, typesafe..
  
  Btw you can vote for it here ;-)
  
  http://developer.java.sun.com/developer/bugParade/bugs/4222792.html
  
  And second thing - keep primitive types.. Did you ever try to multiply matrix realized as array of immutable double wrappers? It's awfully slow and consumpting big amount of memory..

• Garbage Collector
  2004-01-08 02:44:33  anonymous2 [Reply | View]
  
  
  I say get rid of the garbage collector and add destructors
  that will make applications more reliable

• Please don't slow down Java more that it already is!
  2004-01-08 02:14:39  anonymous2 [Reply | View]
  
  
  "I anticipate resistance to these ideas from the performance-at-any-cost crowd".
  Well, I guess I'm among that crowd. And I guess you never tried to write scientific computing applications in Java. Apps that manage millions of number, or millions of String (such as the GIS applications we are trying to write at the geotools
  project). Otherwise you'll know that:
  * 8 bytes object header overhead is a big problem,
  so the compiler implementation should really do
  a hard work at avoiding the object version of
  primitive to get reasonable performance;
  * 4 bytes per char strings cannot be optimized
  and are something that would kill the
  performance of text processing apps, reduce
  cache efficiency, and the like. It really seems
  that you don't play with big data sets, or
  you'll know that getting out reasonable speed
  with modern computers is still a hard job
  * java math is really slow, see for example:
  http://www.coyotegulch.com/reviews/almabench.html
  
  If I could ask something for Java3, it would really be better performance optimization, especially for scientific applications and/or small devices. Pretending that everyone has a big
  machine is not the way to build a good language

• backwards compatibility, etc.
  2004-01-07 10:09:40  anonymous2 [Reply | View]
  
  
  Backwards compatibility can be a good thing too, even if there is some ugliness. Anybody who programs for Unix/Linux can count on the fact that C code that was written 20 years ago still works today. This way tools can be built on one another without having to constantly rewrite them due to APIs becoming obsolete. You mention the Mac as drawing lines in the sand, I'm surprised there is no mention of Windows. Look how many Windows APIs have become obsolete and how many programmers have to learn new ones. This strategy is good for the companies providing the APIS, and perhaps even good for the end user, but it sucks for developers.
  
  If you use a deprecated method or class, you'll get a warning. a good IDE like eclipse makes it easy to get to the javadoc comment that then explains what you should use instead. Sometimes using those deprecated APIs are handy for quick and dirty code because they generally do it in one line, and they tend to work right if you are an english/us locale, latin-1 character set, etc., which in many cases people are. I say this just as I finished getting rid of all my calls to deprecated methods...
  
  I think many of the things you mentioned were not really that important, a few were. You could have also picked a few of .net's features that are improvements over java - avoiding classpath hell with versioned assemblies, unsigned as well as signed types, hey, maybe even delegates if you like that kind of thing. Pretty much any of those features top your list as far as I can tell.

• Thread support bothers me
  2003-10-17 07:39:19  anonymous2 [Reply | View]
  
  
  I may be misguided on this but one of the things that bothers me the most about Java threading is the fact that you cannot stop or suspend a thread. To me that's a serious shortcoming. The reason is that there are too many things out of the realm of control of you the programmer. Perhaps its a poorly written api you have to interface or maybe the db hangs. Yes we like to eliminate these things from happening. However, part of the understanding of writing enterprise software is the understanding that these things can and will happen and our software needs to be prepared to handle it.
  
  Without this functionality I must assume that my all my blocking calls will always return which is like saying I'll never have a bug again. Because of this I can no longer clean up my thread, release it, rebuild a new one, and have my app keep on trucking. Instead I have to come in at 3:00AM in the morning and restart the process or leave the dead threads hanging.
  
  I also understand that cleaning up is a touchy issue. Threads in general are tough to do and so is cleaning up there state but it is something that programmers should learn if they venture into threads. I've written such code in C++ that has allowed my apps to become very durable and survive most any nasty situation.
  
  In my opinion you should be able to stop or kill, throw a exception in the thread, clean up any state issues you have, and let the thread release or continue back processing.
  
  Anyhow my humble 2 cents!

• Benefits
  2003-08-27 07:37:30  anonymous2 [Reply | View]
  
  
  Much of what has been suggested doesn't provide substantive benefits. Prattling on about 'ln' rather than 'log', for instance, doesn't make anyone more productive. Discarding deprecated API doesn't provide benefits either: there is no advantage whatsoever to making a bunch of stuff that most folks no longer use unavailable, it just gives Java opponents something to beat Java with.
  
  Some aspects of Java that work perfectly well are misconstrued by some contributors to this list. Having every Object synchronizable is not a bad thing. For example, if you need to synchronize access to a particular ArrayList, it makes a lot of sense to make _it_ the Object we synchonize on. Anyone who doesn't like this doen't need to use it: use a global object for instance...yes, Java has global objects, they are public static fields:
  
  public class SyncKeeper
  {
  public static Object s_objSync = new Object();
  }
  
  // ...
  
  synchronize (SyncKeeper.s_objSync)
  {
  // ...
  }
  
  Or, for the loonies:
  
  public class SyncKeeper
  {
  private static Object s_objSync = new Object
  ();
  
  public static Object sync()
  {
  return s_objSync;
  }
  }
  
  // ...
  
  synchronize (SyncKeeper.sync())
  {
  // ...
  }
  
  
  What is important:
  
  - class path, class path, class path: as someone else pointed out, a system-wide registry would be helpful. Generally, the class path issue is thorny but with directed effort, e.g. a JSR, a good solution could be found (anyone who thinks that the class path is not a problem, hasn't done much Java development).
  
  - make Java more accessible by providing 'cushioned environments' for development. Customers that use my software tool find the mechanics of Java difficult so in version 2 I moved the entire tool to Eclipse and I take care of issues such as the class path by calling into the Eclipse API in the background, result: the tool is much easier to use.
  
  - Don't waste time with trivia.
  
  
  

• That's the 10 Reasons That I Should Throw Away Java Now, To Embrace C?
  2003-06-30 08:42:11  anonymous2 [Reply | View]
  
  
  If Java changes to "Java 3" like this, and one learns the "new" features of "Java 3". Who could guarantee that those "new" features of "Java 3" will not be thrown away in future release of Java, e.g., "Java 4"? In that sense, why should we(a company, etc.) learn & use to-be-out-of-dated "Java 3" now instead of waiting for "Java 4" to come out and learn then?
  
  First I respect your effort for writing such a good article, really.
  
  I admit that your article is quite good in the sense that you found all the problems while I couldn't find all of them, because at least I like some of them.
  
  But did you ever think of the end-users of previous version of Java? Will they support (ie., upgrade to) new version you designed? How could they support you if you first did not support them(be not compatible with old version of Java)!
  
  I could NOT find a good reason that I should NOT learn Java 2 now, before I read your article.
  
  You could be an extraordinary programmer, but not a good businessman.
  
  My alternatice solutions: Embrace a new language, or design & use a full new language!
  
  Although my comment is not from a pure technical point of view, but I hope that readers could got something from it.
  
  Please forgive my rudiness, if this comment makes annoyance to you.
  
  --------
  A SJP

• minor hitches/adjustments
  2003-06-17 15:44:07  anonymous2 [Reply | View]
  
  
  things to improve java:
  improve some of the function naming (as mentioned earlier, length() or size() )
  add kill() or something to network/ files streams etc, that isn't allowed to throw exceptions, for "panic code" - exception handlers, when your trying to cleanly kill a process are just irratating
  enable short in for loops (it autocasts to an int then crashes)
  make casting a left hand expression, not right handed. ie
  MyType t (MyType)=myVector.get(35);
  improve the docs (or the code) for the wait/notify pair.
  enable the system.properties thingie to be used the way you can with BASH environments (or sh, ksh etc)
  
  

• Perfect way to clean up:
  2003-05-12 08:19:17  anonymous2 [Reply | View]
  
  
  I think, sun should drop all deprecated shit from their language in 3.0, but the java virtual machine should be able, to automatically convert "old" code to new code. I think, this conversion algorithm can take place in the situation, where fields are not found and some internal exception would be thrown instead. They could just lookup the value, those field had formerly. The read class files, but now they are able to alter "old style" class files to new ones.
  
  Triing this, old code in .class-files would still be able to run, but not to compile. Compiling it again needs to change it.
  
  The proposed changes should be listened on their homepage, and the compiler should be made able to give a link to the change, or to actually propose a change.
  
  thanx for your audience.

• As long as we have JNI we need Thread.stop()
  2003-05-01 07:01:00  anonymous2 [Reply | View]
  
  
  I work on something that could be described as a specialized application server. It runs business rules in a multithreaded environment. The rules can be written in Java or in C using JNI calls. There are seperate watchdog threads that keep track of the rule running threads and stop them if the rules are taking too long. Thread.interrupt works OK for the Java rules, but often you need to do a Thread.stop for the C rules if they get in some kind of infinite loop or if they're waiting too long for I/O.

• Too good to be true.
  2003-04-28 01:12:12  anonymous2 [Reply | View]
  
  
  Well, I agree on 95% of these points but I doubt that Sun is making such a change. The potential of breaking with Java developers and not-so-freaky Java-users is high: "Why should I change my working code if I can also change it to .NET and never need to change it again?" Well, this is what many might think as Microsoft is the master of backwards compatibility (not perfect, but they try hard!). Sometimes you need to keep some old stuff to succeed.

• For more discussion
  2003-03-19 01:41:01  anonymous2 [Reply | View]
  
  
  check out this thread in comp.lang.java.programmer
  http://groups.google.com/groups?hl=fi&lr=&ie=UTF-8&oe=UTF-8
  &threadm=Pine.OSF.4.44.0208070114390.8291-100000%40ermine.ox.ac.uk&rnum=1

• Nice Article
  2002-12-18 13:04:47  anonymous2 [Reply | View]
  
  
  Very good article. Hope these things will be considered for the next Java release.

• Functional Methods
  2002-12-16 19:14:24  anonymous2 [Reply | View]
  
  
  I suggest addition of functional (as in "functional programming" i. e. without side effects). This could be specified by method modifier "functional" (in the language) and by special bit in the "access_flags" field of "method_info" structure in class file (there are some unassigned bits).
  
  A functional method should not be allowed to modify objects it did not create or obtained from other method as a return value. See example below: a method adding a number to each member of an array of integers
  
  "Traditional approach"
  
  void addNumber(int[] arr,int n)
  {
  for(int i=0;i {
  arr[i]+=n;
  }
  }
  
  "Functional" approach:
  
  functional int[] addNumber(int[] arr,int n)
  {
  int[] arret=new int[arr.length];
  for(int i=0;i {
  arret[i]=arr[i]+n;
  }
  return arret;
  }
  
  Only functional methods may be called from functional methods, and I/O probably must be very limited for functional methods.
  
  This corresponds to concept of modern functional languages that use monads (their way to define sequentiality) on the top level where I/O is allowed, and "regular" functions called from within monadic level that are prohibited to do I/O and any other action assuming sequentiality (a very rough description though).
  
  Absence of side effects gives big advantages in simplifying garbage collection. Only objects referenced via return statement need to be kept; the rest of objects that might have been created by the method can be disposed of immediately upon method termination (reduces background GC job). Functional methods may even run in parallel thus giving alternative to threading. A thread running in functional mode can be safely terminated (destroyed), and an upper level method should just catch this as an exception. If object(s) a method returns are created by the method, they are not referenced from anywhere and thus can be moved safely to compact the heap.
  
  This suggestion is drawn from my personal experience when I tried to create a straightforward implementation of JVM, and from some other Internet sources.
  
  Dimitry Golubovsky
  
  dimitry at golubovsky dot org
  
• Functional Methods
  2004-01-07 17:52:56  anonymous2 [Reply | View]
  
  
  Why not just use a language that was functional at its inception (e.g. Haskell)?
• Functional Methods (correction)
  2002-12-16 19:45:51  anonymous2 [Reply | View]
  
  
  Sorry, Java code in the examples does not look as expected. I'll try to use HTML tags.
  
  

  
  
  "Traditional approach"
  
  
  
  void addNumber(int[] arr,int n)
  
  {
  
    for(int i=0;i<arr.length;i++)
  
    {
  
      arr[i]+=n;
  
    }
  
  }
  
  
  
  "Functional" approach:
  
  
  
  functional int[] addNumber(int[] arr,int n)
  
  {
  
    int[] arret=new int[arr.length];
  
    for(int i=0;i<arr.length;i++)
  
    {
  
      arret[i]=arr[i]+n;
  
    }
  
    return arret;
  
  }
  
  </pre>
  
  

• Perfect world
  2002-10-24 15:03:33  anonymous2 [Reply | View]
  
  
  Ok, I'm all for doing this when we all live in a perfect world, don't actually _have to_ support backward compatibility, and don't have to live with our humaniod mistakes.
  
  I wonder what we'll be saying about Java 3.1?
  
  Otherwise, you're mostly dreaming...

• Forgot a biggie
  2002-08-27 17:39:19  piobair [Reply | View]
  
  
  My personal pet-peeve. Make Throwable an
  interface. Then I can catch meaningful cross-sections of types of exceptions and not be limited to a single-inheritance tree.

• ClassLoader problem
  2002-08-15 06:08:58  aanno [Reply | View]
  
  
  While ClassLoader problems occur frequently to the uninitiated, it is simply unpossible to make this simpler. The ClassLoader issue is deeply coupled with Java Security, because it is the ClassLoader that associates the ProtectionDomain with a Class. It simply is the _right_ thing that B is not an instance of A when they are loaded by different ClassLoaders. If it would be different, you could compromise A by simply extending it.
• ClassLoader problem
  2002-08-28 14:10:57  bjsyd70 [Reply | View]
  
  
  I wonder how much of this could be resolved by just improving the diagnostic message, so you could instantly see what was going on.
  
  Is the solution difficult to determine, or is the problem difficult to diagnose?
  
  Classes which use Class.forName often can not be shared by multiple .war files.
  
  What about using a 'getCaller' method?
  
  i.e. getCaller().getClass().getClass(name);
  
  The runtime information must be there so the exception stack trace works.
  

• Strange.. , If these are the general problems...
  2002-08-13 07:41:28  chaosb [Reply | View]
  
  
  Yes really there is very big consern about
  Old Mongolian characters.. :) Yes !! make everything object so you get things go really slow ! I don't know about 4 byte chars I'm not old Mongolian, Shumerian or old Bulgarian so if you say so. Strings are damn slow there are many of them believe me ! Performance of many java.util classes is very poor.

• This is one of the worst articles I've read in some time
  2002-08-12 11:12:45  jacyg [Reply | View]
  
  
  The premise is sound. Java can not remain forever tied to eternal backwards compatability. The nomenclature and deprecation stuff, all well and good. Those changes are not substantial and will help the language. But on several of the substantial changes, you missed.
  
  There are good reasons why Java needs a different windowing system than Swing. Perhaps the AWT is not it, but if not, then maybe the SWT should replace it. Whatever the case, Swing, for all its nicities, is never going to compete with native windowing components. For many applications, developers *need* a windowing system that renders using the platform's native components, not just one that approximates the native system with a look and feel. Java should maintain a facility for doing this. Swing is great for many applications, but too many people write off Java desktop application development b/c of bad experiences with the Swing GUIs. I've had to fight against this perception problem at jobs in the past.
  
  For that matter, the legacies of the 1.0 event model are still very useful when you are developing custom components. If you need to create a GUI element that isn't supported by the provided components, it really helps to have access to those methods. For everyone else, they never have to touch those methods, so I don't see how that imposes any penalty on them.
  
  The class loader problem you point to is intractable, short of having to qualify classes not just by package but by build (big no).
  
  And I can't *believe* you would even give the suggestion that checked exceptions be eliminated a mention. I don't care *how* good Thining In Java is, Bruce was and is a fool for advocating that. But go read his article and my (and others') responses to it.
  
  The previous comment by someone re: XML is well put. XML does have too much baggage. It is great for many applications, but it is by no means the best way to skin every cat.

• java first language with builtin thread-support?
  2002-08-09 10:17:00  wolfgangr [Reply | View]
  
  
  IMSR I used them in PL/1 in ? 1985?
  And, never used it, but remember a book on ADA
  and thread- and task-handling shortly thereafter.
  MS didn't invent native threads.
  
  Wolfgang

• How it could be done
  2002-08-08 12:11:57  vahur [Reply | View]
  
  
  To maintain backward compatibility, Java 3 could have a mechanism to switch between new and old implementations. It could be as simple as switching runtime class libraries and jvm implementations for single application and old jvm and runtime could be taken from older Java 2 implementation (probably bug fixed etc.). Something has to be done about Swing, it can just as well be replaced with eclipse's SWT or a library with similar approach. In many cases Swing applications have sub-par UI performance and look too different from native windowing system, confusing users and as an example, looking outdated on Windows XP. The Look & Feel idea in Swing is good and could resolve the looks problem but to build a new layer on top of something so heavy already, will only make user experience worse.
• How it could be done
  2004-01-08 06:56:49  anonymous2 [Reply | View]
  
  
  Shut up stoopidhead.
  
  Look and Feel implementations REPLACE the standard look and feel, they are not ON TOP of it. That destroys that argument, but thanks for posting ANOTHER stupid comment against Swing with no idea how it works.
  
  On another "point" you make - Swing is good because it tries to produce a UI from reasonably good, extensible and flexible principles - hence the ability to have custom models, renderers, selections etc. on most components. It has had some teething troubles and loses speed because of this. This is basically also an EXACT description of Java itself - if you want to do stuff really quickly and exactly like the native OS, but with no flexibility and more bugs, just go get a different language that meets the requirements you have. Putting a one-trick-dog UI like SWT on Java is just a waste of time, and any effort from Sun to use it will just make it take longer to completely sort out Swing.

• I agree, when's it coming out?
  2002-08-07 12:37:19  cbare [Reply | View]
  
  
  I agree with the author's point about the need for Java (or any technology) to evolve and adapt, and occasionally break with the past. Look how far they're going with Perl6. In specific, Threads and AWT/Swing are especially in need of attention.
  
  I've always wondered why java doesn't have an IntegerOverflowException or some means of informing you that your data has just overstepped the range of your data type.
  
  Also, I think it would be nifty to inherit constructors from base classes by default. Why bother typing something like this:
  
  class Whatever extends BaseWhatever
  {
  public Whatever( String param1, int param2 )
  {
  super( param1, param2 );
  }
  
  ...
  
  }
  
  
  
• I agree, when's it coming out?
  2003-09-27 12:37:01  anonymous2 [Reply | View]
  
  
  err.... sorry I don't agree
  
  sometimes the point of extending is to disable a stupid or dangerous contructor in the superclass.

• About Threads
  2002-08-07 11:55:51  dfitzgeraldca [Reply | View]
  
  
  Holub's article on threads is probably some of the best thinking on the subject ever written.
  
  You can read it here:
  
  http://www-106.ibm.com/developerworks/library/j-king.html

• What Mind-boggling Ignorance!
  2002-08-07 07:24:16  toadskin [Reply | View]
  
  
  I suggest the author of this article stick to XML because he is the last person anybody looking for an intelligent, informed voice needs when it comes to enhancing Java. Anybody got any serious suggestions for enhancing Java? He sure doesn't.
  
  The Complex Number class is tired and worn and he is coughing that up as his "personal" suggestion? The solution to that would be generics and operator overloading, not a naive suggestion to add one more class.
  
  The suggestion that they eliminate the need for a semicolon at the end of a line suggests is simply stupid. Java does not require a semicolon ad the end of a line. If he doesn't GET the basic notion of a statement and the ability to terminate such a construct he should not be commenting on Java at all.
  
  What you have here is some clown regurgitating a lot of old and misguided material based on pure ignorance. Do they have an "ignore" button for articles? Now there's a suggestion.
• Learn to read...
  2002-08-07 13:01:05  powersusa [Reply | View]
  
  
  Did you even read the article? You're gripping about statements made by the author as things NOT covered in the article. There was no suggestion to remove semicolons; it was simply an example a syntactical change which would NOT fall under the scope of the article. The same can be said for his mentioning complex numbers. So, go back and read the article, the whole thing, then come back with some intelligent comments.

• Backward Compatibility and ClassLoaders
  2002-08-07 06:16:06  as@bjss.co.uk [Reply | View]
  
  
  Firstly, I think backwards compatibility is a good thing. One of the reasons Microsoft do well (and I am no fan of M$) is that they spend a lot of time trying to get backwards compatibility right. Ok, there are times when it gets broken but they pay a lot of attention to it. As a result it is often easier to migrate between M$ s/w versions than it is other vendors products. On large systems you need the ability to migrate to new versions of products (keeps maintenance simply) without spending time moving components to new API's until the move makes business sense.
  
  w.r.t. class loaders, I'm sorry - I just don't see the complexity here. It's good that types are segregated across class loaders. You spend a few hours figuring it out and then you're set for life. Hardly a reason for wholesale re-engineering.
  
  

• make Object inherit Array and not visa-versa
  2002-08-07 03:23:22  muchandr [Reply | View]
  
  
  The types of all Objects are typechecked, but the
  types of Objects stored in an array object are not -
  this produces a lot of security flaws. If an Object
  was a kind of an Array and not the other way around,
  none of this would be possible. Of course, making an
  array a basic type in an object language is rather
  un-PC, but it would also make all the proposed vector
  extensions very easy.

• WE NEED AN UNSIGNED TYPE
  2002-08-07 01:42:53  st8 [Reply | View]
  
  
  Yes we do

• Cannot agree will all ten reasons
  2002-08-06 23:14:56  arocha_mo [Reply | View]
  
  
  "10. Delete all deprecated methods, fields, classes, and interfaces." seems to be logical but you cannot imagine the impact it may cause to developed system. I think it will make developer harder to accept (use) newer JDK.
  

• Ditch Swing no AWT
  2002-08-06 22:23:11  nirpaz [Reply | View]
  
  
  I tend to agree with most of the suggestions. About UI, I strongly believe that the Eclipse approach - SWT is much better than Swing.
  
  You can see for yourself, by using Eclipse you get the look and feel that is fast and responsive, with a simple API, things that you can't say about swing.

• Leave log() as log()
  2002-08-06 17:11:10  dgrant3 [Reply | View]
  
  
  Every mathematician knows that log means ln if the base isn't specified. So it's a needless change. The methods should be:
  
  Math.log()
  Math.log10()
  Math.log2()
• Leave log() as log()
  2004-01-08 04:55:46  anonymous2 [Reply | View]
  
  
  bullshit! learn basic mathematics!
  in mathematics
  log means logarithm of base 10
  ln means logarithm of base e
  
  log does NOT mean logarithm of base e
• log() -> ln() sounds reasonable to many probrammers
  2002-08-11 16:39:59  bezdar [Reply | View]
  
  
  However for many software developers log() sounds more like log_10 and ln sounds more like log_e !
  BTW it has long been printed on the pocket calculators that way!

• get rid of public constructors
  2002-08-06 16:28:49  friendless [Reply | View]
  
  
  I would like to see constructors all be private, so that you have to invoke a static factory method to get a new instance of anything. The problem with public constructors is that as soon as you call "new", memory is allocated, even if an identical object already exists. For immutable classes, such as Integer and String, arbitrary amounts of memory can be wasted by useless creation of duplicate instances. By making constructors private, use of memory by a class is controlled by the implementors of that class, who understand it best in any case.
• get rid of public constructors
  2004-01-07 21:00:24  anonymous2 [Reply | View]
  
  
  Thats where design patterns come into play as the solution you suggested would not work in all cases.
• get rid of public constructors
  2002-08-07 01:03:15  jdavi [Reply | View]
  
  
  I agree with you in having a way for control if a constructor returns a new object or a reference to an existing one, but I would prefer an equivalent to the readResolve() in serialization or be able to assign the "this" variable to another instance inside the constructor.

• Nuke finalizers?
  2002-08-06 14:28:55  bezdar [Reply | View]
  
  
  Have the finalizers _running at arbitrary time at the discretion of VM_ proven to be The Good Thing (TM)?
  
  If their intent is to free resources (like close Network connections) their unpredictable in time invocation seems a misuse.
  
  The major obstacle IMO is the following:
  - imagine there are some unfinalized objects
  - imagine that the VM gets into dire straits, it's in a Bad Need For Memory (and right now!)
  - but to run the finalizer we need some active thread - we can't reclaim the memory right away, we need to run the finalizer first, but what if this process (running a finalizer) will need more memory itself (and we already have none!)
  
  On the other hand, if the VM has had some time free and managed to have run the finalizer up to this point (what is a matter of chance) - then all goes well.
  
  So we either get or not get an OutOfMemoryException depending on fortune and probably _low system load in previous minutes_.
  Ha-ha!
  
  

• Reimplement WeakHashMap and "ObjectPool" in VM kernel
  2002-08-06 14:11:04  bezdar [Reply | View]
  
  
  1) sadly current WeakHashMap implementation is quite broken:
  
  - the 'orphant' value becomes reclaimable by the garbage collector only when put(), remove(), or clear() is called
  - even if such method is called this does not guarantee that the 'orphant' are reclaimed in the current java kits (both Sun and IBM - my tests show that)
  
  This surely may be corrected if core VM and threading are refactored and WeakHashMap implemenataion is build into the VM - IMO its worth the trouble
  
  2) Maybe I'm over-crazy about performance, but I like very much to keeping pooled objects ready for use (the alternative is to drop object as soon you no longer need it and new() a new one when you're in need of a similar one).
  
  But of course I want such pool to get automatically freed if the VM runs low on memory.
  
  Unfortunatly all the pools that I could imagine built with WeakReference-s in programmers (not VM) space were not perfect.
  
  If the ObjectPool implementation will be built into the VM it may even have the propery of intellectual memory control - as soon as VM runs low on memory the objects among those kept only via WeakReference-s, WeakHashMap-s and ObjectPool-s that haven't been used for the longest time would get cleaned.
  
  It would be even better to consider memery used but this sounds somewhat tricky due to possible interobject dependencies..

• Three more reasons for Java 3.0
  2002-08-06 13:51:40  rayburns [Reply | View]
  
  
  Here are my top three not listed in the article:
  
  3. Make arrays implement the List interface, especially .iterator()
  2. Value types a la C# (ie. allow Rect can be returned in registers)
  1. LET US OUT OF THE BOX!!!!! When a native API needs to be called it should be easy to do so.
  
  I've worked on several large Java applications, and each one needed a lot of JNI code to interface with the native APIs.
  
  For example, my current project requires the use of get_fs_usage() on Linux and GetDiskFreeSpace() on Windows. It's just plain stupid that I should have to go outside the Java language and deal with external libraries and such to make these calls. In many other languages I could write:
  
  long getDiskFreeSpace(String path)
  {
  int freeSpace;
  
  if(PLATFORM_IS_UNIX)
  {
  fs_usage fsu = new fs_usage();
  pin(fsu)
  {
  if(get_fs_usage(path, "", fsu)!=0)
  {
  throw new IOException("...");
  }
  return fsu.freeSpace;
  }
  }
  else if(PLATFORM_IS_WINDOWS)
  {
  long freeSpace = GetDiskFreeSpace(path);
  if(freeSpace == -1)
  {
  throw new IOException("...");
  }
  return freeSpace;
  }
  else
  {
  throw new IOException("Don't now how to get free space on this architecture");
  }
  }
  
  private native int get_fs_usage(String path, String device, fs_usage arg) "fsutil.so";
  private native long GetDiskFreeSpace(String arg) "kernel32.dll";
  
  
  In Java the same thing requires pages of comparatively cryptic JNI code, extra files, extra Make steps, platform-specific compilers, platform-specific binaries, and all sorts of other ugliness.
  
  Ray Burns
  
• Three more reasons for Java 3.0
  2003-05-29 08:12:29  cesalvador [Reply | View]
  
  
  Hello,
  
  
  I am trying to write in Java with JNI a class that gets the free space in my disk, I am having several problem because I don't know how to use the language C to do the interface with Java. Will it be that you have this code of Java and C and can he/she send me?
  
  My email is Carlos_Salvador@cargill.com
  
  
  Thank you
  
  Carlos Salvador
  DBA Oracle PL
  Brazil - SP

• In real life?
  2002-08-06 13:20:25  AGILA [Reply | View]
  
  
  Even though I agree with this article, I don't think that it will possible to change Java so much: Sun and companions are not so flexible, and exisiting software would not run on the new VMs (mobile phones now coming out e.g.)
  I deeply regret this.
• I agree not in real life?
  2002-08-07 06:08:23  sheltonn [Reply | View]
  
  
  I don't know about the author, but I have survived the .com implosion (so far). We have 4 developers supporting 3 personalized sites. The last thing we need to do is rewrite a bunch of code that was written by a person 2 layoffs ago, just so we can upgrade to the next version.
  
  Making an incompatible version would only slow it's introduction.
  
  Instead, add new class structures (like nio) so we can take advantage of them, but PLEASE DON'T BREAK MY PROGRAMS THAT WORK JUST FINE.

• extensions ?
  2002-08-06 11:54:01  jefu1 [Reply | View]
  
  
  
  I don't believe that either of these counts as a language extension as both would retain backward compatibility, but both would be very good to add.
  
  1) better support for "design by contract", in particular, class invariants (checked only on publicly visible member functions), pre and post conditions in member functions - not using the awkward "assert" but more as in Eiffel or Sather - in particular, it should be able to turn these on and off at compile time on a per class (or even per package) basis.
  
  I'd estimate that using pre/post conditions and invariants in Sather reduced my debugging time by about 90% (and I've used "assert" in both C and C++ with nowhere near the same success).
  
  2) Generators/iterators as in Sather, Icon or recent Python. Enumeration classes don't do quite the same thing as generators in Sather can be defined within a class - and without an extra class to hold the enumeration. My experience with these has been that code size has shrunk by 30-50 percent.
  
• extensions ?
  2002-08-28 14:33:32  bjsyd70 [Reply | View]
  
  
  There is a preprocessor which does design by contract for Java, iContract.
  
  There is another preprocessor that does embedded SQL, SQLj
  
  And that targets HTML pages, JSP.
  
  And another for long lived processes, Scenario Beans.
  
  Generics can be added this way.
  
  And others ...
  
  Is AspectJ another preprocessor?
  
  There needs to be 'framework' to organize the implementation of language extensions.
  
  - The ability to add new functions, done.
  - The ability to add new types, done.
  
  We need be be able to add other abstractions.
  

• How about multiple jvm shared core api
  2002-08-06 10:46:58  bobd [Reply | View]
  
  
  One thing that I think could defintely be helpful is having the core api shared in memory across vm's running on the system. Or maybe even a way to place different jar files in a path that allows them to be shared in memory accross vm's. I hate the fact that when I am devloping in Netbeans and running and debugging in Tomcat, JBoss or what ever that the core classes need to be loaded in each vm. It's memory bloat that does not really need to be there and is another thing that effects the viability of Java on the desktop. If you need a few hundred meg to run 2 or three apps thats a problem. Perhaps there should be what amounts to a System level classloader for all of the vm's for a particular version that they share in common. Yet provide the functionality of chained classloaders to the individual vms so they can load different versions of third party api's that they need. This concept has been proven in the web-app world where each app has it's own classloader yet share the core through the classloader for the app server.
• How about multiple jvm shared core api
  2002-08-08 02:52:48  damomurf [Reply | View]
  
  
  I understand that Apple are doing some work in this area with their implementation of 1.4 on OS X. There seems to be some sort of feeling that the shared core api (including loading it from an image) could find it's way in as standard in 1.5 as Apple and Sun seem to be talking a lot to each other. Those non-apple people among us can only hope...

• Most important, but perhaps not Java 3
  2002-08-06 10:31:27  mockturtleneck [Reply | View]
  
  
  The class loader conversation begins to touch upon this, but commercial java apps all package and deliver every jar they use to avoid inconsistencies with existing jars in the classpath.
  That is rediculous. We need a 'registry' of jars and versioning information available to the runtime (especially the installers).
  Don't beleive me? Search your hard drive for Xerces.jar ... I have seven and I've never downloaded the Apache package!
• Most important, but perhaps not Java 3
  2004-01-07 15:01:24  anonymous2 [Reply | View]
  
  
  I can't agree with your suggestion. Every application should come with its own set of libraries. This guarantees that updating application A has no impact on application B. How many *different* Xerces.jar version have you got on your system?? I guest more than two at least! Personally I prefer wasting some KB rather than running into something, windows programmers/users call "DLL hell".

• sounds very reasonable
  2002-08-06 10:08:45  demagogue [Reply | View]
  
  
  to have a 3.0 version that is incompatible with older version... but probably easier if its introduced as a "cousin" language.
  
  or, do what borland does, ship conversion tools along with the new version...

• Interface naming collisions
  2002-08-06 09:30:26  nielsen [Reply | View]
  
  
  Here's something else that needs to be fixed. It requires a major redesign:
  
  I have two interfaces and both have a method with the same name, let's say 'close'. If I want to implement them in the same class but have different things happen for either close method, I can't.
  
  Basic design flaw.
• Interface naming collisions
  2002-08-27 17:44:14  piobair [Reply | View]
  
  
  I'd say its more a design flaw in your model, then Java. If close() has two meanings you probably ought to be more explicit about what/how your closing.
• Interface naming collisions
  2002-08-06 10:40:32  wmshub [Reply | View]
  
  
  But there's already a solution! Just use an inner class instead. I almost never implement interfaces in my "main" classes, so instead of:
  
  public class Foo
  implements Bar, Baz {
  
  public void close() { /* Is this Bar.close or Baz.close? Oh no! */
  }
  }
  
  you can write:
  
  public class Foo {
  public final Bar bar = new Bar() {
  public void close() {
  barClose();
  }
  }
  
  public final Baz baz = new Baz() {
  public void close() {
  bazClose();
  }
  }
  
  private void barClose() { ... }
  private void bazClose() { ... }
  }
  
  Problem solved! Now just use foo.bar when you need the Bar interface and foo.baz when you need the Baz interface.
  
  My only complaint is that it's a very verbose mneumonic. I'd prefer "thin" classes, like:
  public thin Bar bar = Bar() { close=barClose };
  to say "Bar is an inner bar object, but its close is equal to the bazClose in the outer object". Much easier to read.
• Interface naming collisions
  2002-08-06 09:38:49  rpkrajewski [Reply | View]
  
  
  Amen !
  
  In Common Lisp, object functions are just functions and are thus subject to namespace/package partitioning. In Java, by contrast, member selection and the namespace syntax both use ".", which would make any new syntax for letting members belong to packages a bit ugly or different.

• Case sensitivity
  2002-08-06 09:07:43  jmpiazza [Reply | View]
  
  
  Ditch it. Serves no useful purpose. Zilch. Nada.
  
  That would solve item one immediately. Think about it: item one concerns *convention*. Enforcing any case structure by a compiler (or interpreter) goes beyond convention into a *requirement*.
  
  A preferable way of dealing with the issue is to make everything case insensitive but add capability in tools to enforce whatever convention the particular wishes. This would be the equivalent of syntax coloring in a a whole slew of editors. In fact, this approach would allow many programmers to catch even more bugs than case sensitive code can cause all on it's own.
  
  I would much rather have the computer burn a few CPU cycles helping me overcome my occasional (OK, frequent) typing mistakes than actively make them hatch into bugs.
  
  joe from buffalo
  
  
• Case sensitivity
  2002-08-06 10:32:56  wmshub [Reply | View]
  
  
  Wow, I couldn't disagree more. Case sensitivity lets us do things like "Coproc coproc = new Coproc();", etc. Being able to use the same word, with different capitals, for a class and an instance of that class is very nice. I have no trouble hitting shift at the right moment so taking it out would give me nothing but a smaller name space.

• Another thing
  2002-08-06 09:04:16  st0rm [Reply | View]
  
  
  We don't need generics anymore, if everything is an Object.
• Another thing
  2002-08-06 10:25:54  devextreme [Reply | View]
  
  
  With generics, an ArrayList could be checked at compile time to use only objects of type Foo. There would be no cast necessary (and of course no ClassCastExceptions) as with Objects.
• Another thing
  2002-08-18 09:45:46  st0rm [Reply | View]
  
  
  Oh, nice.
• Another thing
  2003-08-15 13:43:57  anonymous2 [Reply | View]
  
  
  Haha! Sucka!!!

• I agree with *almost* everything
  2002-08-06 09:01:15  st0rm [Reply | View]
  
  
  Except I think that we need Java to be a bit more scalable and Swing should be replaced with a portable SWT. However, I don't think all the I/O APIs should be changed. There are a lot of useful Stream classes. There needs to be a better way to allow the old I/O API to work with the new I/O API.
  
  I wholeheartedly disagree with #5. XML sucks. It's a fad. The current Properties serialization is perfect. Most of the stuff you're talking about is just key-value pairs. We don't need XML for it; it carries a lot of extra baggage.
  
  I 100% agree with the JDBC comment.
  
  I have one practical matter that needs to be discussed, in respect to Java Web Start. The JRE currently is NINE MEGABYTES. I'm on cable, but many people are on 56k connections, and are unwilling to download that. I propose two solutions. First, the JRE install could be a few kilobytes and download the packages from mirrors, like Cygwin does. If we don't do that, we could have it download packages on-demand, that is, only download the classes we need for a particular application and cache them. In this way, their first download isn't too big, and subsequent ones will get smaller and smaller.
  
  My 2 cents.

• Yes - clean up thread locks
  2002-08-06 08:56:03  wmshub [Reply | View]
  
  
  I agree 100% with your comments on locks. Java's "every object is a synchronization point" is stupid; if there were one object, the "Monitor" object, that could be synchronized on, then you could add it to any object that you want to use, so what's the benefit of having all objects be synchronization points? The problem is often that when I need to synchnronize, what object do I use? There's no way to be sure.
  
  In addition, it is a realy problem that you can't extend/modify the locks. In C, I have a library+macro system wrapping the pthreads that lets me force lock ordering; when I grab locks out of order, it immediately throws an assertion. To do this in java, I need to invent my own locks, that have explicit "lock()" and "unlock()" calls, thus losing the one good thing that java locks have (you can't forgot to unlock a java lock). It would be so nice to have both, "synchronized(lock) { ... }" while at the same time being able to override locking semantics to add checks for lock ordering, etc.

• Better scalability
  2002-08-06 08:12:09  rdorta [Reply | View]
  
  
  I will like a simplification of the java classes. Currently are too many classes. It will simplify the learning of java and improve the code quality in the future.
  
  I think that Sun must provide a compact java API with basic classes, and reorganize the module access. Separate the JDBC access, the RMI/Corba modules as very different modules but it could be obtained very easily with a easy access to them, these classes could have the same name but distributed separately.

• add READ-WRITE parameters to methods
  2002-08-06 08:02:22  mirek1 [Reply | View]
  
  
  Java methods have very limited possibility to accept its parameters and return more values (then the only one)!
  
  I know that it was intention (to depress "side effect" for variables defined out of body of method). But in practice the Java code of obvious program is then less synoptical and more longer then it could be if Java will inspirate at these 3 "ancient" languages: pascal, FoxPro and Informix 4GL Language.
  
  The main problem is "How to (simpy!) return more primitive values or objects from the method?". That can be express like problem of "READ-ONLY" and "READ-WRITE" parameters of Java method.
  
  The only current mode of Java syntax forces every Java programmar to accept these 2 regules for "radius" of method:
  
  1) The change of parameter of object type WILL result in change of variable defined out of this method.
  2) The change of parameter of primitive type WILL NOT result in change of variable defined out of this method.
  
  Every programmer has no possibility to deside if he/she wants this. He/she only must to accept it.
  
  So every programmer is forced to create special "one-purpose" class for every primitive value that he/she need to change in the body of method and return it out of this method into the place of parameters (for example IntegerX for primitive int, DoubleX for primitive double etc [the buil-in Java objects Integer and Doubles could be used for this reason!]).
  
  1) How was solved this problem at "old" pascal?
  -----------------------------------------------------------------
  
  Remark: pascal distinguishes function (return value)and procedure (does not return value), but for simplicity I will here name both of it only like methods.
  
  EVERY parameter (primitive or object) which is define in the declare of method CAN have an phrase "var":
  
  A) "var" means that every change of this parameter inside of method will be changed the variable of parameter outside of this method.
  
  B) Absence of "var" means that this method has no "side-effects" for suitable variable outside of this method.
  
  When calling of this method, programmer writes only method and names. He/she must know how parameters were defined at declare of method.
  
  It is rather danger.
  
  2) How was solved this problem at "old" FoxPro?
  -----------------------------------------------------------------
  
  I can not remember the correct syntax level of this, but I know that programmer has here more and more more "freedom" then in pascal (and therefore it is more "danger" then in pascal):
  
  A) Programmer can designate the type of parameter (READ-ONLY or WRITE-ONLY) at declare of function.
  
  B) Programmer can change during calling of functions the type of this parameter or let it to act like is cited at declaration.
  
  3) How was solved this problem at "old" Informix 4GL Language?
  -----------------------------------------------------------------
  
  The problem of READ-ONLY and READ-WRITE parameters is "converted" into possibility to enlarge of number of returned values.
  
  So function can be declared with (for example) 3 returned values and during calling of this functions are suitable variable stated.
  
  For example:
  
  CALL function_abc (a, b, c) RETURNING a, b, c
  
  This solution is very nice readable. I do not recommend this exact syntax. I "only" recommend any syntax from which every programmer will se during CALLING of method whether its parameters behave like READ-ONLY or like READ-WRITE.
  
  The code of such program will then be clean, short and nice fore everybody!
  

• We need Generics and Built-in type safe enums
  2002-08-06 07:53:41  dkaz [Reply | View]
  
  
  Agreed on those two points with other users

• Idea about constructor naming
  2002-08-06 07:20:04  mcmilwj [Reply | View]
  
  
  I've always wondered why constructors need to be named with the name of the class. Why not use a generic identifier: this() or ctor()...scratch that (no abbreviations right): constructor() for the default and overloads too. Whenever I've wanted to change the name of a class, it has seemed to me that having to rename all your constructors was kind of silly. Why are we forced to state the name of the class in multiple locations? Just a thought.
• Idea about constructor naming
  2005-02-22 05:24:45  bluetooth [Reply | View]
  
  
  When learning Java we're told:
  "The constructor is a method named after the class with no return type"
  
  I've always thought it makes more sense to say:
  "The constructor is a method with no name that returns an object of the type that it constructs"
  
  It makes the syntax make more sense, to me. Also, your IDE should be able to refactor the constructor names when you re-name a class.

• Agreed...just don't change the name
  2002-08-06 07:14:08  problem1 [Reply | View]
  
  
  I recall reading interviews with Mr. Gosling where he expressed relief that Microsoft didn't do anything really imaginitive with their Java clone. It's great to be relieved about that, but I hope Sun won't miss the opportunity to fix Java even if it has to be at the cost of breaking compatability. This article points out many good ideas to that end.
  
  I want to urge that we remember that even a new and improved Java that is not backwards compatible with previous Javas does not have to be called something else just because it can't compile older code. The last thing the U.S. software developer needs is a new buzzword that's not on their resume and which opens the door further for cheap foreign labor.
  
• U.S ?!? Where did that come from?
  2002-08-07 03:27:04  dspanache [Reply | View]
  
  
  Wow!!! What a logic! Incredible and yet, so simple!
  Maybe simplicity is what best defines your mind.
  
  I'm sure you never intended to start here a U.S. vs. 'rest of the world' debate, but you sound really frustrated to me. I guess you'll overcome your frustrations when you'll have the courrage to replace the word 'cheap' with 'better'.
  
  Or perhaps my idea about 'quality' being the first thing that drives U.S. companies is completely wrong...
  
• U.S ?!? Where did that come from?
  2002-08-08 14:58:09  problem1 [Reply | View]
  
  
  Seems to me that continuity in the name of the product should be an important consideration. Of course the politics that surround the importation of cheap labor does make it more so and this is all I meant to bring to light. If this new improved Java should be called WhizBang v1.0 rather than Java, then employers have an easy out to consider imported workers--couldn't find a native worker with any WhizBang experience, had to look abroad! Of course, there are already many ways to do this...keep an eye out for people with 10+ years experience with Java--U.S. Citizens need not apply.
  
  Sounds like you're being defensive about these programs, so I want you to know that I'm happy to compete with you on an equal footing. What troubles me is that companies can bring you over and pay you less than fair market wages due to a visa status that really is intended to exploit you and improve the bottom line for employers. That puts the squeeze on me, too, and I do feel it. The only worker shortage that's for real is a shortage of cheap workers.
  
  And, please, get a clue...quality is certainly not what drives U.S. companies. Have you seen the news? Enron? WorldCom? Hello? These guys are not focused on quality; they are focused on money and for them, well...they *do* subsitute the word 'better' for 'cheap'.
  

• Clean up syntax
  2002-08-06 07:02:46  asalwin [Reply | View]
  
  
  The syntax with all the braces is awful to someone
  who is familiar with Ada-like syntax. A pre-processor with if/end-if, loop/end-loop,
  class/end-class, etc would be great.
  
  Note: When the AT&T switch took out the east coast several years ago, it turned out to be a bug in a switch statement, in which code "falls through" to the next case. Using Ada-like conventions would have avoided this.

• Reason #2: I/O
  2002-08-06 06:56:00  asalwin [Reply | View]
  
  
  While we're revising I/O, suggest adding some methods that do formatted input. Should be able to read a text file and store the results into a primitive.
  
  

• Include some of the good parts of C++
  2002-08-06 06:44:11  grs19689 [Reply | View]
  
  
  I am a C++ programmer as well as a Java programmer. I'm always wishing I had some of the features of C++ available when I write Java.
  
  1) The "const" modifier. I have never been able to work out my Java does not have this.
  
  2) The advanced features of the STL - iterators and algorithms particularly. I know there are implementations of the STL in java but I'd like to see the features of the STL made standard in the java.util package.
• Given your subject, I was afraid to read your message...
  2002-08-06 07:19:01  ewatkeys [Reply | View]
  
  
  But I think const-ness is a very good idea. C++, it can be a real pain to properly implement proper const-ness on an object. Determining what methods change state and what ones don't can take a lot of time. That's my only problem with seeing this feature in Java.
  
  Just like access control, const-ness is one of those nice-to-have features that raises the hurdles to getting a class ready for prime time. A "proper" C++ class is a pain to build. Overloading assignment operators, default constructors, copy constructors, destructors. It makes you not want to create a new class.
  
  A nice part of Java is that you don't need to be a language lawyer to write code that works as a class is expected to.
• Everything is const
  2002-08-28 14:17:18  bjsyd70 [Reply | View]
  
  
  Well not quite everything, but most things.
  
  Const is not worthwhile - the vast majority of variable I use are const.
  
  Fully identifying this would be painful.
  
  I just worked on some C++ code which would not compile after a compiler/STL version change because of a great many things, including changing interpretations of const.
  
  Brendan
  
  

• Steal Objective-C's selectors, use inner classes far less.
  2002-08-06 06:34:33  ewatkeys [Reply | View]
  
  
  One of the things I've always found painful with Swing is the need to define tons of inner classes to hook user interface elements to a method in a specific object. In a non-object oriented world, it would make sense to pass in a function pointer, and that's what AbstractAction and friends amount to. I believe that the C++ FAQ book calls such one-method objects functoids.
  
  Anyway, Objective-C has a wonderful feature called a selector. It allows a programmer to specify a specific method on a specific object. So instead of this horrific code in Java 1.2:
  
  button = new JButton(new AbstractAction("Throb") { public void performAction(ActionEvent e) { throb(); } });
  
  One would be able to write the following code:
  
  button = new Button("Throb", selector(throb));
  
  While inner classes may have some other benefits, I have rarely used them outside of Swing code, and almost always in a way that could have more elegantly been replaced by a selector.

• Agree on Some points but not all
  2002-08-06 06:24:14  snowwolf [Reply | View]
  
  
  Some of your points are correct. Others I would strongly dissagree with.
  
  10. Delete all deprecated methods, fields, classes, and interfaces
  I have been saying this for years. This has lead to people not using Calendar and still using the broken Date methods.
  
  9. Fix incorrect naming conventions.
  This is reasonable.
  
  8. Eliminate primitive data types
  I disagree.... While there are areas that the types can be improved i.e., BigDecimal, removing the primitive types is the wrong answer. One of the advatages of java is its preformance. While the oo purest may think all objects everywhere, it leads to preformance issues and actully clutters the code unless you add operator overloading. Operator Overloading is a bad idea and should never be added.
  
  7. Extend chars to four bytes.
  agreed
  
  6. Fix threads.
  should have already been done
  
  5. Convert file formats to XML.
  I have had this conversation with many other java developers over the last year. This sounds good on the surface, but it should be optional. For property files and manifest it is a greate idea.
  However, since RMI is done through serializing objects the overhead of xml would dramatically impact the use of EJB's. It would require more cpu cycles and network bandwidth with no gain for the users.
  
  4. Ditch the AWT.
  Sure... sounds good... I don't do AWT/SWING... HTML/XUL/JSP is the future
  
  3. Rationalize the collections.
  Agreed. Make the interfaces behave the same and make them all threadsafe.
  
  2. Redesign I/O.
  Agreeded
  
  1. Redesign class loading from scratch, this time with human interface factors in mind.
  The classloader issue has bit me a few times, but the benifits of the segmented loader is great. I can control aspects of security buy using different classloaders. Not sure there is a way to adjust how the classloaders work without breaking the segmented nature of the loaders. If fixing them means removing the segmented nature, it sould not be done.

• 11 - Add Properties as a language feature
  2002-08-06 06:01:32  powersusa [Reply | View]
  
  
  I wish properties (ala Delphi and I guess C#) were a language feature (and no Java Bean like introspection does not count).
  
  Currently getting and setting encapsulated member variables (ie not a public member) is accomplished with get and set methods:
  
  someVariable = MyObject.getSomePropertyValue;
  MyObject.setSomePropertyValue(someVariable);
  
  It is my view that setting and getting encapsulated member variables should be done through the assignment operator.
  
  someVariable = MyObject.someProperty;
  MyObject.someProperty = someVariable;
  
  There would still be get and set method for doing the work:
  
  private int fWidth;
  
  // the width property definition
  // note: if there is no write path defined
  // then the property is read only
  
  width: int read: getWidth write: setWidth;
  
  private int getWidth()
  {
  return fWidth;
  }
  
  private void setWidth(int aWidth)
  {
  if (aWidth > 0)
  fWidth = aWidth;
  }
  
  
  
  

• Obsolete code **can** be phased out
  2002-08-06 05:32:22  David Collier-Brown | [Reply | View]
  
  
  I had though I'd posted this in full before, but
  I don't see it...
  
  To oversimplify, with each new dot-release of
  the product
  x.1) declare bad idea denigrated
  x.2) start generating warnings about the bad idea
  x.3) generate error, but provide a do-not-fail
  option so that old .class file can
  stil be linked (fir folks who don't
  have the source to something they bought)
  
  In three releases, we could have a bad feature
  complete obsoleted, without causing people who
  have just libraries to lose their investment.
  
  --dave

• Documentation in XML
  2002-08-05 18:37:03  deanwampler [Reply | View]
  
  
  I'd like to see Javadoc tags converted to an XML format, which is the convention in .NET languages. Of course, Java predated XML, so an XML format wasn't an option "in the day".
• Documentation in XML
  2003-07-01 00:33:12  anonymous2 [Reply | View]
  
  
  XSLT could be used to filter out deprected stuff, produce html etc... this would be very cool.
  
• Documentation in XML
  2002-08-18 10:07:07  st0rm [Reply | View]
  
  
  XML isn't everything everyone says it is. Personally, I don't really care what javadoc generates as long as it look the same, but I ***don't*** want to write XML in comments. That's too much typing.
• Documentation in XML
  2002-08-07 08:47:37  smartass [Reply | View]
  
  
  Then you can also use some XSLT to filter out deprecated stuff
• Documentation in XML
  2002-08-06 07:04:29  asalwin [Reply | View]
  
  
  I agree completely.

• a bunch of amateur ideas...
  2002-08-05 08:20:29  morbid [Reply | View]
  
  
  There are many more important areas than need fixing before "all property files become XML" etc:
  
  - clone() needs to work with inner classes;
  - clone() needs to work with final fields;
  - clone() needs to be a public method of Clonable;
  - the language needs built-in typesafe enum support;
  - the language needs support for generic types (List<int>));
  - it should be decided once and for all whether final fields could be changed via reflection or not;
  - Externalizable should work with final fields;
  - it should be decided once and for all whether the current or the thread context classloader is used for implicit dynamic resource loading;
  - java.net.URL API needs cleaning up;
  - custom URL schemes need better support;
  
• a bunch of amateur ideas...
  2002-08-12 11:16:43  jacyg [Reply | View]
  
  
  mostly good, but clone() should not be a public method. See http://developer.java.sun.com/developer/bugParade/bugs/4673424.html
  for a better solution. The reason clone() should not be public is that it you may not *want* to externally expose the ability to clone an object, and having a clone() that is protected allows you to accomplish this. My proposed solution still gives this ability when truly wanted, without sacrificing the ability to keep clone() restricted.
• more...
  2002-08-05 08:28:33  morbid [Reply | View]
  
  
  - .class custom attributes should be accessible programmatically, via ClassLoader API;
  - covariant return types should be supported;
  - the language should support a proper notion of const-correctness;
• Even more...
  2002-08-06 05:31:22  styro [Reply | View]
  
  
  Most of the points mentioned by Rusty Harold are things that you stumble over when you write books, whereas you point out things that seem to stem from experience in using Java in large scale project (especially the const problem is my prime candidate when debugging).
  
  I 'd like to add a few ...
  
  - synchronous destructor/finalizer (in order to use powerful idioms such as allocate/lock-in-ctor, dealloc/unlock in destructor/finalizer). N. B. this does not have anything to do with GC and meory management, there are way more sresources to manage than memory
  - replace String and StringBuffer with String and MutableString (both supporting + operator etc.)
  - operator overleading (I want to define operators for my value types)
  - Fast GUI (move event dispatch to native code)
  
• Even more...
  2002-08-12 11:30:44  jacyg [Reply | View]
  
  
  I agree, though I hadn't thought about it, that Rusty's issues are realy more of an author's, rather than developer's problem. Well said.
  
  I do take issue, however, with the operator overloading. It's sugar, and it can seem sweet, but it's not good for you. In a large application that uses different libraries, if those different libraries have different operator overloads, keeping track of them can be difficult, and your code can have very well hidden errors (such as could result from using the operators in the wrong order). Now, you may say, "I would do better." but it's really not a good thing for the language. It would not enhance the stability and reliability of the general code-base. And it doesn't add any functionality that doesn't already exist with methods. *And*, if you do implement the funtionality with methods (.add(TypeA, TypeB)), there is a much lesser chance that a programmer could goof and inadvertantly use the wrong method. Operator overloading is just a different method syntax, but it puts the burden of figuring out which method on the compiler rather than the developer, and that's just bound to cause problems.

• thread issue
  2002-08-05 06:32:11  bobthedatabaseboy [Reply | View]
  
  
  it's worth reading Allen Holub on threads. he makes two points: i) they ain't OO, ii) they don't really work. if threads are going to be re-done, make 'em OO. i would add, make them thread safe by default; that is, the interpreter knows where a member is. it also knows which thread is using it. it can also, if it doesn't already, keep track of how many (and by name) threads reference the member. if threads were OO, it would just be a matter of the coder to say,
  
  Thread myThread = new Thread(myObject);
  myThread.start(); // or run() or fred()
  
  the interpreter would make sure that all access to members is thread safe. end of story. this behavior could be overridden.
  
  bob

• Agreed
  2002-08-05 06:28:07  uncledave [Reply | View]
  
  
  I agree; keep the debate open, but keep its focus on corrections, not additions.

• Learn from C#/.Net as they did from java
  2002-08-05 02:01:53  joostdev [Reply | View]
  
  
  I suspect Sun would abhor the idea alone of looking at C#/.Net to get inspiration for some changes. But the reality is that MS copied java and improved precisely on these kind things. I think its time Sun should do the reverse and look at C#/.Net. Because; like it or not, they are the competition!
  My suggestions:
  1 one should be able to invoke a method on a basic datatype and it should be wrapped by an object under the hood. cf. C#
  2 one should be able to define ones own basic datatypes for high performance computing (i.e. 'value objects' in C#)
  3 java should support some kind of versioning at the platform level. (cf assemblies in .Net)
  4 java should have some notion of components. (idem)
  
  It's time for a bit of renewal now the advantage java had has been taken over by the copy/improve action that is C#/.Net
• Learn from C#/.Net as they did from java
  2002-08-06 01:39:41  ianfairman [Reply | View]
  
  
  > 4 java should have some notion of components. (idem)
  
  Java already has two component models: JavaBeans and EJB. In what way would a .Net inspired model be different?
• Learn from C#/.Net as they did from java
  2002-08-07 03:15:04  joostdev [Reply | View]
  
  
  Ok, fair point. Imo javabeans and EJB's are too fine-grained to be called real-world components. A .Net assembly (=component) can contain several classes. Ofcourse a .jar file contains classes. But a .jar file does not advertise it's public interface nor does it sustain a form of versioning that is automatically checked by other code that uses the component.

• Numero Uno: Add multilanguage support for JVM
  2002-08-04 21:20:13  oreallyy [Reply | View]
  
  
  There is no reason the JVM cannot support almost all programming languages (like Ada, Eiffel, ML, etc.) Sun needs to add "a few new bytecode instructions for the VM spec." It's easy to do so do it.
• Numero Uno: Add multilanguage support for JVM
  2002-08-06 19:21:49  problem1 [Reply | View]
  
  
  Just as a point of interest, in 1998 Borland (then just renamed Inprise) showed a compiler for their Delphi (Object Pascal) product which targeted Java Byte Code rather than x86 native code. It didn't handle GUI work at all and did have other limitations that caused the folks at Borland to regret showing it to the public at all. Here's a link that briefly mentions the compiler as shown at Borcon '98:
  
  http://www.undu.com/Articles/980820a.html
  
  Personally, I'd prefer the effort be put into cleaning up Java rather than worrying about how to make the JVM accommodate many different languages.
  
• Numero Uno: Add multilanguage support for JVM
  2002-08-05 10:01:14  pmorelli [Reply | View]
  
  
  Here's 160...
  
  <http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html>
  
  
• Numero Uno: Add multilanguage support for JVM
  2002-08-05 23:18:37  oreallyy [Reply | View]
  
  
  The JVM is optimal only for the Java language and a few other (scripting) languages. For other languages, you need to resort to hacks to make the language work with the VM. Sun knows this, even acknowledges this in their VM spec. I just hope they at least start changing the VM for this. This feature should be quite adequate in counter-attacking M$ and .Net.
• Numero Uno: Add multilanguage support for JVM
  2002-08-06 11:05:18  pmorelli [Reply | View]
  
  
  And the MS Common Runtime is optimal for C#... and a few other (scripting) languages. With hacks, so you get Eiffel# and Perl# and Python#.
  
  I agree with your point, that Sun should keep alternative languages in mind, but that isn't their design goal. They have one goal: Making Java run well on all platforms. Anything else is just gravy.
  
  I also think we won't be seeing too much .NET code in anything beside C#. Or VB.NET. Call it a hunch.
  
  BTW, I've used Jython (java + python), and it doesn't seem "hacked" to me. It's always performed quite well, and has a pretty seamless integration.
• Numero Uno: Add multilanguage support for JVM
  2002-08-06 07:58:40  rdorta [Reply | View]
  
  
  I agree with the multilanguage support. I think that Sun must extends the capabilities of the VM to fight against .NET strategy.
  
  I will like to see something like C that generates bytecodes and to be multiplatform. Why not even include support for C# in the VM?
  

• byte primitives should be UNSIGNED
  2002-08-04 18:37:57  bchapman [Reply | View]
  
  
  If byte is only used for I/O and memory operations and dropping the math operators from it leaving only the binary operators is a good idea , THEN it should also become UNSIGNED.
  
  As for the assumption that bytes are used for non arithmetic things only, its probably a fair assumption if you are going to redesign the language.

• Disagree in a few points
  2002-08-04 09:58:08  EugeneKuleshov [Reply | View]
  
  
  Firs of all XML serialization should be optional but not mandatory. Because owerhead is too high and XML advantages you are described is not always useful. I would say, that in most cases binary representation is more convenient. Especially for object machalling.
  
  Now about File. I agree that file should be improved, but disagree about the way. File should represent some object on a virtual file system, and that VFS should allows to plug in custom FS, sucha s FTP, CVS, WebDAV and so on. Now we have to alternatives to access files - URLConnection and File. So, they should be merged and should allow more features and convenience.
• Disagree in a few points
  2002-08-06 08:04:19  rdorta [Reply | View]
  
  
  I agree with you in the File section. It will be a lot easier to programming and to extend capabilities of java if the classes have some standard access.
  
  I also like that the capability of handle several FS like FTP or WebDAV appears on Java 3. But I think that a VFS framework will be create this FS access a lot prettier.
  
  I will include these clases in some javax extension to simplify the language.

• method byte-code size
  2002-08-02 23:56:13  marc_recht [Reply | View]
  
  
  IMO the max. byte-code size of a method
  (currently 64kb) needs to be increased, too.
  For "normal" programs it isn't a problem and
  64kb seem to be quite much. But for JSPs it is
  not really much, because every servlet engine
  I know of does something like that:
  jsp:
  public void jspPage() {
  out.write("html...");
  code
  }
  It makes _one_ method out of your jsp. But if
  you use includes this blows up rather quickly...
  So, IMO increasing the size from 2^32 to 2^64
  would be a good idea..
  

• fix naming...
  2002-08-02 23:07:30  bchoi [Reply | View]
  
  
  Simple comment...
  
  while fixing the method names, be sure to make things more consistent,
  
  like list.size() and array.length .

• primitive types are awesome
  2002-08-02 18:05:07  codemonkey [Reply | View]
  
  
  The author mentions that primitive types are a top-10 drawback to Java, but really they are great in their simplicity.
  
  Using Objects, as the author suggests, with inheritance and all is terribly slow. The fastest Smalltalk even using small integers is at least 4x slower than Java and more like 100x slower for floating point despite cutting huge corners that cause unexpected results (10 == 10 but 10^9 != 10^9 in some Smalltalks). The performance difference is a *huge* factor, not a minor side-issue like the author suggests.
  
  Using values with inheritance, as in Eiffel, can cause totally bizarre effects where
  b = (tmp = a)
  results in b != a and !b.equals(a) for some types -- totally unexpected, bizarre and wrong.
  
  What is needed is an *Object based* system of user defined *value types*. In other words, C structs with methods. Value objects that do not have inheritance. Inheritance is incompatible with value types. Combine with auto-boxing to 'holder' objects where method calls on those cause a new value to be created (ie don't operate on the object itself) and the method called on it.
  
  Also, the author seems confused what a classloader is. It is perfectly right that A implements B not be an instance of B from another classloader; the entire security system depends on this concept. Classes are identified by their name and classloader, so there is no "A" class in the JVM.
  
  
• primitive types are awesome
  2002-08-09 04:50:19  cushko [Reply | View]
  
  
  I think you are wrong about Smalltalk.
  In every smalltalk dialect 10 = 10 and 10^9 = 10^9
  = is equality operator, and it works fine for small and big numbers.
  == is identity operator it is not designed for numbers comparision.

• Primitive types are needed!
  2002-08-02 10:12:15  petilon [Reply | View]
  
  
  For efficiency we still need primitive types. The article mentions C#, but the much-vaunted "Type System Unification" in C# is broken. See http://www.geocities.com/csharpfaq/box.html
  Other poor ideas in C# include structs and properties. See critiques section on this site: http://www.geocities.com/csharpfaq/
  
• Primitive types are needed, but need not prohibit first-class types
  2002-08-06 05:27:23  David Collier-Brown | [Reply | View]
  
  
  Actually smalltalk used a simple mechanism
  to make operations fast: they started out
  running the "primitive" code (ie, machine
  code), but if it could not handle one of
  the cases, faulted into a more general
  interpreted code-block.
  
  This made the common case fast, without blowing
  up the general case.
  
  Java, in principle, could have first-class
  types with full generality, without sacrificing
  performance if the "int" primitive code
  was the first code run for all integer
  operations, and had a few hooks to the full
  class, to be used whenever the primitive code
  didn't suffice.
  
  

• Completely Agreed
  2002-08-02 09:59:57  thanneru [Reply | View]
  
  
  An excellent article and I completely agree that it is time to make all these changes and more.

• I am not convinced
  2002-08-02 08:08:37  anonym_cvs [Reply | View]
  
  
  The author hasn't convinced me with his arguments. I also fail to understand how he can ask for a redesign of core system components (object monitors, ClassLoader, ..) when he himself admits he is not an expert on those topics. Maybe he should investigate a little more and build a stronger case. Java 3 might be needed but not for the reasons he detailed in the article.

• Swing & Generics
  2002-08-02 07:26:11  ianfairman [Reply | View]
  
  
  Personally I think Sun need a kick up the arse to sort out Swing. The current "emulation" approach leads to GUIs that look like Java GUIs on most platforms rather than native GUIs - they don't look or behave right. Using native widgets (a la SWT and Swing on MacOS X) has got to be the best approach.
  
  More profoundly, JDK 1.5 should finally get generics which could have a profound effect on the library, limiting the need for casting. Many C++ coders complain that, although the language has had templates for years, many programmers don't use them. I'd hate for Java programmers in ten years to be casting java.lang.Object all over the place.

• File Systems
  2002-08-02 06:34:19  phidias [Reply | View]
  
  
  I agree with your approach and would like to add my 2 cents worth to your comments on files.
  
  The current File class and the NIO Channel class don't supply you with access to the File System itself. (There's also a FileSystem class).
  
  What's needed is to have SPI implementations for SMB, NFS, WebDAV, FTP, HTTP, CVS etc. I think that's the intent with the NIO classes, but calling it a Channel seems too "abstract" a notion. There are a number of open source APIs to handle these types of file systems, and the NetBeans group created an architecture to support different file systems. Moreover, Sun had a framework several years ago, that it failed to incorporate within the JDK, called WebNFS that provided just such a framework.

• link to Eckel's checked exception article
  2002-08-02 05:48:26  fwierzbicki [Reply | View]
  
  
  http://www.mindview.net/Etc/Discussions/CheckedExceptions
• * it's an interesting example of how even leaders screw up
  2002-08-12 11:21:04  jacyg [Reply | View]
  
  
• Its the meeting of culture, psychology, and design
  2002-08-28 14:26:47  bjsyd70 [Reply | View]
  
  
  
  This:
  
  catch (Exception e) {
  }
  
  Occurs incorrectly over 40 times in in 44 java files in a project I just arrived at. If Java had unchecked exceptions, then 40 rare bugs would be gone and problems would be much better reported.
  
  It also happened on the last project I worked on.
  
  the goal of Architecture is to promote good judgement and discourage poor judgement.
  
  If your culture is different this design decision may have had different impacts.
  
  Eckel is very mature.
  
  There is no "Screw Up" at this level.
  
  There are only choices that end up having a real world impact.
  

• Good ideas!
  2002-08-02 03:26:25  mkluempe [Reply | View]
  
  
  Generally very good ideas. The JDK is WAY too big today. There has to be a more modular way of installing it and we have to get rid of the unnecessary components (deprecated classes, AWT, etc.)
  
  Changes of this magnitude will most likely need to be accompanied by noticeably better performance to convince ISVs and other developers to migrate their code to the new platform.
  
  Meanwhile, I think the next point release of Java should begin to define classes like Vector and Hashtable as deprecated in order to give fair warning to developers as to the future of these redundant features.
  
  Cheers

• expression language
  2002-08-02 01:41:00  danbunea [Reply | View]
  
  
  In jstl and jsp 2.0 I have seen something that could ease the work of o java developer a lot: the expression language, so I think that in a future version of java (3.0) this expression support should be included in the language.
  
  For the work with xml files we should include the support from jstl directly in the language.
  
  Another idea is that transaction management should be included directly in VM.
  
  In rest I totally agree with the 10 reasons and I hope that something shall be done soon.
  
• Something soon
  2002-08-28 14:37:43  bjsyd70 [Reply | View]
  
  
  I hope something is done soon.
  
  People should develop on all of these ideas.
  And others.
  Good ones and bad ones.
  But it is not Java, and should not be Java.
  It's research.
  
  Once the answers are beyond doubt, Java should be changed.
  

• Mandatory 'this.'
  2002-08-01 22:34:42  bayard [Reply | View]
  
  
  While I agree with sentiments to steal good ideas from C#, and to refactor many parts of the JDK, the biggest issue for me would be a change in the Java semantics itself. After spending a short time prototyping PHP OO rather than using JSP, I have become addicted to the safe nature of having to use this-> before every member variable.
  
  I would enforce this in the Java spec and make it mandatory for any access to a member variable to be preceded with this.
  
  A form of naming convention I guess.

• Couldn't it...
  2002-08-01 13:13:28  sethadam1 [Reply | View]
  
  
  Could a JVM for J3EE simply scan the code and if it finds anything it can't understand, pass it off to an integrated J2EE JVM? Or would that slow things down too much?
  
  I don't know too much about Java specifically, but it seems to me like there could be some sort of solution for upwards compatibility. What about some sort of "header" of J3 files that would tell it to run in the J3 JVM vs. the J2 JVM?
  
  Please feel free to follow up at
  
  _adam__at__firsttube_dot_com_
  
  -Adam

• Another: easier app-launcher
  2002-08-01 12:48:18  Chris Adamson | [Reply | View]
  
  
  Maybe this is more runtime than language, but one hold-up to client-side java is the totally dissatisfying options for installing and running applications.
  
  Mac OS X has it good -- make a folder of your stuff, put in resources, localizations and metadata, rename the folder AppName.app and *pow* it's a double-clickable application. Practically the same process applies to jar files and yet, when was the last time you saw an app that launched by double-clicking the jar? And how many end users find that satisfying? The Windows and Mac icons for jars don't exactly say "run me!"
  
  Applets are a disaster, mostly thanks to JVM versioning (especially vis a vis IE for Windoze) and too-tight/too-confusing security, and while Java Web-Start has its place, it is not a cure-all. Servlets are a totally different animal (though very successful for what they do).
  
  Ultimately, client-side developers either turn to InstallAnywhere or InstallShield to figure it out in platform-specific ways (for a handful of platforms), or fall back on command-lines, massaging classpaths and environment variables with batch files and shell scripts. Commmand-lines are great on the server (eg, for cron jobs), but dreadful for real-world clients.
  
  --invalidname
  

• Really good ideas
  2002-08-01 11:45:28  cybarlow [Reply | View]
  
  
  I agree with all of these reasons for refactoring Java. Didn't the addition of assertions and generics to Java begin to open this door? At any rate, if anyone from Sun is reading: making bean properties that are accessible through getProperty and setProperty methods accessible like this:
  
  somebean.someproperty = 5;
  somevar = somebean.someproperty;
  
  would be wonderful. C# cribbed a lot from Java; isn't turnabout fair play?
• Really good ideas
  2002-08-02 23:09:46  bchoi [Reply | View]
  
  
  >I agree with all of these reasons for refactoring Java. Didn't the addition of assertions and generics to Java begin to open this door? At any rate, if anyone from Sun is reading: making bean properties that are accessible through getProperty and setProperty methods accessible like this:
  somebean.someproperty = 5;
  somevar = somebean.someproperty;
  
  I dun agree with that. I would like to be able to tell if I'm dealing with a method or primitive from the syntax. They should be treated differently.
  
  bean.setProperty(5) is not unreadable.
• pros and cons of properties
  2002-08-06 18:30:02  rayburns [Reply | View]
  
  
  Having written a.getB().getC().setD(e.getF().getG()) too many times, I think adding properties to Java is a no-brainer. Public fields are extremely rare in well-written code, but the fact is that hundreds of real Java applications use them because getX() and setY() are too inconvenient and potentially inefficient!
  
  The only good argument I've ever seen for leaving out properties is that client code may make incorrect assumptions about the efficiency of "x.y". But this argument fails for two reasons:
  
  1. It assumes a Java mindset rather than a C++ or VB mindset
  2. It does not preclude using a different syntax for direct field access when such access is necessary
  
  An example of different syntax:
  
  "x.a" indicates property access and "x..a" indicates direct field access. In other words, replace this:
  
  a.getB().setC(d.getE().getF());
  g.internalThing = h.getI();
  
  with this:
  
  a.b.c = d.e.f;
  g..internalThing = h.i;
  
  The second case is more readable and it is still easy to distinguish property access from field access.
  
  
  However this seems like an unnecessary syntactic crutch. I prefer a class contract approach. For example, here's a contract that sum() takes O(N2) time and property x is a trivial access that can be inlined into the client code:
  
  // <contract>
  // <performance method=sum complexity=order_N_squared />
  // <performance property=x complexity=direct_acccess />
  // ...
  // </contract>
  
  Ray Burns
  
• pros and cons of properties
  2002-08-12 11:37:33  jacyg [Reply | View]
  
  
  The biggest problem that I see with properties is that they are just another syntax for a method, but rather than enhancing clarity, they decrease it. For example, there is nothing in the signature of a C# class (C# being a good mainstream model for properties) that makes it clear that it is read-only, write-only, or read-write. However, the presence or absence of the appropriate get() and/or set() method makes that abundantly clear. Yes, it may take a few more characters, but the generated code is the same. We should not be introducing new features in to the language that accomplish the same thing other features do. The willingness to do so will eventually render the language confusing and bloated, rather than streamlined and easy to understand. The best example I can think of is the number of ways to specify a String in Windows C++ development. Do you think a multiplicity of ways to do that same task makes the language better? I don't.

• Interesting
  2002-08-01 05:51:21  bungle [Reply | View]
  
  
  > Java must not be forever handicapped by mistakes made seven years ago in Java 1.0.
  
  This reminds me a lot what Microsoft did to Visual Basic, JScript etc. to incorporate them in .NET platform.
  
  I agree with Elliotte, and I think that the changes should be made to next major release (3.0). If they are not made, the problems will follow forever.
  
  Good article, thanks!
• Interesting
  2005-01-28 06:25:59  gast_arg [Reply | View]
  
  
  Primitive types ? and what about PERFORMANCE ???? everything will be harder to do to the VM...
  it seems that you like to program in VB and not in C / C++, the types now have a fix number of bytes in memory