Migrate off of jsr305

[zyxist]

There are several issues with using jsr305.jar by Guava.

JSR-305 is dormant, has been for a long while and shows no hope of ever producing an agreed set of annotations in our lifetime. Further more these annotations use javax. packages which it is not possible to use according to the Oracle Java binary licence, so applications can not use and ship these dependencies along with a JRE without violating the Oracle licence agreement.

F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation.

The JSR-305 group has not defined any official releases according to its jsr page so the only implementations is a seemingly random implementation provided by the FindBugs team. Even if the team where experts on the JSR (which some where) they are not official as there has been no vote and are not available from the JSR hompage - so the javax package name restriction still applies.

Using jsr305 causes additional issues, if Guava is used in a modular JDK9 applications, because it puts the annotations into javax.annotation package, which is also used by a couple of other JAR-s and a legacy JDK module java.xml.ws.annotation. If one wants to create a modular JDK9 application with two dependencies to conflicting JAR-s, Java refuses to compile and run it because of a package split. Example:

• Guava -> forces us to require jsr305 automatic module,
• Dagger -> forces us to require either java.xml.ws.annotation or jsr250 automatic module.

All of the modules use javax.annotation.

Findbugs has been rebooted as Spotbugs and they are going to make a switch from JSR-305 to their own internal annotations in version 4.0.0 that do not break anything:

https://github.com/spotbugs/spotbugs/pull/180

I think Guava should consider switching to them in order not to pollute application dependencies with jsr305 JAR.

[berry120]

@cpovirk Thanks very much for the update in any case - that's appreciated. I'd echo previous replies in that it'd be fantastic to have at least something in the public domain to cement the project's existence, the companies involved etc. - otherwise it's difficult to gauge progress, and we're always likely to have yet more competing frameworks that pop up aiming to do similar things, further complicating the situation.

But I totally appreciate the design decisions in such a project aren't always obvious or easy, and it's better to take a while and produce something great, rather than to rush something out too quickly.

[cpovirk]

I shared some slides with you. (See slide 21 for list of companies involved.) We're trying to figure out the best way to share the slides publicly, since they were created with with an @google.com account.... In the end, we may just make a copy. We'll see.

[sdavids]

@notnull ... lowercase annotation name?

[mmichaelis]

Well, I was astonished regarding lowercase, too... but it has one advantage, if we make the annotation type annotations: It just reads very similar to any other modifier in the list:

public static @notnull String getNotNull() { ... }

Not saying, that I am convinced yet... but I like the idea to think about it.

[berry120]

@cpovirk Thanks for that. I notice the last slide mentions speaking to you to participate - long shot I know, but I'm very happy to review anything if that's still an option / something that would be useful. (Though I will freely admit up front I'm just a standard lowly Java developer. Haven't any special background in these issues, nor am I the author of a popular library!)

[soc]

@sdavids @mmichaelis Yes, that was largely the intention behind this. Given that the annotations in the past had a rather large footprint/required continuous efforts to use¹, avoiding that annotations draw away the attention from the types itself was also a motivation.

(Current status is that there is some work on the javac plugin ongoing; an Intellij plugin is probably next on the list.)

¹ This is also why @notnull goes on type declarations, not on method params/returns.

If you have further questions, maybe it makes sense to move elsewhere to avoid disturbing people here dealing with their paperwork.

[cpovirk]

@berry120 In the next few months, we hope to have the beginnings of a User's Guide. At that point, standard lowly Java developers will be the ideal reviewers ;) I've set myself a calendar reminder to see what we have for you a little down the road.

[berry120]

@cpovirk Sounds great, thank you!

[garretwilson]

The only doubt I have is: at what date do we decide that it's really not going to happen, regardless of the good intentions of good people?

Here's what I said almost four months ago:

This is great news, and comforting just knowing that there is finally an effort to produce such a thing, as it is sorely needed. The community is grateful and probably most don't want to rush things, but it would great if there was some way we could track the process and know the status. There's always the fear that these sorts of efforts, especially if they are hidden, might stall, die, dry up, and blow away (and we may never know, thinking it was still ongoing). …

We don't have public materials you can review yet at this time.

And that lends to the fears I mentioned. "If there's no picture, it didn't happen" sort of thing. Even a web page with a status, milestones, and a periodic blog entry would be a super start.

I for one never asked for a user's guide yet; I would be overjoyed to see a web site even. If there is really some momentum behind this, why can't a web site be put up with anything?

I was afraid this was too good to be true and would be kept being postponed until "never". So I challenge you to give us a specific date that you'll have at least a web site up with an overview and a status. If that date passes with nothing, it might be an indication that we should start looking into alternate efforts. Because we can't just keep believing rumors forever.

I don't doubt your intentions at all, and I would be so excited that this is real. But until you actually come up with something—anything—it's beginning to sound like vaporware.

[cpovirk]

Our web site has minimal content. We can continue to share the slides from last year with anyone who is interested, but it's completely fair to say that that's last year and that we should have produced something else by now. All of us who are involved feel the same way.

At this point, I wouldn't ask anyone here to make any changes to their plans based on the assumption that we'll ship anything by any particular date. Arguably there was no reason for us to tease the project in the first place. The best way to avoid contributing further to the overall uncertainty and frustration around nullness annotations may have been for us to lay low. We will certainly update anyone interested when have something concrete.

[garretwilson]

I appreciate your candor, but frankly I have little hope that anything will come out of the effort. Please, before you react, let me explain why I say that.

Replacing JSR 305 can easily become a rabbit hole because it means so many different things to so many different people. Do we just want annotations just for documentation purposes? Do we want a full-blown library to do static analysis? Do we want to include thread/concurrency annotations? The list of possibilities is very long.

1. Therefore it is essential that your effort have at the minimum a mission statement indicating the problem you wish to solve and the limiting scope. Otherwise you'll be embroiled for years with a bunch of different interests arguing .
2. You also need some sort of charter and procedure for participation. Otherwise you'll just get something pushed through that meets the needs of the heavy players (for example Google and JetBrains, just to randomly pick two companies) but not something general developers can rally around.

If you have a mission statement, a charter, and membership, you have a working group. But JSR 305 had working group, and it went dormant. Why would your effort succeed where JSR 305 failed? One answer might be that you have a more limited scope or a better procedure. But do you?

The fact is that if you don't even have a mission statement and a description of scope to publish, I strain to imagine how you could succeed where groups like JSR-305 failed. Without some roadmap, even if you do produce something it could wind up being yet another competing rather than unifying library.

I hope for the best, but sincerely, to make this succeed you have to be realistic and do a little planning.

[kevinb9n]

Hi,

I accept your opinion that we are vaporware and we will fail. I might think so too in your place. "It will probably never happen"; that's a very sensible assumption.

I think I would be less inclined to assume incompetence and express said assumptions to the team, though. If I did that, I would be illustrating to the team exactly why their lives are going to get harder once they do go public.

We'll go public when we're ready to. And yes, it will be before any design decision has been finalized. We know that it won't be even remotely fun when we do, but of course it's an important step.

If anyone reading this has a talent for participating constructively in amorphous design decisions and likes to think deeply about nullness and type systems, please reach out to me offline. My work address doesn't include the "9n" part. You could be very helpful to our project a bit earlier than we are ready to put time into fending off attacks.

Thanks!

[garretwilson]

I think I would be less inclined to assume incompetence and express said assumptions to the team, though …

I don't know who you were replying to, @kevinb9n , but I want to make clear that absolutely nothing that I said was in any way discussing competence. I have no doubt all of you are very competent and have great intentions. My concern centered around process. You absolutely must have an objective and a scope, regardless of how competent you are. And if you have an objective and scope, it concerns me that you don't publish this objective and scope. And if you don't have an objective and scope, it worries me even more. I don't know how much clearer or simpler I can make my point.

If anyone reading this has a talent for participating constructively in amorphous design decisions and likes to think deeply about nullness and type systems, please reach out to me offline.

I would love to participate and help make your effort a success! I will contact you immediately.

You could be very helpful to our project a bit earlier than we are ready to put time into fending off attacks.

Maybe I didn't understand that part, but why would anyone be attacking your effort? You have a huge audience here that is clamoring for your success, that is hoping every day to see a glimmer of the results of your work being successful. Making it public will help make it better because we can make sure it meets everyone's needs, or for those whose needs it does not meet, that they understand their needs lie outside its (well-defined) scope.

I'll send you over an email. (You didn't mention the company, but from your conversation I'll assume it's Google). Good luck and talk to you soon.

[kevinb9n]

I'm sorry for not being more direct.

Not having a scope or mission is a very different thing from not being ready yet to publicize your efforts, including that scope and mission.

If we had worked as much as we have without ever realizing that we needed to understand our scope and mission, then I would be the first one to think us incompetent.

So it just felt rather pointed, to me, that you felt we needed you to explain that to us.

Maybe I didn't understand that part, but why would anyone be attacking your effort?

Because it's the Internet? Perhaps substitute a word slightly less strong than "attacks". But again: we are not afraid of it, we are simply not yet ready for it.

I've alluded to "readiness" to expose our work to outside scrutiny, and here's at least a sense of what I mean: if you can already easily tell what the major criticisms will be, and are already working on addressing them, then publicizing is not only pointless but also wastes a lot of people's time.

You have a huge audience here that is clamoring for your success, that is hoping every day to see a glimmer of the results of your work being successful.

Believe me, those are the people who largely stay quiet. :-)

[garretwilson]

If anyone reading this has a talent for participating constructively in amorphous design decisions and likes to think deeply about nullness and type systems, please reach out to me offline. My work address doesn't include the "9n" part. …

@kevinb9n I just wanted to note that a week ago, in response to your call for participation, I reached out to you at what I believe to be your email address based upon your description, but I haven't heard back. If you would like to clarify how I can contact you, or if you would like to contact me, I stand ready to contribute to your project.

[soc]

@garretwilson I think they just went ahead with their stuff at https://github.com/jspecify/jspecify.

[kevinb9n]

Yes, we've been working there for a while, and not much good will come of public attention yet at this point.

[soc]

@kevinb9n Perhaps replying to that person's mail would have been a good way to achieve that? ;-)

[kevinb9n]

A very observant point.

[rossbu]

it looks this issue has been sitting for a decade, and it surely will be another decade just to JSR Nullable and NotNull ?? what's going on? just because One guy William left Oracle, the whole industry can not create a unified standard ?. what a story!

[soc]

@rossbu The approach and scope in their new project hasn't changed from the previous failed attempts. This architecture astronaut style of complexity has been the main reason for the lack of success of these annotations (despite tons of goodwill from basically everyone) til now. Until this is addressed, I wouldn't expect a different outcome.

[kevinb9n]

In any case, we're hard at work.

[cpovirk]

I've owed an update here since the 31.0 release, but it's been blocked behind some work to test out some improvement's in Kotlin's null-handling. For the moment, there's an update on our usage of nullness annotations at the bottom of the release notes for that version. We're trying to make changes gradually and without regressing the existing nullness information available to the various tools that consume it.

[jmott]

My vulnerability scanners are now all complaining about Guava because the com.google.code.findbugs:jsr305:jar:3.0.2 dependency it pulls in is flagged for the recent log4j remote code execution vulnerabilities. Any update on this project to move away from jsr305? Thanks!

[ben-manes]

The poms for jsr305 and guava don't show a log4j dependency (at any scope). It sounds like a false positive.

[kevinb9n]

Since making this happen is in some ways more important to JSpecify right now than it even is to Guava, we're also tracking this in https://github.com/jspecify/jspecify/issues/239, and that might be a better place to follow along.