You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Kevin Meyer <ke...@kmz.co.za> on 2017/09/22 07:13:26 UTC
Complaints against Lombok?
Hi,
We use and encourage the use of Lombok[1][2].
However, inspired by a conversation I had with one of our architects the
other day, I did a little research and found that people complain that
Lombok is hacky and fragile (uses private Java API) [3].
Is any of this really an issue? Are any of the concerns "real"?
I'm thinking about the poor take-up of Isis. I know the argument that "the
young hotshots" are only interested in the latest shiny catch-phrase
technology, but if we're actively using something that has been accused of
"bad practices" that's not going to help our case either...
Opinions? Impact?
Cheers,
Kevin
[1] https://isis.apache.org/guides/rgant/rgant.html
[2] https://isis.apache.org/guides/rgcms/rgcms.html
[3]
http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-you-guys-using-gwt-with-lombok
--
Kevin Meyer
Ljubljana, Slovenia
Re: Complaints against Lombok?
Posted by Kevin Meyer <ke...@kmz.co.za>.
Thank you everyone who responded.
In short: We all appreciate the way that Lombok helps reduce boilerplate
in our (user/domain) POJOs* and there is no concern about how Lombok
achieves this.
Cheers,
Kevin
* Alternatives such as Jackdaw and Immutables only save on keypresses,
they still end up *generating* code that puts getters/setters into the
resulting Java.
On Fri, September 22, 2017 11:30, Chi Cuong Le wrote:
> Hi all,
>
>
> from my point of view, choosing Lombok is not bad idea. It reduces a lot
> of code that developers do not want to write. yes, a specific Lombok
> version will only work with few JDKs. But it doesn't matter because we do
> not change our JDK every day. Every time when JDK upgrade, we have to
> adapt not only Lombok but also other third party libraries also.
>
> Viele Grüße/Best regards,
> Chi Cuong Le
>
>
> On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS <o....@govertis.com>
> wrote:
>
>
>>
>>
>> Hi all,
>>
>>
>> I started to love @Getter and @Setter for more thant 1 year ago, and
>> really happy with that ;)
>>
>> Clearer code, with less boilerplate, and more readable Domain Entities.
>>
>>
>> Basically it’s the same C# people is enjoying.
>>
>>
>> Properties have become a first-class citizen on most Java classes.
>> What is surprising is that Java does not directly implement it.
>>
>>
>> Regards,
>>
>>
>> Oscar
>>
>>
>>
>>
>> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham GI-DP
>> <
>> Joerg.Rade@Kuehne-Nagel.com> escribió:
>>
>>
>> Hi,
>>
>>
>> from the user (developer) perspective I love Lombok's @Getter @Setter
>> for making source much more compact and saving me brain dead key
>> presses. Thereby increasing readability and maintainability of code.
>>
>>
>> AFAIK Lombok intercepts somewhere before compile time and IntelliJ even
>> offers menu options for switching back and forth.
>>
>> Since Java 9 can now enforce visibility on a different level a lot of
>> tools will have to adopt (Apache Isis included [1]). AFAIK there will
>> even be a switch to turn this enforcement off ;-)
>>
>> If architects are really concerned with these kinds of issues, they
>> must live in an almost ideal world ;-)
>>
>> My 2c
>> -j
>>
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-1277
>> -----Ursprüngliche Nachricht-----
>> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
>> Gesendet: Freitag, 22. September 2017 09:40
>> An: dev@isis.apache.org
>> Betreff: Re: Complaints against Lombok?
>>
>>
>> Hi Dan,
>>
>>
>> I acknowledge that tech is probably not the biggest take-up challenge
>> we face.
>>
>> However I'd prefer an argument like "we don't use Lombok in Isis
>> sources, only examples, so any other boiler-plate-removal-choice is
>> entirely under use-control" :)
>>
>> As I understand it, it's precisely because of the hacky/private API
>> that the Lombok devs *have to* address breakages when a new JDK comes
>> out. And what about other JDKs? Or are we binding users to Oracle?
>>
>> @Everyone: Any other opinions?
>>
>>
>> @Dan: Did you consider other helpers? How did you choose Lombok?
>>
>>
>> To be clear, I really like the convenience that Lombok provides! I am
>> now just curious about a decision.
>>
>> Cheers,
>> Kevin
>>
>>
>>
>> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>>
>>
>> Hi Kevin,
>>
>>
>>
>> I'd be surprised if Lombok really counts against us ... in terms of
>> technology choices more likely is our use of JDO (I've just started on
>> the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
>> Remember also that Lombok is just a compile-time thing. I see from
>> [4] that the Lombok guys are working on getting Lombok work with the
>> Java 9 compiler, but even then remember that there's nothing to stop
>> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9 if
>> nec.
>>
>>
>> As we talked about at the mini-conf in Jun, though, [5] I don't think
>> our take up really has very much to do with technology at all. Anyway,
>> our community _does_ continue to grow, and if it grows slowly but
>> steadily, well I'm ok with that.
>>
>> Cheers
>> Dan
>>
>>
>>
>>
>> [4] https://github.com/rzwitserloot/lombok/issues/985
>> [5]
>> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>>
>>
>>
>>
>> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>>
>>
>> Hi,
>>
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the young hotshots" are only interested in the latest shiny
>> catch-phrase technology, but if we're actively using something that has
>> been accused of "bad practices" that's not going to help our case
>> either...
>>
>>
>> Opinions? Impact?
>>
>>
>>
>> Cheers,
>> Kevin
>>
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>> yo u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>>
>> Kühne + Nagel (AG & Co.) KG
>> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
>> 812773878.
>> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors.
>> ),
>> Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde,
>> Michael Nebel, Lars Wedel, Matthias Weiner.
>> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
>> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
>> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
>> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi
>> (Vors.),
>> Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik
>> Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa
>> Sener.
>>
>>
>> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
>> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in
>> Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§
>> 431
>> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten
>> unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf
>> 2
>> SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf
>> 1,25
>> Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je
>> Schadenereignis,
>> mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer
>> Webseite
>> als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne
>> zu.
>>
>>
>>
>> Óscar Bou Bou
>> Socio - IT & GRC Management Services Director
>> m: +34 620 267 520 <+34%20620%2026%2075%2020>
>> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>>
>>
>> LinkedIn: https://www.linkedin.com/in/oscarbou
>> Twitter: @oscarbou <https://twitter.com/oscarbou>
>>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección
>> electrónica; no deberá copiar el mensaje ni divulgar su contenido a
>> ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan
>> en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya
>> finalidad es la de mantener el contacto con Ud. Si quiere saber de qué
>> información disponemos de Ud., modificarla, y en su caso, cancelarla,
>> puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia
>> de su D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L.
>> Avda Cortes
>> Valencianas, 58 – 8º - 6ª. 46015 - Valencia
>> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C2%B
>> A+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
>> y Paseo de la Castellana, 153, 28045 - MADRID
>> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID
>> &entry=gmail&source=g>.
>> Asimismo, es su responsabilidad comprobar que este mensaje o sus
>> archivos adjuntos no contengan virus informáticos, y en caso que los
>> tuvieran eliminarlos.
>>
>>
>
--
Kevin Meyer
Ljubljana, Slovenia
Re: Kotlin archetye (WAS: AW: Complaints against Lombok?)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Jorg,
it's certainly possible to mix Kotlin and Java, pretty much seamlessly,
even on a file-by-file basis. For anyone not in the know, this is
JetBrains language and so it has had deep integration with the IntelliJ IDE
from the off.
I recommend the Talking Kotlin podcast [1] to learn some more about the
language and how it's being used.
Cheers
Dan
[1] http://talkingkotlin.com/
On Fri, 22 Sep 2017 at 12:19 Rade, Joerg / Kuehne + Nagel / Ham GI-DP <
Joerg.Rade@kuehne-nagel.com> wrote:
> Hi,
>
> changing (part of) a development environment is always effort.
>
> For me switching to IntelliJ already pays off and I'll give Kotlin a try
> too.
>
> I assume mixing languages would be possible as well?
>
> Best regards
> Jörg
> -----Ursprüngliche Nachricht-----
> Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Gesendet: Freitag, 22. September 2017 11:42
> An: dev@isis.apache.org
> Betreff: Re: Complaints against Lombok?
>
> Hi Kev,
>
> @Dan: Did you consider other helpers? How did you choose Lombok?
>
> (Probably like others), we were looking at how to make the Estatio
> codebase easier to understand/work with, and I remembered seeing some blog
> posts about it and decided to check it out. Since it integrates nicely
> with the IDEs and Maven, it seemed to fit our environment nicely.
>
> To switch topic a little (but not much)... what we all really want is a
> "better Java", in syntax if nothing else. (Those who know me will know
> what I'm about to say next ...) there's a good argument to advocating and
> ultimately switching to use Kotlin. I did manage to port the simpleapp to
> Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking of
> adding a new Kotlin archetype, perhaps initially as part of the Incode
> Platform rather than in Apache Isis proper.
>
> Thoughts?
>
> Cheers
> Dan
>
>
> On Fri, 22 Sep 2017 at 10:30 Chi Cuong Le <ch...@googlemail.com>
> wrote:
>
> > Hi all,
> >
> > from my point of view, choosing Lombok is not bad idea. It reduces a
> > lot of code that developers do not want to write.
> > yes, a specific Lombok version will only work with few JDKs. But it
> > doesn't matter because we do not change our JDK every day. Every time
> > when JDK upgrade, we have to adapt not only Lombok but also other
> > third party libraries also.
> >
> > Viele Grüße/Best regards,
> > Chi Cuong Le
> >
> > On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS
> > <o....@govertis.com>
> > wrote:
> >
> >>
> >>
> >> Hi all,
> >>
> >> I started to love @Getter and @Setter for more thant 1 year ago, and
> >> really happy with that ;)
> >>
> >> Clearer code, with less boilerplate, and more readable Domain Entities.
> >>
> >> Basically it’s the same C# people is enjoying.
> >>
> >> Properties have become a first-class citizen on most Java classes.
> >> What is surprising is that Java does not directly implement it.
> >>
> >> Regards,
> >>
> >> Oscar
> >>
> >>
> >>
> >> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham
> >> GI-DP < Joerg.Rade@Kuehne-Nagel.com> escribió:
> >>
> >> Hi,
> >>
> >> from the user (developer) perspective I love Lombok's @Getter @Setter
> >> for making source much more compact and saving me brain dead key
> presses.
> >> Thereby increasing readability and maintainability of code.
> >>
> >> AFAIK Lombok intercepts somewhere before compile time and IntelliJ
> >> even offers menu options for switching back and forth.
> >>
> >> Since Java 9 can now enforce visibility on a different level a lot of
> >> tools will have to adopt (Apache Isis included [1]).
> >> AFAIK there will even be a switch to turn this enforcement off ;-)
> >>
> >> If architects are really concerned with these kinds of issues, they
> >> must live in an almost ideal world ;-)
> >>
> >> My 2c
> >> -j
> >>
> >> [1] https://issues.apache.org/jira/browse/ISIS-1277
> >> -----Ursprüngliche Nachricht-----
> >> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
> >> Gesendet: Freitag, 22. September 2017 09:40
> >> An: dev@isis.apache.org
> >> Betreff: Re: Complaints against Lombok?
> >>
> >> Hi Dan,
> >>
> >> I acknowledge that tech is probably not the biggest take-up challenge
> >> we face.
> >>
> >> However I'd prefer an argument like "we don't use Lombok in Isis
> >> sources, only examples, so any other boiler-plate-removal-choice is
> >> entirely under use-control" :)
> >>
> >> As I understand it, it's precisely because of the hacky/private API
> >> that the Lombok devs *have to* address breakages when a new JDK comes
> >> out. And what about other JDKs? Or are we binding users to Oracle?
> >>
> >> @Everyone: Any other opinions?
> >>
> >> @Dan: Did you consider other helpers? How did you choose Lombok?
> >>
> >> To be clear, I really like the convenience that Lombok provides! I am
> >> now just curious about a decision.
> >>
> >> Cheers,
> >> Kevin
> >>
> >>
> >> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
> >>
> >> Hi Kevin,
> >>
> >>
> >> I'd be surprised if Lombok really counts against us ... in terms of
> >> technology choices more likely is our use of JDO (I've just started
> >> on the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
> >> Remember also that Lombok is just a compile-time thing. I see from
> >> [4] that the Lombok guys are working on getting Lombok work with the
> >> Java 9 compiler, but even then remember that there's nothing to stop
> >> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
> >> if nec.
> >>
> >>
> >> As we talked about at the mini-conf in Jun, though, [5] I don't think
> >> our take up really has very much to do with technology at all.
> >> Anyway, our community _does_ continue to grow, and if it grows slowly
> >> but steadily, well I'm ok with that.
> >>
> >> Cheers
> >> Dan
> >>
> >>
> >>
> >> [4] https://github.com/rzwitserloot/lombok/issues/985
> >> [5]
> >> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
> >>
> >>
> >>
> >> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
> >>
> >>
> >> Hi,
> >>
> >>
> >> We use and encourage the use of Lombok[1][2].
> >>
> >>
> >> However, inspired by a conversation I had with one of our architects
> >> the other day, I did a little research and found that people complain
> >> that Lombok is hacky and fragile (uses private Java API) [3].
> >>
> >>
> >> Is any of this really an issue? Are any of the concerns "real"?
> >>
> >>
> >> I'm thinking about the poor take-up of Isis. I know the argument that
> >> "the young hotshots" are only interested in the latest shiny
> >> catch-phrase technology, but if we're actively using something that
> >> has been accused of "bad practices" that's not going to help our case
> >> either...
> >>
> >>
> >> Opinions? Impact?
> >>
> >>
> >> Cheers,
> >> Kevin
> >>
> >>
> >> [1] https://isis.apache.org/guides/rgant/rgant.html
> >> [2] https://isis.apache.org/guides/rgcms/rgcms.html
> >> [3]
> >>
> >>
> >> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
> >> yo
> >> u-guys-using-gwt-with-lombok
> >>
> >> --
> >> Kevin Meyer
> >> Ljubljana, Slovenia
> >>
> >>
> >> --
> >> Kevin Meyer
> >> Ljubljana, Slovenia
> >>
> >>
> >>
> >> Kühne + Nagel (AG & Co.) KG
> >> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> >> 812773878.
> >> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi
> >> (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten,
> >> Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
> >> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> >> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> >> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> >> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi
> >> (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz,
> >> Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde,
> Mustafa Sener.
> >>
> >> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> >> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen
> >> in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden
> >> (§ 431
> >> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
> >> Transporten unter Einschluss einer Seebeförderung und bei unbekanntem
> >> Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33
> >> SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5
> >> Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg,
> >> beschränken. Die ADSp sind auf unserer Webseite als Download
> erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
> >>
> >>
> >>
> >> Óscar Bou Bou
> >> Socio - IT & GRC Management Services Director
> >> m: +34 620 267 520 <+34%20620%2026%2075%2020>
> <+34%20620%2026%2075%2020>
> >> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
> >>
> >> LinkedIn: https://www.linkedin.com/in/oscarbou
> >> Twitter: @oscarbou <https://twitter.com/oscarbou>
> >>
> >>
> >>
> >> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> >> contienen información reservada que no puede ser difundida. Si usted
> >> ha recibido este correo por error, tenga la amabilidad de eliminarlo
> >> de su sistema y avisar al remitente mediante reenvío a su dirección
> >> electrónica; no deberá copiar el mensaje ni divulgar su contenido a
> ninguna persona.
> >>
> >> Su dirección de correo electrónico junto a sus datos personales
> >> constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L.
> >> cuya finalidad es la de mantener el contacto con Ud. Si quiere saber
> >> de qué información disponemos de Ud., modificarla, y e
> <https://maps.google.com/?q=maci%C3%B3n+disponemos+de+Ud.,+modificarla,+y+e&entry=gmail&source=g>n
> su caso,
> >> cancelarla, puede hacerlo enviando un escrito al efecto, acompañado
> >> de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS
> >> ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015
> >> - Valencia
> >> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C
> >> 2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
> >> y Paseo de la Castellana, 153, 28045 - MADRID
> >> <
> https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g
> >.
> >> Asimismo, es su responsabilidad comprobar que este mensaje o sus
> >> archivos adjuntos no contengan virus informáticos, y en caso que los
> >> tuvieran eliminarlos.
> >>
> >>
> >
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ),
> Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde,
> Michael Nebel, Lars Wedel, Matthias Weiner.
> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.),
> Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik
> Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in
> Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431
> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten
> unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2
> SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25
> Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis,
> mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite
> als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>
Kotlin archetye (WAS: AW: Complaints against Lombok?)
Posted by "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <Jo...@Kuehne-Nagel.com>.
Hi,
changing (part of) a development environment is always effort.
For me switching to IntelliJ already pays off and I'll give Kotlin a try too.
I assume mixing languages would be possible as well?
Best regards
Jörg
-----Ursprüngliche Nachricht-----
Von: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Gesendet: Freitag, 22. September 2017 11:42
An: dev@isis.apache.org
Betreff: Re: Complaints against Lombok?
Hi Kev,
@Dan: Did you consider other helpers? How did you choose Lombok?
(Probably like others), we were looking at how to make the Estatio codebase easier to understand/work with, and I remembered seeing some blog posts about it and decided to check it out. Since it integrates nicely with the IDEs and Maven, it seemed to fit our environment nicely.
To switch topic a little (but not much)... what we all really want is a "better Java", in syntax if nothing else. (Those who know me will know what I'm about to say next ...) there's a good argument to advocating and ultimately switching to use Kotlin. I did manage to port the simpleapp to Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking of adding a new Kotlin archetype, perhaps initially as part of the Incode Platform rather than in Apache Isis proper.
Thoughts?
Cheers
Dan
On Fri, 22 Sep 2017 at 10:30 Chi Cuong Le <ch...@googlemail.com>
wrote:
> Hi all,
>
> from my point of view, choosing Lombok is not bad idea. It reduces a
> lot of code that developers do not want to write.
> yes, a specific Lombok version will only work with few JDKs. But it
> doesn't matter because we do not change our JDK every day. Every time
> when JDK upgrade, we have to adapt not only Lombok but also other
> third party libraries also.
>
> Viele Grüße/Best regards,
> Chi Cuong Le
>
> On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS
> <o....@govertis.com>
> wrote:
>
>>
>>
>> Hi all,
>>
>> I started to love @Getter and @Setter for more thant 1 year ago, and
>> really happy with that ;)
>>
>> Clearer code, with less boilerplate, and more readable Domain Entities.
>>
>> Basically it’s the same C# people is enjoying.
>>
>> Properties have become a first-class citizen on most Java classes.
>> What is surprising is that Java does not directly implement it.
>>
>> Regards,
>>
>> Oscar
>>
>>
>>
>> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham
>> GI-DP < Joerg.Rade@Kuehne-Nagel.com> escribió:
>>
>> Hi,
>>
>> from the user (developer) perspective I love Lombok's @Getter @Setter
>> for making source much more compact and saving me brain dead key presses.
>> Thereby increasing readability and maintainability of code.
>>
>> AFAIK Lombok intercepts somewhere before compile time and IntelliJ
>> even offers menu options for switching back and forth.
>>
>> Since Java 9 can now enforce visibility on a different level a lot of
>> tools will have to adopt (Apache Isis included [1]).
>> AFAIK there will even be a switch to turn this enforcement off ;-)
>>
>> If architects are really concerned with these kinds of issues, they
>> must live in an almost ideal world ;-)
>>
>> My 2c
>> -j
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-1277
>> -----Ursprüngliche Nachricht-----
>> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
>> Gesendet: Freitag, 22. September 2017 09:40
>> An: dev@isis.apache.org
>> Betreff: Re: Complaints against Lombok?
>>
>> Hi Dan,
>>
>> I acknowledge that tech is probably not the biggest take-up challenge
>> we face.
>>
>> However I'd prefer an argument like "we don't use Lombok in Isis
>> sources, only examples, so any other boiler-plate-removal-choice is
>> entirely under use-control" :)
>>
>> As I understand it, it's precisely because of the hacky/private API
>> that the Lombok devs *have to* address breakages when a new JDK comes
>> out. And what about other JDKs? Or are we binding users to Oracle?
>>
>> @Everyone: Any other opinions?
>>
>> @Dan: Did you consider other helpers? How did you choose Lombok?
>>
>> To be clear, I really like the convenience that Lombok provides! I am
>> now just curious about a decision.
>>
>> Cheers,
>> Kevin
>>
>>
>> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>>
>> Hi Kevin,
>>
>>
>> I'd be surprised if Lombok really counts against us ... in terms of
>> technology choices more likely is our use of JDO (I've just started
>> on the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
>> Remember also that Lombok is just a compile-time thing. I see from
>> [4] that the Lombok guys are working on getting Lombok work with the
>> Java 9 compiler, but even then remember that there's nothing to stop
>> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
>> if nec.
>>
>>
>> As we talked about at the mini-conf in Jun, though, [5] I don't think
>> our take up really has very much to do with technology at all.
>> Anyway, our community _does_ continue to grow, and if it grows slowly
>> but steadily, well I'm ok with that.
>>
>> Cheers
>> Dan
>>
>>
>>
>> [4] https://github.com/rzwitserloot/lombok/issues/985
>> [5]
>> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>>
>>
>>
>> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>>
>> Hi,
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the young hotshots" are only interested in the latest shiny
>> catch-phrase technology, but if we're actively using something that
>> has been accused of "bad practices" that's not going to help our case
>> either...
>>
>>
>> Opinions? Impact?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>> yo
>> u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>> Kühne + Nagel (AG & Co.) KG
>> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
>> 812773878.
>> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi
>> (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten,
>> Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
>> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
>> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
>> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
>> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi
>> (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz,
>> Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>>
>> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
>> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen
>> in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden
>> (§ 431
>> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen
>> Transporten unter Einschluss einer Seebeförderung und bei unbekanntem
>> Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33
>> SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5
>> Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg,
>> beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>>
>>
>>
>> Óscar Bou Bou
>> Socio - IT & GRC Management Services Director
>> m: +34 620 267 520 <+34%20620%2026%2075%2020>
>> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>>
>> LinkedIn: https://www.linkedin.com/in/oscarbou
>> Twitter: @oscarbou <https://twitter.com/oscarbou>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted
>> ha recibido este correo por error, tenga la amabilidad de eliminarlo
>> de su sistema y avisar al remitente mediante reenvío a su dirección
>> electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales
>> constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L.
>> cuya finalidad es la de mantener el contacto con Ud. Si quiere saber
>> de qué información disponemos de Ud., modificarla, y en su caso,
>> cancelarla, puede hacerlo enviando un escrito al efecto, acompañado
>> de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS
>> ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015
>> - Valencia
>> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C
>> 2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
>> y Paseo de la Castellana, 153, 28045 - MADRID
>> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>.
>> Asimismo, es su responsabilidad comprobar que este mensaje o sus
>> archivos adjuntos no contengan virus informáticos, y en caso que los
>> tuvieran eliminarlos.
>>
>>
>
Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
Re: Kotlin (was: Complaints against Lombok?)
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hi Dan,
In that case, I say "Go right ahead!" :)
I've seen some Kotlin in an Android project and it did seem to simplify
matters.
A new archetype for Kotlin would be interesting to see...
Cheers,
Kevin
On Sun, September 24, 2017 12:05, Dan Haywood wrote:
> Hi Kevin,
> I probably didn't phrase that thought well.
>
>
> I don't think that the core framework will ever be written in anything
> other than Java... to change that would be a big decision indeed.
>
> All I'm suggesting now is to provide a new archetype that would let folk
> write their apps in kotlin if they wanted.
>
> Hope that helps,
> Dan.
>
>
> On Sun, 24 Sep 2017, 10:36 Kevin Meyer <ke...@kmz.co.za> wrote:
>
>
>> Hi all,
>>
>>
>> Let me voice my concerns and you can tell me if they're valid or not.
>>
>>
>> I fully appreciate that "a better Java experience" is a goal that we
>> aim to satisfy.
>>
>> A major selling-point of Apache Isis is that it relieves the developer
>> of *a lot of* mundane stuff that they really don't need to worry about
>> (UI,
>> DB access, etc).
>>
>>
>> However, *I* don't want Apache Isis to be locked into anything other
>> than Java [a].
>>
>>
>> What does "switch to" Kotlin mean? Will it require any change to
>> existing user projects? Will all our users be happy to add Kotlin
>> support to their projects to continue using Isis?
>>
>> Of course, whoever wants to can develop and provide whatever resources
>> they want to users (and announce them on the users mailing list) - as
>> long as the licensing remains Apache and there is no commercial
>> advertising.
>>
>> But the *core* Apache Isis infrastructure should continue to be usable
>> by the wider Java community.
>>
>> Thoughts?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>>
>> [a] This is *my* desire. If the community says it wants to move, then
>> that's fine. We can take that discussion to the users list at the
>> appropriate time.
>>
>>
>> On Fri, September 22, 2017 11:42, Dan Haywood wrote:
>>
>>> Hi Kev,
>>>
>>>
>>> To switch topic a little (but not much)... what we all really want is
>>> a "better Java", in syntax if nothing else. (Those who know me will
>>> know what I'm about to say next ...) there's a good argument to
>>> advocating and ultimately switching to use Kotlin. I did manage to
>>> port the simpleapp to Kotlin a year or so ago, it worked fine. As a
>>> first pass, I'm
>> thinking
>>> of adding a new Kotlin archetype, perhaps initially as part of the
>>> Incode
>>> Platform rather than in Apache Isis proper.
>>>
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> Cheers
>>> Dan
>>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>>
>
--
Kevin Meyer
Ljubljana, Slovenia
Re: Kotlin (was: Complaints against Lombok?)
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Kevin,
I probably didn't phrase that thought well.
I don't think that the core framework will ever be written in anything
other than Java... to change that would be a big decision indeed.
All I'm suggesting now is to provide a new archetype that would let folk
write their apps in kotlin if they wanted.
Hope that helps,
Dan.
On Sun, 24 Sep 2017, 10:36 Kevin Meyer <ke...@kmz.co.za> wrote:
> Hi all,
>
> Let me voice my concerns and you can tell me if they're valid or not.
>
> I fully appreciate that "a better Java experience" is a goal that we aim
> to satisfy.
>
> A major selling-point of Apache Isis is that it relieves the developer of
> *a lot of* mundane stuff that they really don't need to worry about (UI,
> DB access, etc).
>
> However, *I* don't want Apache Isis to be locked into anything other than
> Java [a].
>
> What does "switch to" Kotlin mean? Will it require any change to existing
> user projects? Will all our users be happy to add Kotlin support to their
> projects to continue using Isis?
>
> Of course, whoever wants to can develop and provide whatever resources
> they want to users (and announce them on the users mailing list) - as long
> as the licensing remains Apache and there is no commercial advertising.
>
> But the *core* Apache Isis infrastructure should continue to be usable by
> the wider Java community.
>
> Thoughts?
>
> Cheers,
> Kevin
>
>
> [a] This is *my* desire. If the community says it wants to move, then
> that's fine. We can take that discussion to the users list at the
> appropriate time.
>
>
> On Fri, September 22, 2017 11:42, Dan Haywood wrote:
> > Hi Kev,
> >
> > To switch topic a little (but not much)... what we all really want is a
> > "better Java", in syntax if nothing else. (Those who know me will know
> > what I'm about to say next ...) there's a good argument to advocating and
> > ultimately switching to use Kotlin. I did manage to port the simpleapp
> > to Kotlin a year or so ago, it worked fine. As a first pass, I'm
> thinking
> > of adding a new Kotlin archetype, perhaps initially as part of the Incode
> > Platform rather than in Apache Isis proper.
> >
> >
> > Thoughts?
> >
> >
> > Cheers
> > Dan
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
>
Kotlin (was: Complaints against Lombok?)
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hi all,
Let me voice my concerns and you can tell me if they're valid or not.
I fully appreciate that "a better Java experience" is a goal that we aim
to satisfy.
A major selling-point of Apache Isis is that it relieves the developer of
*a lot of* mundane stuff that they really don't need to worry about (UI,
DB access, etc).
However, *I* don't want Apache Isis to be locked into anything other than
Java [a].
What does "switch to" Kotlin mean? Will it require any change to existing
user projects? Will all our users be happy to add Kotlin support to their
projects to continue using Isis?
Of course, whoever wants to can develop and provide whatever resources
they want to users (and announce them on the users mailing list) - as long
as the licensing remains Apache and there is no commercial advertising.
But the *core* Apache Isis infrastructure should continue to be usable by
the wider Java community.
Thoughts?
Cheers,
Kevin
[a] This is *my* desire. If the community says it wants to move, then
that's fine. We can take that discussion to the users list at the
appropriate time.
On Fri, September 22, 2017 11:42, Dan Haywood wrote:
> Hi Kev,
>
> To switch topic a little (but not much)... what we all really want is a
> "better Java", in syntax if nothing else. (Those who know me will know
> what I'm about to say next ...) there's a good argument to advocating and
> ultimately switching to use Kotlin. I did manage to port the simpleapp
> to Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking
> of adding a new Kotlin archetype, perhaps initially as part of the Incode
> Platform rather than in Apache Isis proper.
>
>
> Thoughts?
>
>
> Cheers
> Dan
--
Kevin Meyer
Ljubljana, Slovenia
Re: Complaints against Lombok?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Kev,
@Dan: Did you consider other helpers? How did you choose Lombok?
(Probably like others), we were looking at how to make the Estatio codebase
easier to understand/work with, and I remembered seeing some blog posts
about it and decided to check it out. Since it integrates nicely with the
IDEs and Maven, it seemed to fit our environment nicely.
To switch topic a little (but not much)... what we all really want is a
"better Java", in syntax if nothing else. (Those who know me will know
what I'm about to say next ...) there's a good argument to advocating and
ultimately switching to use Kotlin. I did manage to port the simpleapp to
Kotlin a year or so ago, it worked fine. As a first pass, I'm thinking of
adding a new Kotlin archetype, perhaps initially as part of the Incode
Platform rather than in Apache Isis proper.
Thoughts?
Cheers
Dan
On Fri, 22 Sep 2017 at 10:30 Chi Cuong Le <ch...@googlemail.com>
wrote:
> Hi all,
>
> from my point of view, choosing Lombok is not bad idea. It reduces a lot
> of code that developers do not want to write.
> yes, a specific Lombok version will only work with few JDKs. But it
> doesn't matter because we do not change our JDK every day. Every time when
> JDK upgrade, we have to adapt not only Lombok but also other third party
> libraries also.
>
> Viele Grüße/Best regards,
> Chi Cuong Le
>
> On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS <o....@govertis.com>
> wrote:
>
>>
>>
>> Hi all,
>>
>> I started to love @Getter and @Setter for more thant 1 year ago, and
>> really happy with that ;)
>>
>> Clearer code, with less boilerplate, and more readable Domain Entities.
>>
>> Basically it’s the same C# people is enjoying.
>>
>> Properties have become a first-class citizen on most Java classes.
>> What is surprising is that Java does not directly implement it.
>>
>> Regards,
>>
>> Oscar
>>
>>
>>
>> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham GI-DP <
>> Joerg.Rade@Kuehne-Nagel.com> escribió:
>>
>> Hi,
>>
>> from the user (developer) perspective I love Lombok's @Getter @Setter for
>> making source much more compact and saving me brain dead key presses.
>> Thereby increasing readability and maintainability of code.
>>
>> AFAIK Lombok intercepts somewhere before compile time and IntelliJ even
>> offers menu options for switching back and forth.
>>
>> Since Java 9 can now enforce visibility on a different level a lot of
>> tools will have to adopt (Apache Isis included [1]).
>> AFAIK there will even be a switch to turn this enforcement off ;-)
>>
>> If architects are really concerned with these kinds of issues, they must
>> live in an almost ideal world ;-)
>>
>> My 2c
>> -j
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-1277
>> -----Ursprüngliche Nachricht-----
>> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
>> Gesendet: Freitag, 22. September 2017 09:40
>> An: dev@isis.apache.org
>> Betreff: Re: Complaints against Lombok?
>>
>> Hi Dan,
>>
>> I acknowledge that tech is probably not the biggest take-up challenge we
>> face.
>>
>> However I'd prefer an argument like "we don't use Lombok in Isis sources,
>> only examples, so any other boiler-plate-removal-choice is entirely under
>> use-control" :)
>>
>> As I understand it, it's precisely because of the hacky/private API that
>> the Lombok devs *have to* address breakages when a new JDK comes out. And
>> what about other JDKs? Or are we binding users to Oracle?
>>
>> @Everyone: Any other opinions?
>>
>> @Dan: Did you consider other helpers? How did you choose Lombok?
>>
>> To be clear, I really like the convenience that Lombok provides! I am now
>> just curious about a decision.
>>
>> Cheers,
>> Kevin
>>
>>
>> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>>
>> Hi Kevin,
>>
>>
>> I'd be surprised if Lombok really counts against us ... in terms of
>> technology choices more likely is our use of JDO (I've just started on
>> the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
>> Remember also that Lombok is just a compile-time thing. I see from
>> [4] that the Lombok guys are working on getting Lombok work with the
>> Java 9 compiler, but even then remember that there's nothing to stop
>> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
>> if nec.
>>
>>
>> As we talked about at the mini-conf in Jun, though, [5] I don't think
>> our take up really has very much to do with technology at all.
>> Anyway, our community _does_ continue to grow, and if it grows slowly
>> but steadily, well I'm ok with that.
>>
>> Cheers
>> Dan
>>
>>
>>
>> [4] https://github.com/rzwitserloot/lombok/issues/985
>> [5]
>> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>>
>>
>>
>> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>>
>> Hi,
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the young hotshots" are only interested in the latest shiny
>> catch-phrase technology, but if we're actively using something that
>> has been accused of "bad practices" that's not going to help our case
>> either...
>>
>>
>> Opinions? Impact?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>> yo
>> u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
>>
>>
>>
>> Kühne + Nagel (AG & Co.) KG
>> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
>> 812773878.
>> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ),
>> Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde,
>> Michael Nebel, Lars Wedel, Matthias Weiner.
>> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
>> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
>> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
>> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi
>> (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik
>> Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>>
>> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
>> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in
>> Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431
>> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten
>> unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2
>> SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25
>> Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis,
>> mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite
>> als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>>
>>
>>
>> Óscar Bou Bou
>> Socio - IT & GRC Management Services Director
>> m: +34 620 267 520 <+34%20620%2026%2075%2020>
>> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>>
>> LinkedIn: https://www.linkedin.com/in/oscarbou
>> Twitter: @oscarbou <https://twitter.com/oscarbou>
>>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>>
>> Su dirección de correo electrónico junto a sus datos personales constan
>> en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya
>> finalidad es la de mantener el contacto con Ud. Si quiere saber de qué
>> información disponemos de Ud., modificarla, y en su caso, cancelarla, puede
>> hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su
>> D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda
>> Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia
>> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
>> y Paseo de la Castellana, 153, 28045 - MADRID
>> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>.
>> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
>> adjuntos no contengan virus informáticos, y en caso que los tuvieran
>> eliminarlos.
>>
>>
>
Re: Complaints against Lombok?
Posted by Chi Cuong Le <ch...@googlemail.com>.
Hi all,
from my point of view, choosing Lombok is not bad idea. It reduces a lot of
code that developers do not want to write.
yes, a specific Lombok version will only work with few JDKs. But it doesn't
matter because we do not change our JDK every day. Every time when JDK
upgrade, we have to adapt not only Lombok but also other third party
libraries also.
Viele Grüße/Best regards,
Chi Cuong Le
On 22 September 2017 at 10:22, Óscar Bou - GOVERTIS <o....@govertis.com>
wrote:
>
>
> Hi all,
>
> I started to love @Getter and @Setter for more thant 1 year ago, and
> really happy with that ;)
>
> Clearer code, with less boilerplate, and more readable Domain Entities.
>
> Basically it’s the same C# people is enjoying.
>
> Properties have become a first-class citizen on most Java classes.
> What is surprising is that Java does not directly implement it.
>
> Regards,
>
> Oscar
>
>
>
> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham GI-DP <
> Joerg.Rade@Kuehne-Nagel.com> escribió:
>
> Hi,
>
> from the user (developer) perspective I love Lombok's @Getter @Setter for
> making source much more compact and saving me brain dead key presses.
> Thereby increasing readability and maintainability of code.
>
> AFAIK Lombok intercepts somewhere before compile time and IntelliJ even
> offers menu options for switching back and forth.
>
> Since Java 9 can now enforce visibility on a different level a lot of
> tools will have to adopt (Apache Isis included [1]).
> AFAIK there will even be a switch to turn this enforcement off ;-)
>
> If architects are really concerned with these kinds of issues, they must
> live in an almost ideal world ;-)
>
> My 2c
> -j
>
> [1] https://issues.apache.org/jira/browse/ISIS-1277
> -----Ursprüngliche Nachricht-----
> Von: Kevin Meyer [mailto:kevin@kmz.co.za <ke...@kmz.co.za>]
> Gesendet: Freitag, 22. September 2017 09:40
> An: dev@isis.apache.org
> Betreff: Re: Complaints against Lombok?
>
> Hi Dan,
>
> I acknowledge that tech is probably not the biggest take-up challenge we
> face.
>
> However I'd prefer an argument like "we don't use Lombok in Isis sources,
> only examples, so any other boiler-plate-removal-choice is entirely under
> use-control" :)
>
> As I understand it, it's precisely because of the hacky/private API that
> the Lombok devs *have to* address breakages when a new JDK comes out. And
> what about other JDKs? Or are we binding users to Oracle?
>
> @Everyone: Any other opinions?
>
> @Dan: Did you consider other helpers? How did you choose Lombok?
>
> To be clear, I really like the convenience that Lombok provides! I am now
> just curious about a decision.
>
> Cheers,
> Kevin
>
>
> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>
> Hi Kevin,
>
>
> I'd be surprised if Lombok really counts against us ... in terms of
> technology choices more likely is our use of JDO (I've just started on
> the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
> Remember also that Lombok is just a compile-time thing. I see from
> [4] that the Lombok guys are working on getting Lombok work with the
> Java 9 compiler, but even then remember that there's nothing to stop
> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
> if nec.
>
>
> As we talked about at the mini-conf in Jun, though, [5] I don't think
> our take up really has very much to do with technology at all.
> Anyway, our community _does_ continue to grow, and if it grows slowly
> but steadily, well I'm ok with that.
>
> Cheers
> Dan
>
>
>
> [4] https://github.com/rzwitserloot/lombok/issues/985
> [5]
> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>
>
>
> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>
>
> Hi,
>
>
> We use and encourage the use of Lombok[1][2].
>
>
> However, inspired by a conversation I had with one of our architects
> the other day, I did a little research and found that people complain
> that Lombok is hacky and fragile (uses private Java API) [3].
>
>
> Is any of this really an issue? Are any of the concerns "real"?
>
>
> I'm thinking about the poor take-up of Isis. I know the argument that
> "the young hotshots" are only interested in the latest shiny
> catch-phrase technology, but if we're actively using something that
> has been accused of "bad practices" that's not going to help our case
> either...
>
>
> Opinions? Impact?
>
>
> Cheers,
> Kevin
>
>
> [1] https://isis.apache.org/guides/rgant/rgant.html
> [2] https://isis.apache.org/guides/rgcms/rgcms.html
> [3]
>
>
> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
> yo
> u-guys-using-gwt-with-lombok
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE
> 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ),
> Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde,
> Michael Nebel, Lars Wedel, Matthias Weiner.
> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform:
> Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745,
> Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.),
> Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik
> Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen
> Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in
> Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431
> HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten
> unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2
> SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25
> Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis,
> mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite
> als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
>
>
>
> Óscar Bou Bou
> Socio - IT & GRC Management Services Director
> m: +34 620 267 520 <+34%20620%2026%2075%2020>
> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>
> LinkedIn: https://www.linkedin.com/in/oscarbou
> Twitter: @oscarbou <https://twitter.com/oscarbou>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad
> es la de mantener el contacto con Ud. Si quiere saber de qué información
> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a
> la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes
> Valencianas, 58 – 8º - 6ª. 46015 - Valencia
> <https://maps.google.com/?q=Avda+Cortes+Valencianas,+58+%E2%80%93+8%C2%BA+-+6%C2%AA.+46015+-+Valencia&entry=gmail&source=g>,
> y Paseo de la Castellana, 153, 28045 - MADRID
> <https://maps.google.com/?q=Paseo+de+la+Castellana,+153,+28045+-+MADRID&entry=gmail&source=g>.
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
Re: Complaints against Lombok?
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi all,
I started to love @Getter and @Setter for more thant 1 year ago, and really happy with that ;)
Clearer code, with less boilerplate, and more readable Domain Entities.
Basically it’s the same C# people is enjoying.
Properties have become a first-class citizen on most Java classes.
What is surprising is that Java does not directly implement it.
Regards,
Oscar
> El 22 sept 2017, a las 10:11, Rade, Joerg / Kuehne + Nagel / Ham GI-DP <Jo...@Kuehne-Nagel.com> escribió:
>
> Hi,
>
> from the user (developer) perspective I love Lombok's @Getter @Setter for making source much more compact and saving me brain dead key presses.
> Thereby increasing readability and maintainability of code.
>
> AFAIK Lombok intercepts somewhere before compile time and IntelliJ even offers menu options for switching back and forth.
>
> Since Java 9 can now enforce visibility on a different level a lot of tools will have to adopt (Apache Isis included [1]).
> AFAIK there will even be a switch to turn this enforcement off ;-)
>
> If architects are really concerned with these kinds of issues, they must live in an almost ideal world ;-)
>
> My 2c
> -j
>
> [1] https://issues.apache.org/jira/browse/ISIS-1277
> -----Ursprüngliche Nachricht-----
> Von: Kevin Meyer [mailto:kevin@kmz.co.za]
> Gesendet: Freitag, 22. September 2017 09:40
> An: dev@isis.apache.org
> Betreff: Re: Complaints against Lombok?
>
> Hi Dan,
>
> I acknowledge that tech is probably not the biggest take-up challenge we face.
>
> However I'd prefer an argument like "we don't use Lombok in Isis sources, only examples, so any other boiler-plate-removal-choice is entirely under use-control" :)
>
> As I understand it, it's precisely because of the hacky/private API that the Lombok devs *have to* address breakages when a new JDK comes out. And what about other JDKs? Or are we binding users to Oracle?
>
> @Everyone: Any other opinions?
>
> @Dan: Did you consider other helpers? How did you choose Lombok?
>
> To be clear, I really like the convenience that Lombok provides! I am now just curious about a decision.
>
> Cheers,
> Kevin
>
>
> On Fri, September 22, 2017 09:28, Dan Haywood wrote:
>> Hi Kevin,
>>
>>
>> I'd be surprised if Lombok really counts against us ... in terms of
>> technology choices more likely is our use of JDO (I've just started on
>> the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
>> Remember also that Lombok is just a compile-time thing. I see from
>> [4] that the Lombok guys are working on getting Lombok work with the
>> Java 9 compiler, but even then remember that there's nothing to stop
>> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
>> if nec.
>>
>>
>> As we talked about at the mini-conf in Jun, though, [5] I don't think
>> our take up really has very much to do with technology at all.
>> Anyway, our community _does_ continue to grow, and if it grows slowly
>> but steadily, well I'm ok with that.
>>
>> Cheers
>> Dan
>>
>>
>>
>> [4] https://github.com/rzwitserloot/lombok/issues/985
>> [5]
>> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>>
>>
>>
>> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>>
>>
>>> Hi,
>>>
>>>
>>> We use and encourage the use of Lombok[1][2].
>>>
>>>
>>> However, inspired by a conversation I had with one of our architects
>>> the other day, I did a little research and found that people complain
>>> that Lombok is hacky and fragile (uses private Java API) [3].
>>>
>>>
>>> Is any of this really an issue? Are any of the concerns "real"?
>>>
>>>
>>> I'm thinking about the poor take-up of Isis. I know the argument that
>>> "the young hotshots" are only interested in the latest shiny
>>> catch-phrase technology, but if we're actively using something that
>>> has been accused of "bad practices" that's not going to help our case
>>> either...
>>>
>>>
>>> Opinions? Impact?
>>>
>>>
>>> Cheers,
>>> Kevin
>>>
>>>
>>> [1] https://isis.apache.org/guides/rgant/rgant.html
>>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>>> [3]
>>>
>>>
>>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>>> yo
>>> u-guys-using-gwt-with-lombok
>>>
>>> --
>>> Kevin Meyer
>>> Ljubljana, Slovenia
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
>
> Kühne + Nagel (AG & Co.) KG
> Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
> Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
> Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
> Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
>
> Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de GOVERTIS ADVISORY SERVICES, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
AW: Complaints against Lombok?
Posted by "Rade, Joerg / Kuehne + Nagel / Ham GI-DP" <Jo...@Kuehne-Nagel.com>.
Hi,
from the user (developer) perspective I love Lombok's @Getter @Setter for making source much more compact and saving me brain dead key presses.
Thereby increasing readability and maintainability of code.
AFAIK Lombok intercepts somewhere before compile time and IntelliJ even offers menu options for switching back and forth.
Since Java 9 can now enforce visibility on a different level a lot of tools will have to adopt (Apache Isis included [1]).
AFAIK there will even be a switch to turn this enforcement off ;-)
If architects are really concerned with these kinds of issues, they must live in an almost ideal world ;-)
My 2c
-j
[1] https://issues.apache.org/jira/browse/ISIS-1277
-----Ursprüngliche Nachricht-----
Von: Kevin Meyer [mailto:kevin@kmz.co.za]
Gesendet: Freitag, 22. September 2017 09:40
An: dev@isis.apache.org
Betreff: Re: Complaints against Lombok?
Hi Dan,
I acknowledge that tech is probably not the biggest take-up challenge we face.
However I'd prefer an argument like "we don't use Lombok in Isis sources, only examples, so any other boiler-plate-removal-choice is entirely under use-control" :)
As I understand it, it's precisely because of the hacky/private API that the Lombok devs *have to* address breakages when a new JDK comes out. And what about other JDKs? Or are we binding users to Oracle?
@Everyone: Any other opinions?
@Dan: Did you consider other helpers? How did you choose Lombok?
To be clear, I really like the convenience that Lombok provides! I am now just curious about a decision.
Cheers,
Kevin
On Fri, September 22, 2017 09:28, Dan Haywood wrote:
> Hi Kevin,
>
>
> I'd be surprised if Lombok really counts against us ... in terms of
> technology choices more likely is our use of JDO (I've just started on
> the DN 5.1 upgrade, so plan to support JPA by Xmas, at latest).
> Remember also that Lombok is just a compile-time thing. I see from
> [4] that the Lombok guys are working on getting Lombok work with the
> Java 9 compiler, but even then remember that there's nothing to stop
> an Apache Isis app compiled with JDK8 + Lombok from running on Java 9
> if nec.
>
>
> As we talked about at the mini-conf in Jun, though, [5] I don't think
> our take up really has very much to do with technology at all.
> Anyway, our community _does_ continue to grow, and if it grows slowly
> but steadily, well I'm ok with that.
>
> Cheers
> Dan
>
>
>
> [4] https://github.com/rzwitserloot/lombok/issues/985
> [5]
> https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>
>
>
> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>
>
>> Hi,
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the young hotshots" are only interested in the latest shiny
>> catch-phrase technology, but if we're actively using something that
>> has been accused of "bad practices" that's not going to help our case
>> either...
>>
>>
>> Opinions? Impact?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-
>> yo
>> u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
--
Kevin Meyer
Ljubljana, Slovenia
Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, Michael Nebel, Lars Wedel, Matthias Weiner.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener.
Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu.
Re: Complaints against Lombok?
Posted by Kevin Meyer <ke...@kmz.co.za>.
Hi Dan,
I acknowledge that tech is probably not the biggest take-up challenge we
face.
However I'd prefer an argument like "we don't use Lombok in Isis sources,
only examples, so any other boiler-plate-removal-choice is entirely under
use-control" :)
As I understand it, it's precisely because of the hacky/private API that
the Lombok devs *have to* address breakages when a new JDK comes out. And
what about other JDKs? Or are we binding users to Oracle?
@Everyone: Any other opinions?
@Dan: Did you consider other helpers? How did you choose Lombok?
To be clear, I really like the convenience that Lombok provides! I am now
just curious about a decision.
Cheers,
Kevin
On Fri, September 22, 2017 09:28, Dan Haywood wrote:
> Hi Kevin,
>
>
> I'd be surprised if Lombok really counts against us ... in terms of
> technology choices more likely is our use of JDO (I've just started on the
> DN 5.1 upgrade, so plan to support JPA by Xmas, at latest). Remember
> also that Lombok is just a compile-time thing. I see from [4] that the
> Lombok
> guys are working on getting Lombok work with the Java 9 compiler, but even
> then remember that there's nothing to stop an Apache Isis app compiled
> with JDK8 + Lombok from running on Java 9 if nec.
>
>
> As we talked about at the mini-conf in Jun, though, [5] I don't think our
> take up really has very much to do with technology at all. Anyway, our
> community _does_ continue to grow, and if it grows slowly but steadily,
> well I'm ok with that.
>
> Cheers
> Dan
>
>
>
> [4] https://github.com/rzwitserloot/lombok/issues/985
> [5] https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
>
>
>
> On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
>
>
>> Hi,
>>
>>
>> We use and encourage the use of Lombok[1][2].
>>
>>
>> However, inspired by a conversation I had with one of our architects
>> the other day, I did a little research and found that people complain
>> that Lombok is hacky and fragile (uses private Java API) [3].
>>
>>
>> Is any of this really an issue? Are any of the concerns "real"?
>>
>>
>> I'm thinking about the poor take-up of Isis. I know the argument that
>> "the
>> young hotshots" are only interested in the latest shiny catch-phrase
>> technology, but if we're actively using something that has been accused
>> of "bad practices" that's not going to help our case either...
>>
>>
>> Opinions? Impact?
>>
>>
>> Cheers,
>> Kevin
>>
>>
>> [1] https://isis.apache.org/guides/rgant/rgant.html
>> [2] https://isis.apache.org/guides/rgcms/rgcms.html
>> [3]
>>
>>
>> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-yo
>> u-guys-using-gwt-with-lombok
>>
>> --
>> Kevin Meyer
>> Ljubljana, Slovenia
--
Kevin Meyer
Ljubljana, Slovenia
Re: Complaints against Lombok?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Kevin,
I'd be surprised if Lombok really counts against us ... in terms of
technology choices more likely is our use of JDO (I've just started on the
DN 5.1 upgrade, so plan to support JPA by Xmas, at latest). Remember also
that Lombok is just a compile-time thing. I see from [4] that the Lombok
guys are working on getting Lombok work with the Java 9 compiler, but even
then remember that there's nothing to stop an Apache Isis app compiled with
JDK8 + Lombok from running on Java 9 if nec.
As we talked about at the mini-conf in Jun, though, [5] I don't think our
take up really has very much to do with technology at all. Anyway, our
community _does_ continue to grow, and if it grows slowly but steadily,
well I'm ok with that.
Cheers
Dan
[4] https://github.com/rzwitserloot/lombok/issues/985
[5] https://cwiki.apache.org/confluence/display/ISIS/IsisCon2017+write-up
On Fri, 22 Sep 2017 at 08:13 Kevin Meyer <ke...@kmz.co.za> wrote:
> Hi,
>
> We use and encourage the use of Lombok[1][2].
>
> However, inspired by a conversation I had with one of our architects the
> other day, I did a little research and found that people complain that
> Lombok is hacky and fragile (uses private Java API) [3].
>
> Is any of this really an issue? Are any of the concerns "real"?
>
> I'm thinking about the poor take-up of Isis. I know the argument that "the
> young hotshots" are only interested in the latest shiny catch-phrase
> technology, but if we're actively using something that has been accused of
> "bad practices" that's not going to help our case either...
>
> Opinions? Impact?
>
> Cheers,
> Kevin
>
> [1] https://isis.apache.org/guides/rgant/rgant.html
> [2] https://isis.apache.org/guides/rgcms/rgcms.html
> [3]
>
> http://grokbase.com/t/gg/google-web-toolkit/163g51xbsg/is-anybody-of-you-guys-using-gwt-with-lombok
>
> --
> Kevin Meyer
> Ljubljana, Slovenia
>
>
>