|
Replies:
26
-
Last Post:
Oct 8, 2004 1:49 AM
by: denismo
|
|
|
|
|
|
|
Welcome
Posted:
Oct 6, 2004 2:32 PM
|
|
|
Denis Mikhalkin has agreed to moderate this forum to discuss the features that you most want to see in the next J2SE release, code named Mustang. Denis writes, ""We are in the stage of planning for the next release, 1.6.0, code-named "Mustang". We have thousands of features to choose from, but only a small amount of them will be implemented. Only the most important features, the most asked by the developers will be chosen and implemented. Do you think we underestimate the importance of some features? Do you have some bright idea for a feature? This is the place for you to speak up."
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 8:43 AM
in response to: daniel
|
|
|
1. Swing. Make it look nice - Finish out the Windows look-and-feel so Swing apps look native (for one thing, the last time I checked text boxes in Windows had a shadow, but text boxes in Swing didn't). Fix the font rendering bugs. Add support for ClearType, so Swing programs look as sharp on lcd monitors as do C# programs. Allow things to get repainted while the window is being resized. There's been a lot of progress on Swing, but there's still a ways to go. If start-up time could be eliminated on a modern system, that would be fantastic. A Swing program currently runs pretty fast once it has started up, but it takes several seconds to start up a program which simply displays an empty JFrame.
2. Jsp stuff - PHP people have a valid complaint when they say things like "java (they mean a jsp server like tomcat) wasn't designed to host multiple users (on one instance of tomcat)". Make it possible to isolate users from each other in the jvm, so one instance of Tomcat can run any number of users, but none of those users can destroy the jvm for everyone else. In other words, you can limit the amount of memory each user can use, each user has their own security settings enforced, and no one user can burn up all the cpu cycles (this last one is probably already true, I just threw it in for completeness).
3. I suppose this will actually never happen, but I really wish java would start having "properties" rather than the get/set convention. With properties, everything that manipulates the property would be in one place. I wouldn't accidentally set the value of a variable directly, when I should be using the set method (inside the class). I wouldn't have to write 2-3 times as much code as I really need just to have a property. I wouldn't have to write getters and setters when it's only in 20% of the cases that they actually have any special behavior. And I wouldn't have to write the same javadoc comment for a single property 6 times (although I would still have to write it twice. See http://jroller.com/page/PaulRivers/20041005#p_say_i_have_a for exact details). Notice how the get/set convention is ignored in many places through the jdk - it's Collection.size(), not Collection.getSize(). There's a reason for this.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 11:39 PM
in response to: paulrivers
|
|
|
I agree. Please make the Windowx XP look and feel lok like windows XP. Our clients really asks for this.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 12:27 AM
in response to: paulrivers
|
|
|
> 2. Jsp stuff - PHP people have a valid complaint when
> they say things like "java (they mean a jsp server
> like tomcat) wasn't designed to host multiple users
> (on one instance of tomcat)". Make it possible to
> isolate users from each other in the jvm, so one
> instance of Tomcat can run any number of users, but
> none of those users can destroy the jvm for everyone
> else. In other words, you can limit the amount of
> memory each user can use, each user has their own
> security settings enforced, and no one user can burn
> up all the cpu cycles (this last one is probably
> already true, I just threw it in for completeness).
>
We're talking J2SE here, not J2EE. And even if it were J2EE, Tomcat is NOT a Sun product.
Voice your complaints to the Apache foundation, they'll most likely welcome your vollunteer efforts to implement your wishes as they seem interesting.
> 3. I suppose this will actually never happen, but I
> really wish java would start having "properties"
> rather than the get/set convention. With properties,
> everything that manipulates the property would be in
> one place. I wouldn't accidentally set the value of a
> variable directly, when I should be using the set
> method (inside the class). I wouldn't have to write
> 2-3 times as much code as I really need just to have
> a property. I wouldn't have to write getters and
> setters when it's only in 20% of the cases that they
You always have the option of creating public data members and do away with getters and setters. Just don't complain when someone abuses the system.
I don't understand what's so bad about writing x.setSomething(y); instead of x.something = y; and it certainly doesn't make my code 20% longer.
Most editors will let you create getters and setters automatically anyway and some will even hide them from view unless you specifically ask to see them.
When using a visual editor like JBuilder or Netbeans to make your Swing app, you can already use the properties directly.
Remember that property IS getter+setter, not the datamember (it's quite possible to have a property without a direct mapping to a datamember for example).
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 1:13 AM
in response to: paulrivers
|
|
|
> 1. Swing. Make it look nice - Finish out the Windows
> look-and-feel so Swing apps look native (for one
> thing, the last time I checked text boxes in Windows
> had a shadow, but text boxes in Swing didn't). Fix
> the font rendering bugs. Add support for ClearType,
> so Swing programs look as sharp on lcd monitors as do
> C# programs. Allow things to get repainted while the
> window is being resized. There's been a lot of
> progress on Swing, but there's still a ways to go. If
> start-up time could be eliminated on a modern system,
> that would be fantastic. A Swing program currently
> runs pretty fast once it has started up, but it takes
> several seconds to start up a program which simply
> displays an empty JFrame.
We are constantly working on improving Swing native L&F support, and startup time of Swing application. Will continue doing the same in Mustang.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 8:52 AM
in response to: daniel
|
|
|
I'm glad the Sun is soliciting advice. My two cents:
1) I would start with the bug parade as and utilize the voting system in place. I won't delve into my pet bug, but the community has used this to voice desired features and bug fixes. This seems like the first place to start.
2) JVM sharing would go along way toward making Java on the desktop better. The launch time for the JVM and the per-application memory footprint hampers the progress of desktop Java.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 10:24 AM
in response to: duanegran
|
|
|
I definitely agree with using bug parade--even as it stands now. The biggest flaw with this plan is that every JSR really needs a shadow bug concerning its inclusion in the JDK or JRE. A better user interface is needed for bug parade, but that has been true for a long time due to the volume of bugs. How about a JDNC client on top of published web services?
Beyond that, it probably makes sense to give every user more votes. I would even support a system where developers could buy votes. In this way eighty thousand developers could fund a bug fix that concerned them individually, rather than IBM funding a bug fix important to it. The nice thing about buying votes is that stuffing the ballot box becomes impossible.
This also gives Java and new revenue stream (for those developers concerned about how Java supports itself) and incentive to grow the developer base--which they want to do anyway. The biggest risk is potential developer backlash. Personally, I think that developers who care about the future of Java enough to spend a few dollars, are generally better qualified to help shape its destiny than those that don't.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 9:04 AM
in response to: daniel
|
|
|
I like the JCP, but I think that java.net may be a better place to plan and develop some components.
I think that Swing's HTML parsing and rendering classes are ideal for more open development. Those classes suffer under a monolithic release cycle because HTML seems to be evolving faster than Java!
|
|
|
|
|
|
|
|
|
Limited language changes, mostly fix existing libraries
Posted:
Oct 7, 2004 9:17 AM
in response to: daniel
|
|
|
Language features:
These should be limited to things that can't be achieved in other ways easily. For example, aspects are doing fine outside the JDK, and are a very complex and little understood area and should be avoided.
- const - trying to simulate const is very difficult using other means, and when you need it you take big risks by not having it (our large web application uses a naming convention of variables starting with 'r' for readonly - this is not good)
- continuations - I know little about them, but what they seem to promise is a true step forward in disjointed programming tasks like web programming.
- operator new overloading - Many classes get written in an evolving environment. Initially you code the class to be instantiated each time via new Xxx(). Later you decide you want to cache/tune/pool it, but to do this you need a factory. (Not everyone has the luxury of full upfront design...) This request would allow the retrofitting of existing classes with pooling/caching/singleton behaviour without the caller needing to change their code. Note that I am not asking for general operator overloading as that is a very Bad Idea.
Please, please, please, also allow people to vote against proposed changes. Java 1.5 has introduced some awful crud which will haunt the language for the rest of its days. I'm more than happy for people to vote against my three language choices if they wish 
Library changes:
So many to do
- update the java beans spec to deal with reality like collections
- replace Calendar/Date - consider http://joda-time.sourceforge.net
- Add a Delegate class (Object+Method)
- Add a Property class (Object+Field)
- Add IO static methods to close streams quietly
- In fact see all the useful methods in Apache Jakarta Commons Lang, IO and Collections (not all should be in the JDK, but a fair few should be)
Basically, spend at least 50% of the whole coding effort of 1.6 on tidying up/minor teaks to/polishing what you already have. I believe that a really _open_ JSR process to go through the basic libraries (lang/util/io etc) could really get buy in from the community.
|
|
|
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 9:25 AM
in response to: daniel
|
|
|
what i want to see in mustang :
In the API:
1) A way to create read only array, there is lot of
defensive copies that are not necessary in all
Java program because there is no way to create
a read-only array.
I propose to add a method somewhere in java.lang
package that take an array and create allocate a
new read-only array populated this the data of
the array.
Object createReadOnlyArray(Object array)
This method could avoid lot of object creation
in JDK API like reflection or enum.
I think it's possible on all OS to allocate object
in a page that can be after set it as read-only.
The only problem to solve is how the GC can
deal with this page because it couldn't marked
the header of the object if the page is read-only.
But i think, it's the right moment to think about
this.
2) NIO effort must be continued (NIO 2 ?),
there is no support for selector on file,
multicast channel, etc.
3) In package java.lang.instrument,
Instrumentation.redefineClasses() may support to add
new fields and methods in live class .
This could permit to
implement dynamic mixin easily.
Persistence model based on interceptor stack
could be greatly improved.
4) because in java 5.0 add features like varargs and
auto[un]boxing, the VM compilers could try to
optimise peculiar sequence of box/unbox or
new array/array store/array load while
inlining to avoid object (wrapper or array)
creation.
5) in the same way, because now the bytecode contains
special attributes indicates the presence of generics,
VM compilers could use these informations
to generate specialized code (like C++ template)
for a specific
PS: i think that for now, doing this with the
existing attributes is impossible.
But it could be possible by introducing
a few more attributes, by example
to flag generics creation.
If item 4 and 5 are implemented, i dream about
the full optimisation of this code :
ArrayList<Integer> list=new ArrayList<Integer>();
list.add(3);
That enought for today 
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 10:26 AM
in response to: daniel
|
|
|
I hope that JSR 121: Application Isolation API is included in the next version of Java -- that's the second part towards a truly shared JVM, and it's of foremost importance to performant java on the desktop.
|
|
|
|
|
|
|
|
|
Faster
Posted:
Oct 7, 2004 10:29 AM
in response to: daniel
|
|
|
1. Faster dev time: Swing apps should be faster to create. We need something like JFaces or (dare I say) MFC to build apps quickly without too much fuss (an application framework). The problem with Swing is that the default behavior is not very good. Maybe JDNC is a good start to addressing this. Besides Swing other areas could be improved too.
2. Faster start up time: everybody has been asking for this.
3. Allow partial deployment: why do I need all 5mb of jars for a simple app.. let me deploy partially. This will help people that like to compile java into native apps (we could write little utilities in java now).
|
|
|
|
|
|
|
|
|
Re: Faster
Posted:
Oct 7, 2004 10:43 AM
in response to: dog
|
|
|
Please, no new feature in the Java language or libraries, in Mustang, but all bugs in the BugParade with vote > 1 solved! I'll even accept all bugs with vote > 5...
|
|
|
|
|
|
|
|
|
Re: Faster
Posted:
Oct 8, 2004 12:32 AM
in response to: dog
|
|
|
> 1. Faster dev time: Swing apps should be faster to
> create. We need something like JFaces or (dare I say)
> MFC to build apps quickly without too much fuss (an
> application framework). The problem with Swing is
> that the default behavior is not very good. Maybe
> JDNC is a good start to addressing this. Besides
> Swing other areas could be improved too.
>
That would probably require a complete rewrite which would in turn break most existing code.
Not a good thing. I agree Swing is a bit clunky.
> 2. Faster start up time: everybody has been asking
> for this.
>
Not that interesting for me as most of our apps run serverside for months at a time uninterrupted so having the JVM take half a second to start is a moot point
Even clientside the actual JVM startup time is short compared to the time it typically takes to load an (non-trivial) application and render the screen.
> 3. Allow partial deployment: why do I need all 5mb of
> jars for a simple app.. let me deploy partially. This
> will help people that like to compile java into
> native apps (we could write little utilities in java
> now).
How would you explain to a customer they have to install the JVM 10 times when installing 10 applications that each have a different partial deployment requirement.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 12:28 PM
in response to: daniel
|
|
|
Please implement the following which are found in most languages and will make java much more useful for numerical work;
1)JSR 83 - multiarray package
2)provide hardware speed trig functions
3)provide an optimized Complex number class (preferably with overloaded operators)
thanks.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 12:47 AM
in response to: virtualrob
|
|
|
and what about possibility of big arrays indexed by long?
|
|
|
|
|
|
|
|
|
Implicit declaration
Posted:
Oct 7, 2004 12:47 PM
in response to: daniel
|
|
|
It is great that Java now has generics.
This adds to the type saftey of the language but it also creates a lot of clutter and unnecessary to particular class in your code. In fact in a lot of cases, the amount of code is not reduced by generics.
What I think would make the situation better is to have an implicit declaration feature I.e.
Rather than doing something like this:
List<Person> people = getPeople();
one would do this:
people := getPeople();
This ":=" would automatically declare a variable of type List<Person> for you. I think this is consistent with the new for/in syntax.
The major advantage of this is that if you decide to refactor your code in some way and rename the class Person to PersonRole, then you just need to do a recompile, not a find and replace. Sure most IDEs have a "Refactor" facility, but this also cuts down on the amount of code you write.
Message was edited by: distiller
|
|
|
|
|
|
|
|
|
Re: Implicit declaration
Posted:
Oct 8, 2004 12:37 AM
in response to: distiller
|
|
|
This would destroy type safety and make the entire language a lot more obscure.
What if you had List<Person> getPeople() and Map<String, City> getCities().
Now you do something like
people:= getPeople();
people:= getCities();
person:= people.get(1);
You're getting an error, but would you get the error at line 2 (assignment of an incorrect type) or line 3 (calling a method from List on a Map)?
Line 2 is syntactically correct but unless it's an error line 3 is wrong here.
If you want something like you suggest, use Python or Ruby instead.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 2:02 PM
in response to: daniel
|
|
|
I would like to see a 'friend' operator. Or something like it. Something that would allow me to move classes that are protected by package level access to other classes.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 2:04 PM
in response to: nickhomeaccount
|
|
|
ooopps... "to other packages"
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 7:57 PM
in response to: daniel
|
|
|
Improve GTK look and feel (ugly, stupid file selection dialog copied from old gnome!).
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 7, 2004 11:59 PM
in response to: daniel
|
|
|
I'd like to see great support for multimedia and devices, from image acquisition through a scanner to phone handling...
Carlo.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 12:52 AM
in response to: daniel
|
|
|
I think Swing and Java Web Start enhancement is very important, the most important of all to me. I think Swing needs a team of 5 or 10 people to sit down and fix & update all of the broken and outdated code. Additionally, JDIC needs a lot more work and features and subcomponents, and should maybe be shipped as part of the JDK in javax.*
I think it's very important to continue to enhance the language using:
1. Runtime generic type argument introspection (so a new ArrayList can see what its element type is, and optimize accordingly)
2. Various useful annotations (like in JSR 250)
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 1:22 AM
in response to: daniel
|
|
|
Make API more connected together what allows shorter code and better performace. Those are little things usually, but they brink problems.
I give you an example - If you have Bean serialized in String and want to deserialize it, you have problem, because XMLDecoder works with InputStreams only and StringBufferInputStream is deprecated. So you have to convert it to byte[] and wrap to ByteArrayInputStream, put it to decoder, which send it to parser, where it is wrapped with Reader and converted to characters again. Result is longer code and poor performance.
|
|
|
|
|
|
|
|
|
Mustang Features?
Posted:
Oct 8, 2004 1:22 AM
in response to: daniel
|
|
|
Here's what I'd like to see in Mustang.
1. MUCH finer grained security permissions in WebStart. Every article I see about webstart makes the complaint about its current security permissions (all or nothing).
2. Bring JDOM into the core API.
3. A copy method on the file object, such as
File.copyTo(File source) throws IOException;
This method should use the fastest method possible for copying a file available natively on the current OS.
I too would like to see support for Scanners and other multimedia devices, but thats a non-core job. I think JavaMediaFramework needs updating badly , and some kind of Image Acquisition API for scanners, cameras and other still frame devices.
|
|
|
|
|
|
|
|
|
Re: Welcome
Posted:
Oct 8, 2004 1:49 AM
in response to: daniel
|
|
|
Closing this topic, please post the ideas as separate topics
|
|
|
|
|
java.net RSS
