28 Feb 07 6 coisas que eu não gosto no Java SE/EE
Bom, acho que a maioria dos que ja leram este blog alguma vez sabem que eu adoro Java, gosto muito de programar em Java pois tenho bastante flexibilidade, e com a mesma linguagem é possível escrever aplicações para celulares, PCs, PDAs, Main Frames e para o smart card que tem dentro de cada um dos celulares GSM do mundo inteiro …
Mas des de que eu comecei com java, algumas coisas me incomodam na plataforma em si e algumas pequenas coisas até na linguagem.
Então resolvi escrever esta pequena lista para ver se aluguem discorda de algum destes pontos, ou aponta alguma solução …
Antes de começar com a lista, só quero lembrar (acho que eu mesmo, pra não exagerar na lista 
) que mesmo com estas deficiências/pontos com os quais eu não concordo. A plataforma Java ainda assim é uma ótima solução para diversos tipos de problemas, e para algumas situações acredito que a unica solução
Vamos la então …
- Qualquer coisa em Java precisa ser configurada.
Eu sei que isto é por causa da flexibilidade do Java, mas acho muito chato precisar configurar alguma coisa, eu acho que deveria ser possível configurar, mas não obrigatório.
Isto teria de ter sido pensado assim des de os primórdios da linguagem, eu acho, mas até para executar um jar tu é obrigado a dizer qual a classe principal da aplicação, não era mais fácil deixar esta possibilidade mas ter deixado um padrão? - Para se ser produtivo desenvolvendo uma aplicação web simples em java, é necessário conhecer pelo menos uns 3 frameworks diferentes, uma meia dúzia de design patterns, e ser bastante disciplinado para não mandar tudo pra PQP e colocar todo o código dentro de 2 ou 3 JSPs.
Sim, eu sei que as aplicações ficam mais bonitas assim, mas convenhamos que a API de Servlets e JSPs sózinha não é nada produtiva, e praticamente te induz a fazer um sistema porco, custava fazer algo flexivel, mas fácil de usar?
Por causa disto temos diversos frameworks MVC, mas mesmo a API de Servlets sendo tão flexivel, ela não é flexivel o suficiente para um framework MVC se configurar sózinho, o que obriga o coitado do programador que esta começando no mundo Java EE a alem de ter de aprender o que ele realmente vai usar, ainda ter de aprender a configurar um web.xml da vida … - Excesso de compatibilidade retroativa
Um monte de classes na biblioteca padrão do Java SE tem métodos deprecated des do Java 1.1, isto ja deveria ter sido removido da plataforma a muito tempo, e isto é um tipo de compatibilidade burra, já que só infla a biblioteca padrão, e eles já quebraram a compatibilidade com um monte de código antigo por simplesmente adicionar a palavra chave “enum” mesmo, pior do que enum só se a partir de amanha “i” fosse uma palavra reservada, ai quebraria mais da metade das aplicações já escritas até hoje, ou vocês querem me convencer que nunca criaram uma variável com nome “i” para controlar um loop? ou uma de nome “enum” para armazenar um javalutil.Enumeration? - Inexistência de métodos de classe
Não, métodos estáticos não são métodos de classe, são apenas uma herança de programação procedural. Por que eu afirmo isto? simples, tu não pode sobre escrever um método estático, ele não sabe nem a que classe ele pertence …
Um exemplo de método de classe que eu lembro agora é no Object Pascal (Isto mesmo, Delphi), quando se declara um “class method” no ObjectPascal, a palavra reservada “self” que normalmente aponta para a instancia atual do objeto (semelhante ao “this” do java), passa a apontar para a classe (algo como this = this.getClass()), e a partir disto, um class method no pascal sabe a partir de qual classe ele foi invocado.
Um exemplo de utilização disto é um class factory para a hierarquia inteira … - Java Server Pages
Precisa realmente explicar? na minha opinião as JSPs são a pior coisa que ja saiu do JCP …
Alem disto são as responsáveis, junto com os programadores, e gerentes mão de vaca é claro, pela impossibilidade de se dar manutenção em diversos “sistemas” que já tive o disprazer de precisar corrigir bugs … - “Programação em XML”
Isto não é exatamente um problema da plataforma java, mas sim uma conseqüência da necessidade de configurar tudo, o que fez com que muitas pessoas “criativas” fizessem com que a configuração de alguns frameworks fossem simplesmente linguagens de programação em XML (um exemplo disto é o BPEL)
Bom, acho que vou ficar por aqui por enquanto …
Se eu lembrar de mais coisas, adiciono aqui na lista, e como temos feito ultimamente, se alguem quiser contribuir com a lista, é só deixar um comentário que eu vou atualizando o post …
Se você gostou deste post, lembre-se de assinar o RSS feed do blog, para ser notificado de novos posts!
Tags: Java
Reader's Comments
Leave a Comment
Licença
Blog do Urubatan by Rodrigo Urubatan Ferreira Jardim is licensed under a Creative Commons Attribution-Share Alike 2.5 Brazil License.
Permissions beyond the scope of this license may be available at http://www.urubatan.com.br/contato/.
“Para se ser produtivo desenvolvendo uma aplicação web simples em java, é necessário conhecer pelo menos uns 3 frameworks diferentes, uma meia dúzia de design patterns, e ser bastante disciplinado para não mandar tudo pra PQP e colocar todo o código dentro de 2 ou 3 JSPs.”
Reply to this commentFalou pouco mas falou bonito !!!
Essas desvantagens que você citou não tem muita coisa a ver com o Java em si, mas sim em como o Java “mantido” (se bem que o negócio de setar a classe Main em um jar é f** mesmo).
Reply to this commenta unica que na minha opinião é “como o java é mantido”, é o excesso de metodos deprecated …
agora o resto são caracteristicas da linguagem ou plataforma …
pelo menos é assim que eu vejo …
Alem disto, tem outras coisas muito chatas também, como o tratamento de excessões em java, que é muito mal feito na minha opinião, por exemplo, por padrão, as excessões não tem um código, o que facilitaria muito o tratamento delas, e dificultaria o mau uso que é feito da classe “Exception” por exemplo …
Excessões checadas são usadas em excesso, o que deixa o código mais feio …
lógico que isto é a minha opinião, ninguém é obrigado a concordar, e agradeço todos os comentários de quem concorda, e principalmente dos que não concordam
Reply to this commentO uso de Design Patterns não é obrigatório, para que se tenha um bom projeto. Aliás, acredito que a GoF(Gang of Four) já previam que a indústria de software vislumbraria os Designs Patterns como uma maneira de realizar propaganda do produto. Isso está implícito no livro deles, quando eles mencionam o que os Designs patterns não são, quando utilizá-lo, etc.
Reply to this commentAlessandro, em nenhum momento eu tentei dizer que java é um lixo, inclusive uso java a bastante tempo, e gosto bastante …
Agora, o uso de Design Patterns é obrigatorio sim em Java, ou tu consegue fazer uma aplicação web decente em java sem usar MVC? ou em SWING?
concordo que eu poderia ir la e criar uma JSR, mas falando sério, qual a probabilidade de eles removerem aquele monte de lixo deprecated?
quanto ao jar, não precisaria procurar classes com um método main, é só assumir que vai existir uma classe com o mesmo nome do jar, um nome padrão ou algo parecido …
e eu não reclamei de poder configurar o MANIFEST.MF, e sim de “ser obrigado a configurar” o MANIFEST.MF
mas ja estou pensando em alguma forma de solucionar pelo menos algumas das coisas que listei …
algumas delas outros ja solucionaram, mas não esta no core do java, e nem vai estar …
e como eu falei antes, o fato de eu não gostar destes pontos não quer dizer que a linguagem ou a plataforma sejam ruins …
Reply to this commenta coisa que mais me deixa louco em Java é que se você desenvolve uma aplicação comercial, qualquer um pode pegar o seu .jar, utilizar um decompiler qualquer e roubar seus fontes… tudo bem que a ideia é codigo fonte aberto, mas e se eu não quiser disponibilizar os códigos como fica? Eu sei, muitas pessoas vão dizer que dá pra usar um obfuscador de código, mesmo assim, dificulta mas não impossibilita… isso é o fim.
Reply to this commentJerônimo, isto não é problema só do java, mas de qualquer linguagem pseudo interetada, como por exemplo qualquer linguagem compilada para .NET vai ter exatamente o mesmo problema
Reply to this commentse você precisa deste tipo de segurança, a sua unica opção é migrar para uma linguagem compilada para código de maquina …
Que injustiça com Java EE 5 hein ?
Reply to this commentpor que injustiça com Java EE 5? algum destes pontos mudou no Java EE 5? não cheguei a estudar tão a fundo, mas pelo que eu vi até agora nenhum dos itens que eu falei foram solucionados (se bem que a unica coisa obrigatoriamente Java EE que foi listada são os JSPs
)
Reply to this commentVocê mencionou que as “JSPs são a pior coisa que ja saiu do JCP”, todavia não listou os motivos da afirmação. Poderia fazê-lo?
Reply to this commentBrunno, disse isto sobre as JSPs por diversos motivos, mas acho que estes são os mais importantes:
O motivo principal é o suporte a scriptlets que deveria ser sumariamente removido da especificação, mas estes outros também influenciam bastante na minha opinião …
Reply to this commentmas como eu disse, é a minha opinião …
Alguem mais concorda?
Se vc começasse a falar de JSF nunca ia parar hauahuahua
Reply to this commentRealmente java tem muita coisa podre, e é por isso que vai pras cucuia um dia.
um dia vai, mas acho que ainda vai demorar muito …
Java ainda tem muito chão pela frente …
e como eu disse antes, continuo achando que é uma ótima linguagem/plataforma …
e considerando a popularidade deste post, acho que amanha vou escrever um sobre o que eu gosto no Java
o que vocês acham?
Reply to this comment“Qualquer coisa em Java precisa ser configurada.”
Em Java EE 5 isso foi simplesmente pulverizado… existe agora 1 descritor XML para persistencia… o resto virou tudo opcional… configuracao pela excessão… a unica coisa que tem ainda que configurar eh o web.xml e tmb é discutivel… se vc usar um IDE como NetBeans , nem nele vc nao pega.
“Para se ser produtivo desenvolvendo uma aplicação web simples em java, é necessário conhecer pelo menos uns 3 frameworks diferentes, uma meia dúzia de design patterns, e ser bastante disciplinado para não mandar tudo pra PQP e colocar todo o código dentro de 2 ou 3 JSPs.”
Olha… se vc usar Java EE 5 nao vai usar 123123123 frameworks diferentes… vai usar JSF 1.2 e EJB 3 , com a especificação simplificada e uma IDE descente para te auxiliar em algumas coisas ditas morosas vc vai se dar bem… Agora quanto a diciplina… eh meio obvio neh ? ou vc preferiria algo “like PHP” ? Voce jah deu manutencao em um sistema PHP onde o cara teve “toda essa liberdade” ? eu já… e posso dizer… viva a “diciplina”.
“Excesso de compatibilidade retroativa”
Eu nao acho isso uma coisa tão ruim… tenho Java instalado em varios clientes meus… nao tenho condicoes de ficar atualizando as maquinas com a ultima versao de tudo… entao acompatibilidade garante para mim que meus clientes nao vao “parar” ao receber aquela “atualizacao automatica” da JVM… fora que existem dezenas de milhares de bibliotecas que dependem dessa compatibilidade… Eu tinha um problema parecido com esse em delphi… mudava a versao do delphi eu tinha que comprar todos componentes denovo… prq ? “falta de compativilidade retroativa”.
“Java Server Pages”
Alguem usa isso puro ainda ? JSP é um PHP só que com Java… tem suas utilidades… mas nao dah para ficar criticando algo que em projetos serios não é nem cogitado a utilizacao.
“Programação em XML??
Isso em Java EE 5 simplesmente não existe. Existe se voce quiser configurar algo fora das anotações… e repito… faces-config.xml e web.xml são mantidos pela IDE , dificilmente eu tomo ciencia deles… soh quando quero fazer algo mais mirabolante… até o mapeamento de Servlets é feito automatico pelo netBeans… mantem atualizado os vinculos e etc…
XML é uma coisa legal quando é opcional… estilo Java EE 5, acredito que voce só da valor a isso quando tem componentes de terceiros que precisao “conectar” ao seu sistema com politicas de funcionamento especificas…
Não é uma critica ao seu POST , apenas voce esta exagerando… acho que tem que olhar para as especificacoes atuais… não tomar como padrao por exemplo o JBoss…. existem alternativas a ele que tornam Java EE muito mais produtivo… por exemplo GlassFish , simplesmente 10.000 vezes mais organizado, rapido e facil de mecher…
Reply to this commentMeu Caro,
“# Java Server Pages
Precisa realmente explicar? na minha opinião as JSPs são a pior coisa que ja saiu do JCP ?”
Acho que você está muito equivocado, como tem coragem de dizer isso?
Pela forma que você atacou JSP, deu para perceber que você faz parte da fatia do mercado (A maior fatia) que pega as tecnologias e usa da forma ERRADA, senão não falaria tudo que falou…
Acho que você deveria estudar melhor o proposito de cada coisa que atacou.
Reply to this commentDeiverson, leia com mais atenção o que eu escrevi …
é possivel usar bem JSP sim, mas considerando simplesmente a possibilidade de utilizar scriptlets, o que causa um estrago incrivel nas mãos de qualquer um que esteja começando a programar em java.
ou vai dizer que tu nunca viu um sistema “feito em JSP”? se tu ja viu um, tu não tem o direito de descordar do que eu disse, se tu nunca viu, quando tu ver tu vai entender
mas mesmo assim, eu disse que era a minha opinião, ou seja, tu não é obrigado a concordar com a minha opinião
Diego:
“Em Java EE 5 isso foi simplesmente pulverizado? existe agora 1 descritor XML para persistencia? o resto virou tudo opcional? configuracao pela excessão? a unica coisa que tem ainda que configurar eh o web.xml e tmb é discutivel? se vc usar um IDE como NetBeans , nem nele vc nao pega.”
–Não foi pulverizado não, a configuração só mudou de lugar, agora em vez de configurar em XML se configura via annotations …
“Olha? se vc usar Java EE 5 nao vai usar 123123123 frameworks diferentes? vai usar JSF 1.2 e EJB 3 , com a especificação simplificada e uma IDE descente para te auxiliar em algumas coisas ditas morosas vc vai se dar bem? Agora quanto a diciplina? eh meio obvio neh ? ou vc preferiria algo ?like PHP?? ? Voce jah deu manutencao em um sistema PHP onde o cara teve ?toda essa liberdade?? ? eu já? e posso dizer? viva a ?diciplina??.”
des de que tu queira fazer aplicações WEB, para fazer sites JSF não ajuda muito, até atrapalha, mas ai ja estariamos entrando e outra conversa …
Outra coisa, os EJBs realmente estão mais fáceis de usar, mas para cada página JSF que tu fizer tu tem que cadastrar pelo menos 2 outcomes e 1 backing bean via XML (sim, eu sei que da pra fazer via java, mas não é exatamente a coisa mais intuitiva do mundo, e eu não estou também reclamando da forma de configurar, estou reclamando de ter de configurar 
)
–Com isto eu até concordo
Concordo que é bem melhor que XML por ser compilado e bla bla bla, mas continua sendo configuração
“Alguem usa isso puro ainda ? JSP é um PHP só que com Java? tem suas utilidades? mas nao dah para ficar criticando algo que em projetos serios não é nem cogitado a utilizacao.”
O Java EE 5 realmente melhorou
Reply to this comment– Sim, usam, vide comentário do Deiverson a cima
“Isso em Java EE 5 simplesmente não existe. Existe se voce quiser configurar algo fora das anotações? e repito? faces-config.xml e web.xml são mantidos pela IDE , dificilmente eu tomo ciencia deles? soh quando quero fazer algo mais mirabolante? até o mapeamento de Servlets é feito automatico pelo netBeans? mantem atualizado os vinculos e etc?”
–Como eu comentei no post, eu não estava me referindo a configurações neste ponto, tanto que usei BPEL como exemplo, acho que isto é um mau uso do XML por parte da maior parte dos frameworks, não relacionado diretamente com Java EE
PS.: muito obrigado pelo post, vou dar mais uma olhada no Java EE 5, mas como eu disse antes, este post não quer dizer que “eu não gosto de java”, mas não é por eu gostar da plataforma, que eu tenho que concordar com absolutamente tudo
Eu acho que a pior coisa em JAVA é a impossibilidade de liberar um objeto da memória na mão, deveria ter uma opcão para informar que você quer que tal objeto não seja controlado pelo garbage collector e sim que voce vai liberar ele na mão.
Reply to this commentEu quero dominar a linguagem, não gosto quando a linguagem me domina.
Wilton:
Eu acho isso uma das melhores coisas do java… manipular objetos na mão é extremamente chato… se preocupar em finalizar tudo que se cria… qual a vantagem disso ?
Nao tem nada de “ser dominado”… é questao de praticidade…
Trabalhei muito em delphi minha vida… e te digo que esquecer um .free e ele dar problema 2 horas depois é uma coisa constante… o proprio delphi tenta minimizar isso quando voce coloca um componente visual (um botao por exemplo) vc nao precisa finalizar ele na mao… apenas o que voce cria nos metodos…
Imagina uma tela com 50 objetos dentre eles 32 labels…
Qual a graca em fazer 50 linhas com
label1.free();
label2.free();
Acho que voce tem mais coisa para se preocupar que isso.
Reply to this commentOlá!
Também achei exagerada a crítica ao JSP. Se usam errado, a culpa não é obrigatoriamente da tecnologia. Partindo desse princípio, posso desqualificar *QUALQUER* tecnologia.
JSP tem muitos méritos. Na época do seu surgimento ela representava até certo ponto a maturidade que existia para este tipo de tecnologia no mercado e é tão sólida que muita coisa que vem surgindo, com a evolução da maturidade/tecnologia, roda “por cima” dela.
Então, dá um desconto pra coitadinha.
Reply to this commentAbraços!
Oi.
Devo dizer que concordo, ou pelo menos penso relativamente igual, a voce em muitos pontos.
A parte da configuração excessiva realmente pode te deixar fulo da vida quando voce teve aquele dia ruim, e nos dias bons conseguem realmente torrar uma parte da paciencia.
A parte da programação web do java, voce disse tudo. Apesar de ser possível fazer tudo num jsp, e sofrer pro resto da vida, ou causar a perda de cabelos de um outro pobre coitado, é necessário aprender vários frameworks que não fazem parte da especificação J2EE formal. Há de se descontar o JSF.
A parte da compatibilidade retroativa, realmente devo concordar que é uma coisa boa, para sistemas antigos que rodam Java e não podem simplesmente parar por causa de uma atualização.
JSP não precisa comentar. Começou com o Servlet que era horrível para se criar páginas. Dai eles vem com o JSP que se baseia no Servlet. Ótima evolução.
E a parte do XML é perfeita. XML foi feito para troca de informações. Ponto. Sem se preocupar qual linguagem que o programa que gerou foi feito e qual linguagem o programa que irá ler foi feito. Usar XML para coisas mirabolantes como configuração de ORM do Hibernate por exemplo, ou para as configurações de eventos do Struts deveriam ser explodidas da face da terra.
Reply to this commentO Dyego falou tudo….
e acrescento mais:
qual o problema em ter q usar frameworks, MVC, design patterns?? Quer fazer tudo “nas coxa” (de qualquer jeito) como muito pseudo-programador por aí? Pensa num sistema q seja desenvolvido por vários programadores sem padronização nenhuma e veja a bagunça q vai ser o código….
Você não pensou em facilidade d manutenção quando escreveu essa crítica?
Retirar completamente o suporte a JSP? E os sistemas legados em java q usam scriptlets jsp? Irão parar de funcionar por falta d retrocompatibilidade…
Desde quando é f** colocar um atributo Main-Class no manifesto do jar?
E quem disse q o java tá morrendo? Só por que não é exatamente igualzinho a linguagem q vc usava antes d aprender java?
Quanta crítica sem sentido…
Reply to this comment[...] dos grandes problemas do Java EE como eu falei em outro post, é a necessidade de configurar tudo, a possibilidade de configurar é uma das maravilhas do Java, [...]
Reply to this comment[...] e concordando com o Urubatan: ?Um dos grandes problemas do Java EE como eu falei em outro post, é a necessidade de configurar tudo, a possibilidade de configurar é uma das maravilhas do Java, [...]
Reply to this commentLuis,
Reply to this commento problema é ter que usar …
poder usar é excelente
mas realmente esta necessidade, deu origem a algumas das pérolas que temos hoje, como o Seam, JSF, Spring, …
Java é um nojo total.
Reply to this commentQuanta crítica sem sentido.
Se acham que java é um nojo total ou ficam reclamando à toa, então esqueçam java e voltem para a linguagem que usavam antes.
Reply to this commentMuito legal seu post urubatan, na minha opinião usar uma tecnologia não significa idolatra-la sob qualquer hipótese. Se fosse perfeito não precisaria ter saído da versão 1.0.
As críticas são muito importantes, mais do que os elogios, fazem com que a tecnologia evolua e fique ainda melhor do que já é. Galera xiitismo não leva a nada.
A única crítica que talvez você deveria repensar (pelo menos um pouco) não pelo Java mas sim pelo histórico do desenvolvimento web é a do JSP, já utilizei algumas tecnologias diferentes para web (especificamente ASP, PHP, JSP e ASP.NET) e todas elas tem características muito parecidas, que as vezes parecem ruins, mas são assim desde o CGI puro e nunca mudaram, eles devem ter tido bons motivos para fazer o JSP desta forma.
NENHUMA CRÍTICA É SEM SENTIDO (só a do Dênis, ele também deve ser xiita, mas não pelo Java)
Deve-se continuar criticando o que não é bom, para que seja melhorado sempre.
Resumindo, Dênis, cai fora cara, isso é conversa pra gente que gosta de TI, não extremista xiita radical talibã de linguagens de programação específicas (provavelmente .NET).
Luis e Dyego, peguem leve, isso é construtívo! Java é MUITO bom, mas tem seus defeitos sim, deixem seu fanatismo de lado e digam aí:
O que vocês acham que poderia ser melhorado?
Reply to this commentHehe, eu tenho como certeza que JSP surgiu para competir com ASP e PHP que eram linguagens de script que dominavam o mercado e Java estava apenas com desenvolvimento via Servlets.
A linguagem avançou muito e temos muitos frameworks para trabalhar. O conhecimento fica muito segmentado, que é bom em alguns casos, mas complicado em outras situações. Para contratação de profissionais muitas vezes complica.
Hoje com o Ruby por exemplo tem o Ruby on Rails. Isto hoje, daqui a pouco vai sair alguém dizendo que o framework “Ruby on The Shoes” é melhor e vão nascer outros frameworks e o esquema começa a acontecer.
Acho que o fato de sempre pensarmos no java como sendo uma “enterprise class language” é que pode pesar. Quando precisamos fazer algo simples o negócio pesa.
Aí a solução pode ser as JSRs que falam sobre scripting dentro do Java, o JRuby e assim a coisa vai avançando, com mais frameworks para conhecermos, dominarmos e trabalharmos.
Reply to this commentExistem alguns compiladores de JAVA para binario puro http://www.excelsior-usa.com/jet.html , http://gcc.gnu.org/java/
entre outros, mas mas pelos testes que fiz ainda nao estao com performace de c++.
O garbage coletor nao deveria ser obrigatorio, deveria existir uma maneira de deixar o objeto fora dele e poder liberar o objeto da memoria quando quisesse.
O JNI tem um overhead para troca de contesto com C/C++ oque baixa a performace do codigo obs: CNI jo GCJ nao tem esse problema.
Reply to this commentComo JAVA engloba muitas plataformas, todos os usos específicos dele se tornam mais complexos do que se utilizar tecnologias que “nasceram” para a função. PHP é mais prática que JSP, Flash é mais sofisticado que JavaFX, Delphi é mais produtivo que Swing. Por isso que sempre encontraremos defeitos em Java, porque comparamos com essas tecnologias. Mas já pensaram em desenvolver Web com Delphi? Arrrgrgggg…. Animação com PHP? Programação side-server com Flash? (essas duas ultimas sequer são possíveis acredito eu).
Ou seja, tudo acaba caindo naquele dilema que o professor insiste em repetir na classe de aula: “depende da aplicação”. Mas o que me fez olhar com mais carinho para o Java frente a outras tecnologias é que o Java é o melhor para a fase de manutenção do sistema, e a manutenção é a parte do ciclo de vida do software que tem maior duração.
Reply to this commentMuito bom o artigo!
Reply to this commentParabéns!
[...] e com a mesma linguagem ? poss?vel escrever aplica??es para celulares, PCs, PDAs, Main Frames ehttp://www.urubatan.com.br/2007/02/28/6-coisas-que-eu-nao-gosto-no-java-seee/Adoro - Translate this page Adoro. Armando Manzanero. adoro la calle en que nos vimos, … adoro la [...]
Reply to this comment