| 1 |
On Tue, 11 Apr 2017 00:44:30 +0300 |
| 2 |
Mart Raudsepp <leio@g.o> wrote: |
| 3 |
|
| 4 |
> Ühel kenal päeval, E, 10.04.2017 kell 17:33, kirjutas William L. |
| 5 |
> Thomson Jr.: |
| 6 |
> > Add a new Java version and recompiling packages with it, will also |
| 7 |
> > immediately show breakage if any. |
| 8 |
> > |
| 9 |
> > If your saying Python code is of higher quality than Java. I would |
| 10 |
> > digress heavily on that. You have leniency in python not being |
| 11 |
> > strong typed. Lack of generics and stuff could only mean that could |
| 12 |
> > be worse. |
| 13 |
> > Relying on internals to handle data types for you. |
| 14 |
> |
| 15 |
> Which is why python modules can't just pretend to work with a newer |
| 16 |
> python by merely happening to "compile" and install. It is not |
| 17 |
> strongly typed and it does not involve a AOT phase (pyc is just a |
| 18 |
> semi-binary representation of the source code really) and issues are |
| 19 |
> not found unless properly tested at runtime or test suite. |
| 20 |
|
| 21 |
Java is strong typed. Lots things in Java have tests. That does not |
| 22 |
ensure no bugs. Nor does that mean things are the same all the time. |
| 23 |
|
| 24 |
Case in point. I have issues that upstream does not. Both on JDK 1.8, |
| 25 |
and java is java so it should be the same right? |
| 26 |
|
| 27 |
Fix for Java 1.8 and Guice 4.1 |
| 28 |
https://github.com/jclouds/jclouds/pull/1036 |
| 29 |
|
| 30 |
Its likely a matter of dependencies. Their guice may not have been |
| 31 |
compiled as Java 1.8. Thus I may be triggering something they are not. |
| 32 |
It is not easily figured out if the fix is needed or not. Though in my |
| 33 |
case without it fails. In their case without it does not fail.... |
| 34 |
|
| 35 |
> > Regardless of new eclass, the TARGETS remain. Things did not change |
| 36 |
> > from a user perspective. Recently packaging some ebuilds, the |
| 37 |
> > COMPAT/VERSION does not seem to have changed. Despite what ever |
| 38 |
> > changes to the eclass. |
| 39 |
> |
| 40 |
> Users don't get unexpected failures, as things that are claimed to |
| 41 |
> work with a given python version, probably actually do so. |
| 42 |
|
| 43 |
This really is no different. We are not talking about a new python |
| 44 |
version going straight to stable. Any issues would be in ~arch, and |
| 45 |
short of speculation. It may not effect as many packages as people |
| 46 |
think. |
| 47 |
|
| 48 |
If python is really breaking that much between even 3.x releases. Then |
| 49 |
just shows that much more how it sucks. Though I think breakage could |
| 50 |
be looked out for. Code modified. Fixes sent upstream. etc. |
| 51 |
|
| 52 |
When I see lots of versions. Seems more like people are maintaining vs |
| 53 |
fixing/patching the code and sending stuff upstream. I would have more |
| 54 |
but not everything do I take upstream. Depends on if I feel they will |
| 55 |
be receptive or a waste of my time. |
| 56 |
|
| 57 |
Thankfully most in Java are forward looking. Most active projects |
| 58 |
already support 1.8 and have things being tested under Java 9. |
| 59 |
|
| 60 |
-- |
| 61 |
William L. Thomson Jr. |
Archives