Help us with choosing issue BG JUG adopt hackathon

Ivan St. Ivanov at
Tue Dec 2 21:00:25 UTC 2014

Hello core libs developers!

I am Ivan from the Bulgarian Java User Group. We are adopting OpenJDK for
quite some time in our JUG. So far we have done some sessions in our
community as well as on conferences in Bulgaria and neighboring countries,
where we just talked about the project and the adoption topic. We also did
some hackathons, where we showed the people how they can download, build,
change and use the changed images of the latest version of OpenJDK. On the
last Java2Days conference in Sofia we even went further and together with
Mani Sarkar from LJC we did Jigsaw project hands on lab, where besides
explaining the roadmap and JEPs for the modularity, we built and ran JBoss
Forge with the image that we built from the latest source from jigsaw/m2

And now we decided that we want to go one step further. We think that we
are ready for our first real contribution to OpenJDK. Of course, we want to
start small, we don't plan to implement project Valhalla in a day ;)

We took our time and analyzed the open issues that we found in the OpenJDK
JIRA. We selected a few items and before picking one for our hackathon on
11th December, we decided to ask for your opinion. So, this is what we
found appropriate:
*Throwable convenience method: String getStackTraceString()*
This stays open for quite some time. Maybe we could add a default method to
java.lang.Throwable or static convenience method to another class?
*(coll) Generics and collections support for generic arrays*
We believe that this issue was reported ahead of its time :). It basically
proposes adding new methods to the Collection interface, but the proposal
came in 2004! Now with default methods it is finally possible. We would
argue as well with the syntax: instead of addAll(<? extends E>[] array), we
would propose to have addAll(E... array) method (the same applies for the
other three proposed new methods as well).
*(ch) Retrofit scatter/gather interfaces with varargs where possible*
I guess we need to discuss this more. Especially the comment "I think this
job must be generalized to the whole API." We know that Joe Darcy and the
team already ran some effort on cleaning up things like that, but if you
still know about generifying/varargsifying/coinifying/labdaifying (wow! :))
internal APIs, we would be more than happy to help.

We that, I would conclude the list. Do you think that we can work on one of
these next Thursday? If not, what else would you propose?

We really hope that we'll be able to do such hackathons once per two months
at least. And our next goals is to participate in Jigsaw once it gets to
its final straight!

Thanks and regards,

More information about the core-libs-dev mailing list