Skip to main content

What new feature do you most want to see in Dolphin (Java SE 7)?

Language-level XML support
13% (110 votes)
Language-level Visual Basic support
3% (26 votes)
Easier library versioning/management
27% (224 votes)
Easier end-user deployment
28% (228 votes)
Better multimedia support
20% (160 votes)
Something else (please comment)
9% (72 votes)
Total votes: 820

Comments

Full runtime generics support

Or alternately, 'fess up that Generics were an April Fool's joke that got out of hand; remove them from the language, purge them from the specs, burn any books which mention them, and salt the ground from which they sprang.

And *then* Nuke them from orbit... just to make sure.

After all, when SomeGeneric does not behave as expected, what were they thinking???

Just goes to prove the design rule: "Don't make architectural decisions after a long boozy lunch"

Blame it on the JCP

The current secretive, NDA-ridden way of doing things, means that good ideas can't be separated from bad ideas, by evaluating them in multiple, independant implementations *before* a spec is finalized.

If the JCP bothered to pick up some good ideas from W3C, we'd all be better off.

re: Blame it on the JCP

Actually, given that there is pretty much no way to vote against something, it is amazing that there are any JSRs that have failed at all.

I note that most of the failed JSRs are because the Spec Lead got tired or bored or because there was a similar JSR that it got absorbed into. But even so there are actually one or two that failed to pass one of the voting processes.

It would be interesting to be able to pick and choose bits of the JSR, to separate the good ideas from the bad ideas. But this would work better with larger JSRs than smaller ones I think. Also if we could 'back out' a JSR that was decided to be a bad thing that would be interesting. On the one hand having multiple competing implementations would be good, on the other having a timely turn around would be good.

Also the JSRs are vulnerable to technological fads/fashions. Retrofitting RMI to run on top of Corba probably looked like a good idea in the late 90s when people thought that Corba would take over the world. But now that Corba has pretty much flopped RMI could be 'improved' (by yanking IIOP) because there are things that RMI could do which Corba couldn't.

The correct response to a fad is to build a library which does what you want, not build it into the language. E.g. the correct response to the 'threat' of Ruby on Rails is to say "are we PHP developers? No? Okay then, no problem". A less correct way of dealing with the threat is to slap together 'yet another web framework' which does things the Rails way. The wrong way to deal with the problem is to kick off a JSR to build Rails into Java.

One of the problems with Generics was that anyone that opposed it was labelled "too stupid to contribute meaningfully"*... which is a common trap that many online discussions fall into. I wonder how the W3C avoids the common pitfalls of internet discussions?

*Example: Person A complains that Generics are too complicated. Person B says "read the JSR". Person A says the JSR doesn't make any sense. Person B says "well read it some more".

Generics above all else is broken because it violates the principle of least surprise. That is: people's natural expectations for how things work.

That it doesn't work with other parts of the language (such as... reflection) is really just the icing on the cake.

Native properties

I don't see any benefit in using annotations to label private fields so that the compiler generates "getter" and "setter" methods. That's missing the whole point!!! The "get"/"set" convention was created as an alternative to simply exposing "properties" as public fields: you could then use a method body to return virtual/calculated properties with "getters", or implement "setters" to encapsulate persistence and validation.

Adding extra annotations to define constraints, validation, or sequences is just a hack with limited usefulness, as the expressiveness is going to be less powerful than with a method body (unless you want your annotation to be as powerful as Java code, in which case it might as well be Java anyone, and you've just created an even clumsier alternative to a getter/setter).

The C#-style way of defining properties is far cleaner and involves less clutter: less verbose than getters/setters, easy for IDEs to generate (or just to type), and easy to use in client code (i.e.: x = obj.x instead of object.getX(), something that makes code even more readable when coding in a non-English language).

- Chris

Native properties

Native properties are way, way overdue - +1

Native properties

Here is another vote for native properties! I belive that we also need some way of accessing them from code, so just as you can currently type: Person.class You should be able to type Person.name.property With the increasing use of reflection for thinks like databinding binding, etc we really need a better way of specifing properties than strings. - Luke

Native properties

+1 I'd really appreciate properties as first-class citizens, without the need for string expressions and reflective stuff (no proper compile-time checking).

Native properties

Amen to native properties. The whole setter/getter, JavaBean-would-be-a-way-hip-and-super-confusing-name -for-the-convention thing is crap. I know my IDE can autogenerate all the boilerplate stuff, but it makes Java look antiquated. Properites are a must. Please add them. -Bryan

Native properties

Hey I've just had a rully rully good idea! What if we threw out all those annoying getters and setters... and just marked the instance variables as public! Why has noone thought of this before?

On a slightly less sarcastic note, if you use the dot notation as suggested, then how would the compiler know the difference between calling the getter and accessing the variable directly?

That would make the following method loop infinitely:
Foo getFoo() { return this.foo; }

Native properties

That's why my graduate student, Alexandre Alves, who implemented a native properties prototype, chose a slightly different syntax for property access.

student.@name = "Fred"; // calls setter String name = student.@name; // calls getter

The name field stays private (if indeed there is such a field), and the setters and getters can do other actions such as logging, DB access.

There is no confusion with field access and no loss of encapsulation, just boilerplate avoidance.

Native properties

I just don't like the look of the .@ 'operator'. Not sure what would look better.

student->name = "Fred"; // calls setter String name = student->name; // calls getter

The setter looks very visual basicish. Maybe we haven't finished picking over the corpse of that langauge yet. (Matisse gets about halfway to the usability of the VB gui builder, and I note that it has some of the more interesting features of Apple's Project Builder (the guidelines for component placement), even if they don't always work when you run the app). This is part of the reason I'm so keen to see Simplice ASAP.

Multiline strings (heredoc)

Similar syntax than C# could be good enought.

add more bundle

1. bundle with install4j-like package tool for desktop application 2. bundle with openejb,tomcat as embed j2ee container 3. bundle with xulrunner...(may be it's large footprint is a problem....)

add more bundle

1. bundle with install4j-like package tool for desktop application 2. bundle with openejb,tomcat as embed j2ee container 3. bundle with xulrunner...(may be it's large footprint is a problem....)

Bluetooth support

Cross platform support for writing bluetooth code would be very nice! I suggest that you look into including JSR-82 for the Dolphin release. It has been very successful for Java ME. Linux: bluez Windows: Windows XP Bluetooth API at least. Mac: Mac OS X Bluetooth API Solaris: ?

Bluetooth support

Cross platform support for writing bluetooth code would be very nice! I suggest that you look into including JSR-82 for the Dolphin release. It has been very successful for Java ME. Linux: bluez Windows: Windows XP Bluetooth API at least. Mac: Mac OS X Bluetooth API Solaris: ?

Generics

The problem with Generics was the attempt to meld the Collections framework (Set, List et al) to use them. Far better to have kept Collections as-is, circa 1.4.2, then introduce a new/better framework that doesn't need to worry about backwards compatibility, can handle reification, and move on from there.

Generics

I personally supprt generics and think they were a very good idea. Unfortunately this information is not available at runtime as its been stripped at compile time, so is a half dead feature. The generics info should be kept at runtime. Maybe the compiler could insert some custom annotations which can later be queried for this info.

Generics

The problem with Generics was the attempt to meld the Collections framework (Set, List et al) to use them. Far better to have kept Collections as-is, circa 1.4.2, then introduce a new/better framework that doesn't need to worry about backwards compatibility, can handle reification, and move on from there.

Generics

The problem with Generics was the attempt to meld the Collections framework (Set, List et al) to use them. Far better to have kept Collections as-is, circa 1.4.2, then introduce a new/better framework that doesn't need to worry about backwards compatibility, can handle reification, and move on from there.

tuples

I haven't completely thought through the implications of them in Java, but I often wish for the tuples ala Python and most functional languages. For the most part, I'd like them for return types in situations where two distinct objects could be returned from a method, but yet an aggregate type seems clumsy, wasteful, and challenging to the local terminology.

NIO support for multicast sockets

would be nice. As for the rest of the stuff I'ld settle for no features and less bugs!

NIO support for multicast sockets

Despite my previous suggestion, I agree. Every major JVM upgrade seems to be accompanied by a few weeks of finding work-arounds for mystery JVM crashes.

Web Component and a REAL JMF

...When will java have a core web renfering component? Not just XHTML + CSS like FlyingSaucer, but full boat HTML parsing and proper rendering? Also, to become a real meaningful platform on the desktop, it's gotta play better with the native multimedia devices including frame grabbers. JMF is still such a burden on the end user to use...

Remove all the crap

Dolphin should be a major cleanup release.

First remove all the stuff being added in Mustang, like built in SOAP and webservers.

Then remove EVERYTHING that's been deprecated so far.

Then lock out all the punters who've suggested the crap that was added in Mustang from ever touching a computer again.

Then maybe start doing something about improving Java Webstart.

Then lock the standard so that it can't be corrupted anymore.

Remove all the crap

I'm sure there are many who think that the SOAP+webserver addition in JSE is the greatest thing ever, and they really need it for there application. Great. Let's not deney them that, but rather provide an intuitive system that would automagically download and install/cache/whatever that feature for that JSE instance. You please EVERYONE. Those who want a minimal amount of crap in their JSE get it, and those who want to install every freakin' feature conceived by man can do so. Sun already has the whole "online installer" for JSE. You download a tiny installer and then that installer will download the whole JRE. Why not do that lazily? Don't download everything up front, just install crap as apps need it. (Allowing users to install everything up front if they want of course). -Bryan

Real time garbage collection

I still want a real time garbage collection. A garbage collection that handles multi gigabyte heaps full of objects without drop out s longer than 250ms.

beside versioning & modules,

support for DbC a la Java Modeling Language

copying a few of nice's features wouldn't hurt, either.

support for mutli-stage programming with partial evaluation & specialisation like in Jumbo

support for automatic versioning and api spec files within the bytecode

an ELF format for natively compiled java code

separation of the jvm into osgi components

Bloat

IMHO, Java platform development should stabilize. Focus should be on improving the existing language aspects instead of adding all the feature set needed to solve the world's problem.

Ofcourse, this is required but it doesn't have to be part of the core language. I heard Derby is getting included as part of the language and I am thinking what for?

Incorrect

Derby is not being added to the "language". Derby (or actually a subset of Derby named "JavaDB") will be included with the JDK (not the JRE). So developers will have to download another 2MB of JDK bloat, but the JRE is unaffected. Personally, I don't care about the 2MB of extra size in the JDK download. I have broadband, it's cool. But Sun had better be completely anal about keeping the Dolphin JRE size small (I'm talking < 5 MB) with the ability to pull in Derby (or whatever) with a super ninja commando lazy-classloader-via-apt-getter thingy. The Mustang JRE is *HUGE*. I hope this is because the binaries are busting with debug info in both the C/C++ code and the class files, but I'm not sure that's the case. The 1.5 JRE is a 15-16MB compressed file. How the heck did we get to near 30MB with the Mustang JRE? This is a joke. For all the Swing coolness and desktop improvements that exist in Mustage, desktop Java is screwed with this kind of JRE bloat. Wow, I went off on a tangent. -Bryan

Null handling

How often do we have to handle nulls in our code? How often do we get NPEs? Yet we see very little discussion about how to enhance Java to handle this. Here's a summary of my proposal: Each expression can be defined to ignore nulls at each stage of the comparison, for example: Address addr = session#getProfile#getPerson#getAddress() so, addr will be null if any other element in the expression is null. This would save vast amounts of repetitive null checking. To implement, the compiler creates the code a human would write now with if statements. This concept can be extended further: Each method can declare each parameter as not accepting null by prefixing with #, for example: public #String doSttuff(#StringBuffer buf) {...} Each variable can be defined as not accepting null by prefixing with #, for example: private #Person person; These would allow a tighter definition of a method than at present, again enhancing code quality. Think of it in this way - generics attacked the ClassCastException, this proposal attacks NullPointerException.

Null handling

Interesting and comparable with the @NotNull and @Nullable annotations proposed by IDEs (such as IntelliJ IDEA).

It would probably be harder to support than it appears though, when issues such as serialization, the "transient" keyword, reflection and so on are considered. I do like the idea though and it'd be great if a workable solution could be implemented.

- Chris

Null handling

Also a very good idea! for non-null transients this is solved by not allowing a non-null in a transient declaration for serialization, the classloader can check the non-null condition and throw a validation error if the field is null. for methods this can be extended to throw an 'AssertionException' if the method returns null (okay, still an error instead of a nullpointer but at least more compiler checks can be performed to try to prevent this)

Type-safe Method references.

Give us a way to access a method object with resorting to strings! I want my IDE to be able to refactor all references I might create to an object.

Type-safe Method references.

Totally agree! This would greatly help when binding bean properties to widget controls without having to use strings eg createTextField( foo, foo:bar ); <--compiler checks instead of createTextField( foo, "bar" ) <--not managed by compiler

Type-safe Method references.

"Method pointers" or "delegates" are what you're looking for, and I believe they're being considered for Java 7 (despite not being mentioned above). I sincerely hope they'll be included. C# already has them, and they would be useful for efficiently improving the implementations of many Java frameworks, application builders, and scripting languages.

They're a suprising omission from the poll categories above in fact...

- Chris

Type-safe Method references.

Might as well just swap over to Objective-C.

How about Objective-C support in the JVM? :D

on the contrary new file types = progress.

It's a natural progression to have this extension. Java already has the ability to read/write audio and images. Why should xml be any different? XML and databases are very common, if not ubiquitous, needs among applications. By not having some sort of functionality like this in the core, you force the application developer to tie these worlds together. It really just makes sense.

on the contrary new file types = progress.

I see where your enthusiasm comes from... there's a subtle misunderstanding of what's being proposed...

Java-the-language CANNOT read/write audio or images. Java-the-language defines class structure, method bodies, if...else... blocks, loops, and so on. Java-the-platform (or in other words, the standard APIs) provides classes and methods letting you read/write audio, images and so on. It already has API-level support for XML and databases.

If you work in a domain such as web services, then you'd perhaps benefit from this extension, but say you work in 3D or grid computing, it's most likely to be completely irrelevant (however, in such specific domains, you'd probably benefit from more powerful maths integrated directly into the language).

The best solution is to have a good strong core language with keywords and structures that apply universally. As such, I'm favourable for language-level support for properties (not annotations to automate getters and setters though, as they're pointless and are only interesting to those who don't understand why getters/setters were introduced in place of simple public field accessibility...) and method pointers, but for anything else, domain-specific languages are a much better fit. Try using Groovy or JavaScript or the Jetbrains MPS for example, you'll understand what's being proposed (and can use it now if you like it).

- Chris

Keep XML out of Java, leave it to JVM scripting languages

Rhino/JavaScript is being integrated into Java 6, apparently after being forked to remove native support for XML ("E4X"). And yet it appears Java 7 might include native support for XML. That appears to be very contradictory behavior.

Furthermore, Java-the-language should really remain general purpose to avoid becoming overly-complicated. XML is very commonplace in many application, but so are databases, drawing operations (in 2D and 3D), and so on, so I don't see why Java should become cluttered up with a domain-specific solution.

Scripting languages like Groovy and JavaScript are far better candidates (unless of course forked, see above). They (esp. Groovy) enable lots of domain-specific extensions, going way beyond basic language-level support, and as such are much better platforms for adding this feature. They're designed for this sort of "expressivity".

- Chris

Keep XML out of Java, leave it to JVM scripting languages

Agree 100% - keep XML out of the language.

There are dozens of templating engines that can do this plenty well enough. Failing that, write a preprocessor (gasp) to do the necessary transformations.

Does anyone remember Snobol?

My personal belief is that you do as much as possible outside of the language before putting it in there. Generics were bad enough let's stop there please.

Keep XML out of Java, leave it to JVM scripting languages

I agree that XML has no place in Java as a top level concept. Its just not important enough to be a language level feature. However, there may be a role for builders along the lines of Groovy's builder. The difference is perhaps subtle - native XML is restricted to XML, builders are not - but that difference would benefit Java hugely over time.

Keep XML out of Java, leave it to JVM scripting languages

Agreed.

BTW, sorry for double-posting last comments, the forum engine redirects me to edit my profile when I click "submit" and hides the post (even although it accepted it without notifying me).

- Chris

Keep XML out of Java, leave it to JVM scripting languages

Rhino/JavaScript is being integrated into Java 6, apparently after being forked to remove native support for XML ("E4X"). And yet it appears Java 7 might include native support for XML. That appears to be very contradictory behavior.

Furthermore, Java-the-language should really remain general purpose to avoid becoming overly-complicated. XML is very commonplace in many application, but so are databases, drawing operations (in 2D and 3D), and so on, so I don't see why Java should become cluttered up with a domain-specific solution.

Scripting languages like Groovy and JavaScript are far better candidates (unless of course forked, see above). They (esp. Groovy) enable lots of domain-specific extensions, going way beyond basic language-level support, and as such are much better platforms for adding this feature. They're designed for this sort of "expressivity".

- Chris

Keep XML out of Java, leave it to JVM scripting languages

I keep looking at the grab bag of features that is Mustang and having played around with webservice annotations, I wonder if it is possible to write a 'pure' Javascript webservice? (where pure means slap the @WebService annotation on the javascript function).

How cool would that be?

Keep XML out of Java, leave it to JVM scripting languages

I've been having a look at the example code for rhino so I can now answer my own question.

How cool would that be? Not very. Move along, nothing to see here.

Compiler extensions for XML and DB via XML.

XML is integral to any modern day application at all levels. Thus, Be able to check the validity of an XML file via it's XSD or .java file definition so that applications have operational safety and consistency across file types. Likewise, be able to validate database structures against SQL/ORM queries contained in a subset of the new "compiler-checked" xml files. This ensures that at least structure wise, the database will be able to meet the intended the requirements the application will ask of it. Make all of this easy to use with absolutely minimal configuration.

J2ME support on the desktop

How about adding enough stuff to run a J2ME application using J2SE. AFAIK the whole J2ME thing is supposed to let the same app run in different environments, why not the desktop? (Remember WORA?) I'm not talking a full-on phone emulator - I don't need to be able to send SMS from my desktop, and I'm quite happy using a keyboard instead of clicking on a phone pad. The only times I've ever tried to write a small utility app (bitrate calculator) I had to write it twice, once for the desktop and once for the phone. Ghaaa! Andrew Rowbottom

Full runtime generics support

Being able to access generic type information for objects at runtime.

Full runtime generics support

The problem with Generics was the attempt to meld the Collections framework (Set, List et al) to use them. Far better to have kept Collections as-is, circa 1.4.2, then introduce a new/better framework that doesn't need to worry about backwards compatibility, can handle reification, and whatever new features we'd like, and move on from there.