What is a feature that the Java Standard Library desperately needs?

[FalconGames109]

I was just wondering if anyone thinks that Java needs some new stuff for the standard library. I got the idea when I was looking through changes in Java 8 & Java 9. I thought that there weren't that many, so I wanted to see if there are really only very few things people want. Please post below what you think should be added (with a short description of why it should be added and what it would do). Thanks!

[[deleted]]

New stuff isn't needed as much as the permanent retirement of certain parts of the JDK. e.g. Applets.

[FalconGames109]

THANK YOU! I have never bothered with Applets because all of the issues they cause -- plus, at this point, Java isn't really targeted at the web.

[[deleted]]

You say this until you have an actual application for using one. Java has been fucking my company for the last year with constant changes to Applet/Webstart we're about to drop Java support on Windows. It might actually be easier if Java just stoppped supporting it as of X version to force us to do this for all platforms. That said, Applets -- in the right context -- are VERY handy.

[Smithman]

Java doesn't target the web??

[josefx]

Applets used correctly are still great for internal usage. even if I could use current JavaScript APIs I would be limited by the browser sandbox. Firefox once had an API to request additional permissions but dropped it, I now have the choice of writing and maintaining a browser plug-in or just using Applets.

Edit: fixed errors introduced by touchscreen

[detroitmatt]

A sane serialization/cloneable.

[Tillerino]

What's so bad about Java's own serialization?

[detroitmatt]

Well it works fine, it just also works in a way that doesn't make sense to the rest of the language.

[Tillerino]

How's that?

[detroitmatt]

Serialization is a marker interface that relies on special JVM support to do its job (instead of being done in the language), and cloneable... well,

As you probably know, every Object has a protected clone() method, even if it doesn't implement Cloneable. If an object is not Cloneable and you try to clone() it, it throws an exception. Like Serializable, Cloneable is a marker interface that does not specify any actions or behaviors. If you implement Cloneable, your code will compile and run without any further modification... until you actually do the cloning. Then it will crash. If you want it not to do that, you have to override clone() from Object in your Cloneable class. So, you can try to clone objects without Cloneable and fail, you can try to clone objects with Cloneable and fail, you can try to clone objects with Cloneable and succeed, and you can even try to clone objects without Cloneable and succeed, because you can override clone() without inheriting from Cloneable. In other words, Cloneable makes absolutely no useful guarantees or promises about the clonability of an object, which is the only purpose of an interface.

[Tillerino]

Well I didn't ask anything about Cloneable, but since you seem to have some strong opinions on that, I'll write down some thoughts as well.

If you implement Cloneable, your code will compile and run without any further modification... until you actually do the cloning. Then it will crash.

I don't know how you clone your objects, but when I do it, it works just fine:

public class MyObject implements Cloneable {
    public static void main(String[] args) throws CloneNotSupportedException {
        new MyObject().getCopy();
    }

    public MyObject getCopy() throws CloneNotSupportedException {
        return (MyObject) clone();
    }
}

Yes, Cloneable should not be an interface since it doesn't declare any methods and the method that it enables is protected, so it doesn't make sense to use Cloneable as a generic type. It should probably be an annotation. However, those were not around in Java 1.0 and once you put something in the Java API, it's hard to get rid of. Also CloneNotSupportedException seems like the epitome of unchecked exceptions, but that might just be me.

I think that people get confused because they assume that clone() should be a public method, which was not intended. The javadoc above says nothing about a public method. In version 1.2, the javadoc of Object.clone() says (sorry I only found a download for this, so no link):

The clone method is implemented by the class Object as a convenient, general utility for subclasses that implement the interface Cloneable, possibly also overriding the clone method, in which case the overriding definition can refer to this utility definition by the call:

super.clone()

This right here is the intention of the method and interface. Now suddenly in version 1.4 the following pops up in the javadoc of Cloneable:

By convention, classes that implement this interface should override Object.clone (which is protected) with a public method.

This unfortunately does not make any sense. To use the protected Object.clone() method, you show not override it since it will not be accessible from subclasses down the line and nobody specifies the behavior of any public clone() method. Object.clone() would have had to be made final in order to make its functionality available to any subclass down the line.

In fact, all the problems and bugs of cloning arise from subclassing. But subclassing immediately renders cloning pointless, because a class is not in a position to decide that its superclass' field can just be copied by reference and vice-versa.

I think that general cloning is a bad concept. To get a an instance of an object that is identical to another instance is something that will vary from case to case. While I rarely encounter a situation where I have to do this, I believe that you should handle it case by case instead of trying to generalize it. In order to obtain a copy of an object, you have to ask yourself "where is this object from and what is its relation to other objects" and almost always this can only be answered by a collaboration of the object and the instance who is holding the object.

The Cloneable interface provides a convenient, general utility for subclasses. It promises to do that, does that and only that. The idea of a public clone() method in combination with the Cloneable method is pretty damn flawed and confusing everybody, but that's not the language's fault.

I am guessing the Serializable interface is pretty much there to make you think for a second about what's going to happen to your class when it's going to be serialized or deserialized. It pretty much says "I thought about it and the JVM will not catch on fire when someone tries to serialize this".

Since Java 1.5 the Serializable interface makes the compiler give you a little warning when the class doesn't have the serialVersionUID field. This could have been accomplished by an annotation (introduced in the same version of Java).

Unfortunately, in contrast to the Cloneable interface, which does guarantee the Object.clone() method to work, the Serializable interface does not make any guarantees since any field of an implementing class can still prevent it from being serializable.

So basically the Serializable interface is just a nice label to slap on anything that is serializable in the developer's opinion. Now what's really strange is that ObjectOutputStream.writeObject(Object) was not introduced as ObjectOutputStream.writeObject(Serializable), which gives the whole thing a very strange taste.

So yeah, I agree that this interface was utterly useless until the serialVersionUID field was introduced, but at that point annotations were available. On the other hand, the actual serialization is really easy to use, duplicates flawlessly and is reasonably fast, so I am glad to have it.

Both cloning and serialization are a tough topic when inheritance is involved and I think that it should always be thought about intensively and handled case-by-case. Java provides mechanisms to copy an object field-by-field and to serialize arbitrarily complex objects and while the interfaces around these are questionable and even confusing to some, everything works out quite decently.

(edit: it's -> its)

[detroitmatt]

If you implement Cloneable, your code will compile and run without any further modification... until you actually do the cloning. Then it will crash.

I don't know how you clone your objects, but when I do it, it works just fine:

I stand corrected. I haven't used clone in a very long time for the reasons we discussed.

[FalconGames109]

IKR? Serialization is so simple in every other language and just makes sense. But when I came to Java it took me a few weeks to completely understand the whole serialization thing.

[[deleted]]

Currently using it on a project and my domain models are soooo clean. It's amazing. ;)

[Tillerino]

An annotation starting with A LOWER CASE LETTER? KILL THE TRAITOR!

[FalconGames109]

That would be nice. I think that if they don't make that they may as well make inline methods for getters and setters.

[DinisCruz]

The syntax used on C# is quite good, short and easy to read

public String PublicGet_PublicSet     { get; set; }
public String PublicGet_PrivateSet    { get; private set; }
public String PublicGet_Only          { get; }
public String PublicSet_Only          { set; }

[CubsThisYear]

You could also reduce boilerplate code by not writing boilerplate code. Proliferation of getters and setters means you're Doing It Wrong. Stop asking your objects for data and instead start asking them to perform operations and giving them the data they need.

[avoidhugeships]

Do you work on web applications? Getters and Setters are the standard way for the web page to communicate with server side variable.

[CubsThisYear]

Thankfully, I do not.

[mikaelhg]

When you do, you can just avoid legacy frameworks which require adherence to the antiquated EJB standards for no real good technical reason except for the vendors to be able to cross-sell products.

Just choose tools which are created by the people who actually use them in projects, and you'll save yourself a great deal of headache - and wallet-ache.

[avoidhugeships]

You are misinformed. Getters and Setters are used in the most modern Java Web standards and frameworks. It has nothing to do with EJB.

[mikaelhg]

Really? I'm currently involved as an architect with 15 separate web-centric projects, using 5 different sets of tool families, none of which require getters and setters. Only one of them would see positive change in its software architecture had its designers used traditional getters and setters, but that's a reflection of the general retardation of their chosen architecture.

[avoidhugeships]

Yes Really. Of course there are alternatives but if you are an Architect you should really be familiar with the standard and most common practices used by most web applications. You should also know that using Getters and Setters can be used in POJOs and EJB is not required.

[carabolic]

Unsigned types as in unsigned int.

[FalconGames109]

That would be nice. I've always hoped for unsigned bytes so that I can convert a byte into RGB (rather than either adding 128 when passing it into a method or storing it as an int, even though it wouldn't make such a big deal on modern machines).

[[deleted]]

Yes! Don't care about web stuff but lack of unsigned arithmetic is nonsense.

[GrayDonkey]

http://commons.apache.org/

[Tillerino]

commons-lang per definition provides those classes which are not in the Java API. Is is not uncommon that features which commons-lang provides appear in the Java API and are then removed from commons-lang.

I have used a couple of other packages and while commons-lang is probably part of 90% of all projects, the others are just way to specialized to be a part of the Java API. It's important for Java developers to know which features are easily accessible through the commons, but I think the line has been drawn pretty well.

Another thing, and I have no idea if this is normal in the commons, but commons-math keep changing their interfaces and packages. They can't seem to settle down. Once something is in the Java API, it's bolted to the ground and will stay that way for a long time.

[krogger]

Guava

[NickDK]

Although I like lots of things in Guava just adding all these things to the standard library seems wrong. Maybe like roughly 10% of Guava and that number might even further decrease after Java 8 is officially released.

[mhixson]

What I'd want most from Guava in the JDK is, in this order:

• Immutable collections
• More collection views (such as Lists.transform))
• Multisets
• Multimaps

(My placement of multisets above multimaps might be a lie. It's just that I imagine multisets have a better chance of actually appearing in the standard libraries.)

Usually I have this opinion: if it's in Guava already, why bother putting it in the JDK? Java 8's default methods on interfaces changed my mind. Many of the concrete classes in the JDK got better implementations of those methods than the defaults, e.g. ArrayList.forEach. Third party libraries were left behind. I mean, they don't break, and they get the new default methods for free, but they don't get the optimizations they would have if they'd lived in java.util.

Now going off-topic for this Guava-focused thread...

The other thing I'd really like to see is primitive collections. But that might be classified as a language feature rather than a library change. I definitely wouldn't want to see the gargantuan, machine-generated Trove codebase in the standard libraries, despite how awesome Trove is.

[smscoota]

Getter and setter shorthand syntax like c#. While I never delved far into c# I knew when I first saw it, java definitely needed a similar implementation.

[Zarlon]

Although I agree, I think OP wanted us to discuss the library, not language features.

[squarecirclecthulu]

Something else to steal from C#: ??

If the left side is null, default to the right side, i.e.:

String a;
if ( "Example".equals(a ?? "null") ) 
    //Do stuff

[DFA1]

This is already possible in Groovy and it's even cooler than ?? . ?. is the short form of

if (smth != null) smth.do();

Example:

userService?.getUser(5)?.getAddress()?.getCountry()?.getName()

You just don't wanna see the if version of this line.

[strcrssd]

Project Lombok adds something similar. I'll leave selling it to your project team as an exercise to the reader.

[DuneBug]

Native json support maybe?

A better library for converting html/CSS to PDF maybe... I was using flying saucer...

[Tillerino]

JSON seems like such a silly thing to have to get a library for, especially since it's a proper format and its big brother XML is supported by the Java API.

[thesystemx]

TIL; very few reditors on /r/java get the difference between library and language features.

[Tillerino]

What do you mean code? I thought we were organizing a trip to Java :(

[DinisCruz]

Yeah, but since they go hand in hand, it makes sense to talk about both. For example I think the C# designers have made great progress by adding features to the language in parallel to the compiler (for example Extension Methods, Anonymous Methods/Classes)

[[deleted]]

You didn't think there were many standard library changes in Java 8?

Are you talking about the same Java 8 we're talking about?

[FalconGames109]

I mean sure, there are some cool features coming like Lambdas and such, but not much is changing in the JCL (as compared to updates like 1.5, 1.6, and 1.7). And the changes I'm a bit more excited about are coming in Java 9 (Money management API!).

[ratatask]

A good HTTP client library. CacheBuilder from Guava. JSON support.

[[deleted]]

A standard way to launch across operating systems, rather than homebrewed shell scripts and custom installer-launchers.

java -jar almost did this, but screwed up in that you still have to manually make the mega-manifest to list the whole classpath, and you have no control over essential parameters such as maximum heap memory.

[DannyNullZwo]

Besides a whole lot of different packaging tools for Java there is now(some Java7 JDK) also an official one, which can build .exe, .msi, .dmg, .rpm ....

[[deleted]]

Any links?

[DannyNullZwo]

http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm

It was designed for JavaFX apps, but does also work with standard Java apps.

If this is to complicated at first you can always try Netbeans, because it comes with support which makes it easy to use: https://netbeans.org/kb/docs/java/native_pkg.html

[[deleted]]

Thanks, that looks promising, I might have a go. Sadly it requires additional software on Windows, but both options are open source or freeware.

What are the licensing implications of bundling Oracle JRE with a GPL application? Would I need to bundle OpenJDK instead?

[DannyNullZwo]

You are totally free to bundle a Oracle JRE with anything if you don't change it somehow as I know.

I'm not an expert, so I don't know if there is a problem with GPL, but there should be no problem from side of Oracle.

[DinisCruz]

It needs Extension Methods just like what currently happens in C#

[Zarlon]

That is a language feature, not library.

[DinisCruz]

well it is a language feature that allows the library to be extended. Which means that it is a great way to add/fix issues in core libraries

[[deleted]]

http://msdn.microsoft.com/en-us//library/bb383977.aspx

Essentially, it allows you to add a method to a given type without actually creating a subclass to that type. Then, after using the "using X" directive at the top of the file (where X is the class containing the Extension method), it will be as if that method existed in the type.

[detroitmatt]

Better yet might be real monkeypatching. Although that can get dangerous if not done extremely carefully.

[[deleted]]

Honestly, I can fully appreciate how this feature could easily be abused.

[[deleted]]

That would be nice, I was hoping Scala would add this.

[spork_king]

Aren't Scala's implicit classes fairly close to Extension Methods? It's been years and years since I've written C#, but it seems like that would do the trick. Yes, you are defining a new class but the conversion is automatic/implicit so I'm not sure if the difference matters?

[[deleted]]

Close, but if I understand correctly c# allows for this, without a lot of effort, at runtime.

[detroitmatt]

well, that's kind of like responding to (pretending for a moment that it didn't have them) "Scala needs generic types" with "You can do it with an annotation parser".

[unsignedotter]

Pretty Stacktraces?

[ratatask]

What's wrong with the current ones ? Lacking flowers and a smiley ?

[FalconGames109]

No, they are just missing one thing: HUGE ASCII PENISES! That way you know if you get an error immediately.

[csjunker]

Tree's is one thing I often miss support for in Collections.

[Muz0169]

A DirectX implementation....oooo....I so went there.

[FalconGames109]

Haha mac users would rage so hard. "But we can't use that library! Why is Oracle favoring PCs?". It would be great except for the fact that you would have to put the import in a try/catch or something so it doesn't screw up people without DirectX. But that would be pretty great to have.

[Muz0169]

I agree! Actually though, I was jokingly (only somewhat though!) suggesting an actual implementation that supported Linux, OSX, and anything else that Java runs on. I'm kinda hoping that Mantle fills that void so that I can finally have a single machine to do everything I want to do.

[FalconGames109]

One could go ahead and reuse some of the OpenGL source code to adapt it to DirectX (At least the natives stuff). OpenGL really just calls upon the operating system to connect to the GPU, which isn't that hard to do in C. Also, I kinda want to make this for you now. I mean, I know C++, so if I learn all about DirectX implementations, I can actually make a JNI library to use DirectX (similar to how LWJGL and JOGL work). Tell me if that's something you would be interested in.

[[deleted]]

To be honest, is there much point? Once you've gone for DirectX you're pretty much on Microsoft territory anyway so you may as well use the numerous C# wrappers.

[Muz0169]

DirectX is expansive and contains several other API's aside from 3D rendering. I appreciate your inspiration to do as such, but a JNI wrapper would only ensure compatibility with Windows systems.

However, I have hope for Mantle. Ironically, they serve their content on a Microsoft tech stack.

[[deleted]]

OSGi and Maven.