Interfaces you'd like to see in the jdk

[i30817]

As we all know, there are plenty of good ideas that would be nice to have standardized, but don’t get even get a time of day because it never would get implemented in the jdk (and maybe they shouldn’t).
Still, i think it’s a good idea to have a well thought out interface (as if that was possible without 3 prior implementations!), so as to subtly pressure the library authors to support it, so you can change tools.

I’ve got a “hate-hate-love” relationship with this stuff, because it inevitably ossifies and leaks, but it does sometimes allow to change implementations. Exe:
JAXP, corba, java speech api etc.

Still, i’ve recently thought it would be nice to have a “bug report” interface, so that i could use a library that would report to my project google page bugs on uncaught exceptions and filter duplicates with the stacktrace.
Such a simple interface would be nice encouragement for library writers.

Do you have any such jdk interface longings?

//is there any library that does this stuff for google code?

[sproingie]

I’d like to see them focus on the JVM and leave library design to people who are better at it. Other than jdbc, java.util.concurrent and a few collections classes (but not all), I’m hard pressed to think of anything bundled with the JDK that I don’t tend to prefer a third-party implementation for. Not sound, not GUI, not XML processing, not logging …

[Riven]

Regardless of who is better at it, I think it’s most important that whatever you include in the JVM has to be supported forever and is basically feature frozen.

Adding a new JAR to the classpath is so easy that you’d wonder why there is even a demand for adding libraries to the JVM.

[Evil_1]

java.lang
java.math
java.sql
java.util
java.net

[lhkbob]

Java.io: Permanent & Contract Remote Work.

maybe java.nio

[Roquen]

@Riven

Regardless of who is better at it, I think it’s most important that whatever you include in the JVM has to be supported forever and is basically feature frozen.

I serious dislike these kinds of notions. Lucky (IMHO) there are moving in the opposite direction and modularizing and versioning the various libraries and making it non-monolithic. Backward compatible is preserved (which I assume is your real motivation) without forever & ever handcuffing future versions. If you don’t like a newer version of something, you can always specify the specific previous version you want to utilize.

Pretty much everything I want is at the VM level, which would need to be exposed at both the language and library level.

Examples:

• VM support of structures with library structures that expose SIMD operations.
• VM support of concrete arrays with operations which expose caching hints

For java in the wider sense:

• Mutable primitive wrapper classes (I’m still at a loss why we’ve never had this.)
• High level IR framework (scripting languages, runtime compiling, ease other languages on JVM).
• Lots and lots of contracts via metadata (annotations)

[princec]

The only ones I think that should be part of the JVM are java.lang, java.math, java.io, java.nio, java.net and java.util and their subpackages. Those are the bare basics to make a VM work with whatever language may actually be on top of it all. It might be nice if they ditched all the legacy deprecated methods and classes one day and drew a line in the sand for backward compatibility - after all it’s trivial to rewrite and recompile Java code to use newer methods.

When I chopped the VM down back in 2003 ish I got the entire thing down to a 2.5mb payload (1.4.2 Hotspot client) capable of running fully featured games. I asked Sun a lot about licensing such a VM but apparently there was so much political red tape involved in actually doing so it never happened. I fear there was an opportunity missed.

Cas

[nsigma]

@princec

When I chopped the VM down back in 2003 ish I got the entire thing down to a 2.5mb payload (1.4.2 Hotspot client) capable of running fully featured games. I asked Sun a lot about licensing such a VM but apparently there was so much political red tape involved in actually doing so it never happened. I fear there was an opportunity missed.

Of course, with OpenJDK there wouldn’t be any political shenanigans about doing this. But are many people doing that now?

[Roquen]

From the hand-waving future directions stuff I’ve seen that seems to be exactly the direction that they’re intending on moving in. No more multiple JVMs (from Oracle). Just HotSpot with various different components depending on if it’s ME, SE or EE. How is not clear (conditional compile or broken into shared libraries). On the classpath side, no more monolithic single version (forever backward compatible), but broken into chunks (granularity is unclear) which are versioned. It seems logical that the minimum required to execute would be a single chuck…but stuff isn’t always logical to me.

Of course, with OpenJDK there wouldn’t be any political shenanigans about doing this. But are many people doing that now?

I don’t see how this really changes anything (for the moment), unless there as been some licensing changes of which I’m unaware. But (again from hand-waving papers) addressing the issue of minimal embedded (from a distribution standpoint) is one of the stated reasons for the above moves.

[nsigma]

@Roquen

Of course, with OpenJDK there wouldn’t be any political shenanigans about doing this. But are many people doing that now?

I don’t see how this really changes anything (for the moment), unless there as been some licensing changes of which I’m unaware. But (again from hand-waving papers) addressing the issue of minimal embedded (from a distribution standpoint) is one of the stated reasons for the above moves.

Because as long as you keep it GPL w/CPE you can strip it down as much as you want! And use it wherever you want as well for that matter. Interesting side note - GPL cannot have field of use restrictions - so if Android had been forked off OpenJDK there wouldn’t be a problem. Just can’t call it Java.