• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Cool New Options for Process class and dumb typo in JavaDocs

 
Jesse Silverman
Saloon Keeper
Posts: 1603
51
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had heard there were some cool new additions to the Process class in Java 8, 9, and, apparently, now in 17.

I went to read about these here:
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Process.html

And they do indeed seem pretty nifty, I think I especially appreciate the inputReader(), errorReader() and outputWriter() methods, because let's face it, character input/output is pretty common.

There seems to be a weird typo in the new explanatory info up-top.  First I thought I was just being dense, but now it looks to me like a typo:

JavaDocs wrote: The I/O streams of characters and lines can be written and read using the methods outputWriter(), outputWriter(Charset)}, inputReader(), inputReader(Charset), errorReader(), and errorReader(Charset).



Why the '}'?  What's that mean.  I now think it is just a formatting/rendering error or typo.
Or am I misunderstanding something?

Either way, cool new additions since Java 7 I'd mostly ignored until today.
 
Mike Simmons
Master Rancher
Posts: 4052
56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm pretty sure it doesn't mean anything - just a dumb typo, as you say.

The new methods are nice, though.
 
Tim Holloway
Saloon Keeper
Posts: 24496
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:I'm pretty sure it doesn't mean anything - just a dumb typo, as you say.

The new methods are nice, though.



Actually, they drove me crazy.

I was re-engineering a VERY old Android app of mine and the client/server interfaces had gone through about 5 stages of obsolescence at that point. The latest replacement was pretty much punting to the new core JVM process services, but since they, too were so much in flux, it was hard to figure out what to do.

I'm getting very cross about this kind of stuff. It reminds me too much of the Bad Old Days when Microsoft had a different DBMS every week and the stuff I wrote to connect Excel and webservers was obsolete before I finished it.
 
Jesse Silverman
Saloon Keeper
Posts: 1603
51
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:...

Actually, they drove me crazy.

I was re-engineering a VERY old Android app of mine and the client/server interfaces had gone through about 5 stages of obsolescence at that point. The latest replacement was pretty much punting to the new core JVM process services, but since they, too were so much in flux, it was hard to figure out what to do.



To be clear, it is the new API methods to which I referred in this post that are driving you crazy?

If I recall correctly, Android has decided to be stuck on Java 8 forever, and if you don't like that, switch to Kotlin, right?

 
Tim Holloway
Saloon Keeper
Posts: 24496
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a sense. Because the Internet does not present things chronologically, often a "better" method would have come along to be obscured by an older one. Or even an older simpler approach might be pushed aside from a more complex/confusing newer one. It begins to smell like throwing things at the wall and see what sticks.

As for Android's Java hang-ups, I'm really not into the newer features anyway. I'll gladly let Android Studio convert my legacy code to use Lambdas, and I do keep streams in mind, but for the rest, I paid little attention. The goal for the moment was to upgrade first for the OS. Only afterwards for the language.
 
Paul Clapham
Marshal
Posts: 26909
82
Eclipse IDE Firefox Browser MySQL Database
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would be nice if the Java folks would produce a Release Document which lists all of the changes like that. But when I tracked down this document:

API Differences between Java SE 16 (build 36) & Java SE 17 (build 35) Compiled by Iris Clark

I realized that it would then be a monstrously large document. For example there's 191 "contexts", which term appears to mostly mean "methods", which are new. I see there's a new java.util.HexFormat class whose purpose is to convert between bytes and chars and hex-encoded strings. It supports a variety of decorations too -- but this one is mentioned in the Release Notes. The new methods don't make it into the Release Notes so we're left to stumble over them when browsing.
 
Tim Holloway
Saloon Keeper
Posts: 24496
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem with autodocs, release notes and the like is that they don't show practical use in most cases.

But every time I run across a blog or internet article that has no date on it, I want to scream.
 
Les Morgan
Rancher
Posts: 988
23
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Paul,
I completely agree.  Java used to be a delight to develop with in comparison to MS's run for the change, but any more there is no difference.  I have a VERY difficult time selling any of my clients on Oracle Java any more when their developers are facing the same things, with better support included in their Windows contracts, than Oracle is giving.

I really miss the days of the Volvo type of bettering the product, instead of releasing new versions very few months--they are out Microsofting Microsoft--and that is not a good thing!!!
Les

Paul Clapham wrote:It would be nice if the Java folks would produce a Release Document which lists all of the changes like that. But when I tracked down this document:

API Differences between Java SE 16 (build 36) & Java SE 17 (build 35) Compiled by Iris Clark

I realized that it would then be a monstrously large document. For example there's 191 "contexts", which term appears to mostly mean "methods", which are new. I see there's a new java.util.HexFormat class whose purpose is to convert between bytes and chars and hex-encoded strings. It supports a variety of decorations too -- but this one is mentioned in the Release Notes. The new methods don't make it into the Release Notes so we're left to stumble over them when browsing.

 
Tim Moores
Saloon Keeper
Posts: 7162
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesse Silverman wrote:If I recall correctly, Android has decided to be stuck on Java 8 forever, and if you don't like that, switch to Kotlin, right?


But I don't think Kotlin extends the API. It has some capabilities that make it easier to use than Java, but the platform API is the same for both languages. If you need something else, AndroidX and other additional libraries are the way to go.
 
Tim Moores
Saloon Keeper
Posts: 7162
165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:It would be nice if the Java folks would produce a Release Document which lists all of the changes like that. But when I tracked down this document:

API Differences between Java SE 16 (build 36) & Java SE 17 (build 35) Compiled by Iris Clark

I realized that it would then be a monstrously large document. For example there's 191 "contexts", which term appears to mostly mean "methods", which are new. I see there's a new java.util.HexFormat class whose purpose is to convert between bytes and chars and hex-encoded strings. It supports a variety of decorations too -- but this one is mentioned in the Release Notes. The new methods don't make it into the Release Notes so we're left to stumble over them when browsing.



Rob Spoor maintains a more manageable (IMO) version of that at https://robtimus.github.io/whats-new-in-java/
 
Rob Spoor
Sheriff
Posts: 22504
122
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
True. I found two others as well in September:
  • https://javaalmanac.io/jdk/17/apidiff/11/ offers the same functionality plus more. One of the features I had planned is already there: showing which new implements clauses there are. I only miss filtering and collapsing of nodes.
  • Oracle offers new additions to the API as well now: https://docs.oracle.com/en/java/javase/17/docs/api/new-list.html
  •  
    Jesse Silverman
    Saloon Keeper
    Posts: 1603
    51
    Eclipse IDE Postgres Database C++ Java
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    So in addition to Rob's much-appreciated efforts, the recent posts have shown no fewer than three additional resources to track API changes across versions, including one from Oracle, right?

    While I definitely agree that working with Microsoft technologies was often very frustrating, I am not certain that working with Java is now equally bad for the same reasons.

    In general, most of the important "Microsoft" documentation has now been very much open-sourced, and those maintaining it seem to be very accessible when it comes to suggested fixes and changes.  In my personal experience those maintaining the JavaDocs are now less responsive.

    I am also not sure I think that frequent releases of Java are the core problem here.
    I am also not sure they aren't.

    I am pretty sure that knowing which places to go to stay on top of them is now Very Important, so thank you for the links everyone, and any shared experiences as to which ones are the easiest and most useful to work with, even better.

    My approach to just learn as I go by consulting the Javadocs for new changes whenever I am using some facility I haven't read the docs for in a while wasn't *not* working, but these various supplementary documentation-of-changes-and-additions efforts are all much appreciated.
     
    Tim Holloway
    Saloon Keeper
    Posts: 24496
    167
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    So far, there are no Kotlin-only APIs for Android and no plans, but also no promises. And curse it, I'd forgotten about the whole androidx mess and its relatives. Android is as slippery a platform as Windows. Totally gives the lie to the idea that "Java" is inherently a stable platform.

    Don't expect much from the core Java documentation. Oracle is only in it for the money - and they're having no better luck making money off Java than Sun did. Sun was more dedicated, but didn't have the budget and offshoring the bulk of the product to a continent where English is generally not the birth language couldn't have helped.

    One of the things I miss most about "dead tree" technology magazines was that their chronology was never in doubt and people actually got paid to make things plain. It also helped that I could randomly flip through them and make happy discoveries - reading PDF's on a tablet doesn't compare, and this is coming from someone who reads most entertainment on tablet.

    A lot of my keeping up to date comes from following conversations here on the Ranch. If I have an active project, much of the rest comes from chasing down documentation related to things I want to do in that project. But since I resigned from the Corporate World, much of what I do isn't even Java now (current project excepted).
     
    Jesse Silverman
    Saloon Keeper
    Posts: 1603
    51
    Eclipse IDE Postgres Database C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Tim Holloway wrote:
    Don't expect much from the core Java documentation. Oracle is only in it for the money - and they're having no better luck making money off Java than Sun did. Sun was more dedicated, but didn't have the budget and offshoring the bulk of the product to a continent where English is generally not the birth language couldn't have helped.



    Agreed with everything else and nothing useful to add, you already said it all, eloquently.

    I am confused about the status of Javadocs, however.

    The "Microsoft" situation, IMHO, regarding both C++ and .Net Documentation got much, much better right around the same time they started open-sourcing more and more and more of the code base.

    As far as I can tell, this is because the control of the documentation got open-sourced at the same time, and is now contributed to by both for-pay Microsoft staff and a dedicated bunch of us weird Open-Source types giving away lots of their time and efforts just so everyone has better documentation.

    I don't have the feeling that the same thing has happened with the core Javadocs, and if it hasn't, it is not obvious that the reason is that somehow Oracle is greedier than Microsoft.

    I agree it feels like a problem, but I am less certain of either the cause or the best approach to solving it.
     
    Tim Holloway
    Saloon Keeper
    Posts: 24496
    167
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Jesse Silverman wrote:I don't have the feeling that the same thing has happened with the core Javadocs, and if it hasn't, it is not obvious that the reason is that somehow Oracle is greedier than Microsoft.

    I agree it feels like a problem, but I am less certain of either the cause or the best approach to solving it.



    Watch what happens over the next few years. Oracle is very possessive of their Intellectual Property - remember, they recently lost a lawsuit where they tried to claim ownership over not only the implementation, but the definitions of the fundamental Java classes. A lot of the move on Android to Kotlin has been fueled by developers wanting to ensure that their own work would be safe.

    You might think that they'd welcome "fan additions" to their documentation (like PHP did), but in fact, that's not the norm in business. Commodore had a very friendly relationship with their Amiga development community, but even they didn't allow people to just come in and self-integrate. As a rule, only open-source projects permit that.

    Microsoft has become friendly actually because they're more commonly accused of anti-trust action, plus they are competing heavily against open-source alternatives and thus need to make themselves look as attractive as possible. OpenJDK is an open-source alternative to Java, but it's not really "competition". It has go go through Oracle's certification process. And as long as it must remain a virtual clone of the Oracle product, don't expect anyone to get creative with the javadocs.

    Now that JEE is Jakarta EE, you may see a difference in their documentations. Although documentation for any software product is often a problem. Commercial products see the documents more as a cost than as a revenue generator, but open-source projects often see the coding as the "glamour" job, and documentation as something someone will hopefully do.
     
    Jesse Silverman
    Saloon Keeper
    Posts: 1603
    51
    Eclipse IDE Postgres Database C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    So much valuable information in there for me, Tim.

    My take-home caution: "Don't let the changes that we've seen in the relationship between Microsoft and the larger open-source community surrounding C#, .Net and C++ lead you to believe that we will see that same beneficial change in relationship everywhere else that Large Corporations are part of a larger open-source community.  Hope for it, if it makes you feel better, but don't bet on it."
    (That's how my brain paraphrased your thoughtful explanation).

     
    Rob Spoor
    Sheriff
    Posts: 22504
    122
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    As someone who's subscribed to the core-libs-dev mailing list, the process to get any changes in seems to be very, very bureaucratic.

    You have to sell your soul sign the OCA first. Then you can fork the OpenJDK on GitHub, fix the documentation bugs, and create a merge request. There may be some rules involved that I don't know about though, because all pull requests (https://github.com/openjdk/jdk/pulls) have a ticket number assigned already. Anyways, after that you need to become very, very patient, as the reviewing process is started. Depending on the MR, that might take ages, especially if the reviewers don't think your issue is worth the while.

    For feature requests the process becomes even worse. You need to start a discussion on the mailing list first about whether or not the feature is actually wanted. I've made a few suggestions that either got shot down or never even got a reply. The biggest success was my latest suggestion (custom default properties in annotations); the answer there was something like "it's a nice feature but we'll probably never make time to work on it". Since it involved language changes as well I'm certainly not going to provide code myself.
     
    Tim Holloway
    Saloon Keeper
    Posts: 24496
    167
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Rob Spoor wrote:As someone who's subscribed to the core-libs-dev mailing list, the process to get any changes in seems to be very, very bureaucratic.


    No surprise. Java was designed from the beginning to be an industrial-grade language environment. To ensure that Java would truly be "write-once/run-anywhere", Sun kept a tight rein on the language. Which, as it turns out was wise, considering what Microsoft tried to do to it.

    A JDK/JRE has to go through a rigid certification process before it can claim the name "Java". To make mods to the language environment you have to file a JSR and everyone in the world is going to pick it apart, argue over it, get it amended, proofed, and eventually - if you're lucky - get it incorporated.

    OpenJPA is just as subject to those constraints as is Oracle's own Java products, or for that matter IBM's. A minor change could potentially affect millions, so even bug fixes are not taken lightly.

    Incidentally, it's not just a joke that fixing bugs is like pushing on a balloon. Long ago studies determined that once a product attains maturity, the number of bugs remains relatively constant. IBM's OS/360 had something like 10,000 bugs in any given release.

    You might think that documentation changes would be easier, but considering the number of ways that people can mis-read simple statements, not so. One of the reasons why automated software development has never been realized at scale. Too many different ways to implement "All You Have To Do Is..." pop up.

    For things like third-party libraries, life is less strenuous, of course. Though it also depends on who's involved (for example, Apache Foundation products).
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic