Adopt OpenJDK @ BG JUG, Step 2

Wed Apr 2 12:30:26 UTC 2014

In general, trying to do multiple different unrelated things in a single change is a  bad idea. Not just because it introduces artificial complexity into a simple operation, as it requires reviewers to chip in on two distinct issues. It also means that a change is more likely to get stalled out during the review phase, as with every new separate concern to review the chance of having to spend another review round only goes up, bringing us back to the artificial complexity during review. 

More specifically in a case like this, where you are trying to lift parts of the class library to use a new feature, it is rarely done on a class by class basis, unless the complexity and risk of change would warrant it (and if that was the case, it'd be a bad item to start learning the ropes on). Otherwise, you'd have dozens if not hundreds of spurious change sets for 'applied new feature x to class y' with the corresponding bad human effort to benefit ratio.

A good example to follow is being set by Joe Darcy and his Javac lint warnings eradication quest - see core-libs-dev archives for details.

So, in short - pick one thing you want to do, like strings in switch, get some idea how much work that is going to be and make a plan how you are going to do it and how long it's going to take, and then post to say core-libs-dev about your idea before you post a patch. 

The reason for starting a conversation  at the ideas stage rather than at the 'here's my patch, someone please pull this in please' is quite simple - as with many things in life, timing is everything, and there may be other cleanups or integration efforts going on without one necessarily being aware of it at the time of patch submission.

Cheers,
Dalibor 
--
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214<tel:+494089091214> | Mobile:+491737185961<tel:+491737185961>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

> On 01.04.2014, at 20:41, "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com> wrote:
> 
> Hey Martijn,
> 
> Here it is: http://www.
> dmitryalexandrov.net/webrev/
> 
> Thanks,
> Ivan
>> On Apr 1, 2014 6:51 PM, "Martijn Verburg" <martijnverburg at gmail.com> wrote:
>> 
>> Hi Ivan,
>> 
>> Are you able to host it in a non Google Drive location?  Unfortunately
>> Google Drive doesn't act as a 'real' web server and so you get the raw HTML
>> as opposed to the output displayed.  I/we should then be able to give some
>> advice on the suitability.
>> 
>> On the other question, it's usually best to have one patch per issue.
>> 
>> Cheers,
>> Martijn
>> 
>> 
>>> On 1 April 2014 16:45, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>> 
>>> Hi Rory,
>>> 
>>> Yes, I have read it. I am asking something different. My question is
>>> whether, provided we follow the process, the type of change would be
>>> accepted. Or it would get rejected only because it does not bring any
>>> tangible value to the project.
>>> 
>>> Cheers,
>>> Ivan
>>> 
>>> 
>>> On Tue, Apr 1, 2014 at 6:30 PM, Rory O'Donnell Oracle, Dublin Ireland <
>>> rory.odonnell at oracle.com> wrote:
>>> 
>>>> Hi Ivan,
>>>> 
>>>> Did you have a chance to read Martijn's New Contributor wiki page here<
>>> https://wiki.openjdk.java.net/display/Adoption/New+Contributor>
>>>> 
>>>> It describes step by step how a new contributor should get involved.
>>>> 
>>>> Rgds, Rory
>>>> 
>>>> 
>>>> 
>>>> On 31/03/2014 20:39, Ivan St. Ivanov wrote:
>>>> 
>>>> Hi folks,
>>>> 
>>>> I am Ivan from the Bulgarian Java User Group. We started end of last
>>> year
>>>> our Adopt OpenJDK efforts. As proposed on the wiki, we started with
>>> initial
>>>> presentation of the concepts to the JUG. We had a dedicated JUG meeting
>>> and
>>>> two talks by Mani from LJC on a couple of conferences in Sofia. Then we
>>> set
>>>> up Open JDK VM, that we shared to be used by our JUG members. In fact I
>>>> think that Mani's quick start document is referring to our VMs for
>>>> download. Last month we had Lambdas workshop in the JUG, where along
>>> with a
>>>> presentation of the great new feature in Java 8, we did a hands-on lab
>>> on
>>>> the well known Lambda tutorial.
>>>> 
>>>> Now, it's time for the next step. According to the wiki, a good thing to
>>>> start with is doing some small fixes like applying project coin or
>>> lambdas
>>>> to some JDK methods. I decided to set up locally Java 9. Earlier this
>>> week
>>>> I met (guess whom?) Mani at JavaLand and he advised me to run IntelliJ's
>>>> code analysis to find some candidates for such small fixes. Based on
>>> that I
>>>> created a really small patch, just to walk down the path, before going
>>> to
>>>> the JUG. Here is a link to the webrev archive that I created:
>>> https://drive.google.com/file/d/0B0zkCj4qHzcrR1k3TC1Qd3B4RWM.
>>>> 
>>>> So, I have the following questions:
>>>> 
>>>> - Do you think that such type of change would be welcome? If not, would
>>> you
>>>> recommend what should we do before going to JBUG? If yes, we will go on
>>> in
>>>> our JUG and find some other such small issues and even add test cases
>>> for
>>>> them
>>>> - Would you recommend having one big patch for all the changes that we
>>>> find, or you think it is better to have one patch per issue
>>>> 
>>>> Special thanks to Mani for all the help that he's been giving our JUG in
>>>> the last few months!
>>>> 
>>>> Cheers,
>>>> Ivan
>>>> 
>>>> 
>>>> --
>>>> Rgds,Rory O'Donnell
>>>> Quality Engineering Manager
>>>> Oracle EMEA , Dublin, Ireland
>> 
>> 